DevSecOps_RFI_final_update date.pdf

REQUEST FOR INFORMATION

OPERATIONAL TEST AND TRAINING READINESS DIVISION

1.0 Description

1.1 1.1 Space Systems Command (SSC) is seeking information on how interested industry partners and a Consortium Manager (CM) could design, engineer, evaluate, and validate a secure, multi-node, multi-vendor continuous software development and delivery architecture.

The Government is evaluating the feasibility of executing a No-Funds-Obligated (No-Cost) Prototype Other Transaction Agreement (OTA) under the statutory authority of 10 U.S.C. § 4022.

The primary technical objective of this prototype project is to test the viability of connecting commercially owned and operated secure facility nodes directly to secure Government cloud environments to enable scalable, secure DevSecOps pipelines.

Phased Market Research Approach: This RFI is being conducted under a two-phase security and market research framework:

• Phase 1 (Public RFI): This public notice is intentionally generic to protect operational security and prevent public disclosure of specific technical environments. It focuses on identifying baseline commercial software capabilities, business case feasibility, and vendor security postures.

• Phase 2 (Controlled Release): Following the evaluation of Phase 1 responses and the verification of vendor security clearances, qualified and vetted respondents will be invited to participate in Phase 2. Under Phase 2, specific technical integration requirements, architecture guidelines, and target enclaves will be shared under a Non- Disclosure Agreement (NDA) via secure, controlled Government communications channels.

In addition to our primary NAICS code (541715 - Research and Development in the Physical, Engineering, and Life Sciences), we have listed secondary NAICS codes—including 541512 (Computer Systems Design Services), 541511 (Custom Computer Programming Services), and 541519 (Other Computer Related Services). This is a strategic decision to cast a wide net across the commercial sector. Because many specialized software developers, cloud architects, and cybersecurity providers categorize themselves under these IT codes rather than traditional military R&D, adding these secondary codes ensures this innovative opportunity reaches a diverse, highly capable pool of modern tech companies without prematurely restricting the Government's acquisition approach.

1.2 THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. This Request for Information (RFI) is issued solely for information and planning purposes (market research). This RFI does not constitute a solicitation (Request for Proposal (RFP), Request for Prototype Proposals (RPP), or Request for Quotation (RFQ)) or a promise to issue a solicitation in the future. This RFI does not commit the Government to contract for any supply or service whatsoever. Responses to this

RFI are not offers and cannot be accepted by the Government to form a binding contract.

Furthermore, the Government is not, at this time, seeking proposals and will not accept any unsolicited proposals. Respondents are advised that the Government will not pay for any information or administrative costs incurred in response to this RFI. All costs associated with responding to this RFI will be solely at the responding party’s expense. Not responding to this RFI does not preclude participation in any future solicitation, if any is issued. Any information submitted by respondents to this RFI is strictly voluntary. All submissions become Government property and will not be returned. Proprietary information will be safeguarded in accordance with the applicable Government regulations. Proprietary information or trade secrets shall be clearly identified.

2.0 Background

2.1 In the current military space and software ecosystem, integrating commercially developed software into highly secure networks presents a critical, systemic technical and scheduling bottleneck. Currently, software is largely engineered in disparate, unclassified environments and later manually migrated across high-to-low security boundaries. This security barrier to entry paradigm results in severe technical friction:

Accreditation Delays: It regularly takes extended periods post-contract award to construct, accredit, and clear physical secure facilities for new entrants or small businesses, locking out innovative commercial firms and forcing them to sit as subcontractors under traditional prime contractors

Delivery Failures: Software often faces technical integration challenges, dependency failures, or configuration issues upon high-side delivery because it was not natively built, compiled, or tested in a continuous integration/continuous delivery (CI/CD) pipeline connected to the target cloud enclave.

2.2 To optimize software accreditation timelines and improve deployment reliability, SSC intends to prototype a decentralized software delivery pipeline. This technical prototype will prove whether a multi-node, secure development network can successfully and securely compile, test, and deploy software directly from distributed commercial nodes to secure Government enclaves.

This ensures that when future Space Force programs of record are awarded, the industrial base has a robust pool of cleared, "shovel-ready" software providers capable of executing secure work on Day 1.

3.0 Proposed Prototype Mechanics

3.1 General Consortium Architecture

To scale this architecture without burying Government security and contracting offices in hundreds of individual bilateral agreements, the Government is considering a multi-vendor Consortium framework:

The Prime OTA: The Government will sign a single, overarching Prime No-Funds-

Obligated Prototype OTA (obligating $0.00 of federal funds) and a Prime DD Form 254 with a designated Consortium Manager (CM) or Consortium Management Organization (CMO).

The Flow-Down: The CM will handle administrative onboarding, issue sub-agreements, and flow down subcontractor DD254 sponsorships to participating commercial industry vendors. The Government will retain strict, unilateral written veto and approval authority over all consortium members to protect national security.

3.2 Value Exchange and Cost share (10 U.S.C. § 4022(d))

Government Contribution: In-kind contribution consisting of DD254 sponsorship (Facility Clearance and Personnel Clearances), technical oversight, and access to secure software enclaves and testing datasets.

Industry Cost-Share: In accordance with 10 U.S.C. § 4022(d), participating commercial vendors will provide 100% of the cost-share, utilizing private start-up or internal capital to construct/lease their physical secure facilities, clear their personnel, and fund the engineering labor required to stand up their pipeline nodes. This structure accommodates substantial participation by Non-Traditional Defense Contractors (NDCs) and small businesses.

3.3 Consortium Administrative Fee Structure

Because the Government is obligating $0.00 to the CM, the CM's administrative overhead, platform management, and vetting processes will be funded entirely via nominal membership or transaction fees paid by the participating industry vendors. This allows the ecosystem to scale rapidly and sustainably at no cost to the taxpayer.

3.4 Pathway of Production (10 U.S.C. § 4022(f))

In accordance with 10 U.S.C. § 4022(f), upon a determination that a participant has successfully completed their pipeline prototype node (demonstrating safe, secure connection and software transmission), they may be eligible for a sole-source follow-on production contract or transaction under future programs of record without further competition.

3.5 Security & DCSA Compliance (The "Bona Fide" Need)

Sponsorship of a Facility Security Clearance (FCL) requires a documented bona fide need to access classified information during the performance of the active agreement. Under this prototype, the bona fide need is established by the technical requirement to test, validate, and troubleshoot live, secure continuous-delivery software nodes routing secure experimental datasets.

Note: The prototype project does not exist as an administrative clearinghouse; rather, the security clearances are a prerequisite to execute the active secure DevSecOps pipeline prototype.

• All participating vendors must be entirely U.S.-owned and operated (precluding foreign ownership, control, or influence [FOCI]).

• Participating personnel must be U.S. citizens eligible to obtain and maintain the required personnel clearances.

4.0 Requested Information

4.1 Technical Capability and Physical Readiness

Interested vendors are requested to provide information on the following:

1. Describe your organization's technical capability to engineer, secure, and maintain a secure

CI/CD software delivery pipeline node (e.g., DevSecOps toolchains, containerization, Kubernetes) from a commercial facility.

2. Detail your organization’s familiarity or experience working within high-security government cloud environments or secure hosting infrastructures.

3. Secure Submission of Security Posture: To protect vendor information and maintain robust operational security, do NOT submit detailed narratives regarding your physical facility floor plans, specific capital readiness figures, or sensitive security vulnerabilities in your public response. Instead, interested vendors must submit their current Facility Clearance (FCL) level, CAGE code, and general security posture via a separate, secure channel directly to the designated Government Points of Contact listed in Section 6.1.

4.2 Business Case and Consortium Feasibility

Feasibility of No-Cost Model: Does the proposed No-Funds-Obligated/In-Kind Cost Share model present a viable business case for your organization? Specifically, is the opportunity to secure FCL sponsorship and a 10 U.S.C. § 4022(f) transition pathway sufficient incentive for your organization to invest the private capital required to establish a secure facility and engineer the software node?

Consortium Fee Structure: Provide feedback on the viability of paying nominal membership or transaction fees to a Consortium Manager to fund the administrative overhead of the ecosystem.

Risks & Barriers: Identify any critical technical, administrative, or legal barriers you foresee in executing this "first-of-its-kind" no-cost prototype and propose potential mitigations.

5.0 RFI Responses

5.1 Interested parties are requested to respond to this RFI with a white paper addressing Requirements and Requested Information, as stated in this RFI.

• White papers will be in Microsoft Word for Office compatible format o Can contain no more than 5 pages. The title page and front matter such as transmittal letter, cover page, and table of contents will not count against the page limit.

o 8.5 x 11-inch pages o Font no smaller than 12-point Times New Roman unless for artwork and/or tables which can be no smaller than 8-point Times New Roman or Arial o Line spacing 1.0 or greater o 1-inch margins for all 4 edges of pages

• Provide Offeror Business Information o Name, mailing address, phone number, and e-mail of designated point of contact o Cage Code o Unique Entity ID o Business size classification (large, small, or other) o Socio-economic status o The facility security clearance of the responder

• Proprietary information will be safeguarded in accordance with the applicable Government regulations. Proprietary information, if any, should be kept to a minimum and MUST BE

CLEARLY MARKED.

• In order to review the response, PROPRIETARY information may be given to Federally Funded Research and Development Center (FFRDC), Systems Engineering and Technical Assistance (SETA) and/or Advisory and Assistance Services (A&AS) contractors working for the Government. Non-government support contractors listed below may be involved in the review of any responses submitted. These may include but are not limited to: The Aerospace Corporation, Science Applications International Corporation (SAIC), Emolbi, Tecolote Research Inc., Palski & Associates, MITRE, MIT/Lincoln Labs, Pacific Northwest National Laboratory, Galapagos Federal LLC, Tyto Athene, ManTech International, Johns Hopkins University Applied Physics Laboratory (JHU/APL), Georgia Tech Research Institute (GTRI), Utah State University Space Dynamics Laboratory (USU/SDL), and TechSolutions Inc. If Respondents disagree to the release of its RFI response to any of the firms, the Respondent must clearly state this restriction in the cover letter accompanying the RFI responses.

• All submissions become Government property and will not be returned.

6.0 Submittal Instructions

6.1 All responses shall be submitted via email to the Points of Contact identified below. All submissions shall include the company name and point of contact information (including name, position, telephone number, and email address). Please use the following email subject line format: "Response to RFI: Distributed DevSecOps Prototype - [Company Name]” by 12:00 PM MDT on September 11, 2026.

Any questions related to the RFI should be directed to both POCs listed below no later than 12:00 PM MDT on September 10, 2026.

Points of Contact

Ashley J. Irizarry Chief of Contracts Ashley.Irizarry@spaceforce.mil

Jennifer A. Hughes Contracting Specialist Jennifer.Hughes.26.ctr@spaceforce.mil

6.2 Responses received after the due date may not be considered in the Government’s analysis.

The Government may subsequently contact respondents for clarification on the information submitted.

6.3 Oral communications are not permissible. No telephonic communications will be permitted.