Attachment 01 Go_ No-Go Matrix 6 May 25.rtf

Attachment 01 Go/No-Go Matrix Dated 25 April 2025

CHARACTERISTIC

REQUIREMENT

GOV VERIFICATION/CRITERIA

WHITE PAPER REF (PAGE #/PARA)

DoD Software Development and Open-Source Memo Compliance Submission of a white paper that demonstrates how the offeror plans to comply with the DoD Software Development and Open-Source Memo Requirements found on the next page.

The Government will verify the white paper speaks to the proposed capability’s ability to comply with the CIO Memo.

Prototype Demonstration Plan Submission of a white paper that demonstrates how the offeror plans to meet an 8-weeks prototype demonstration schedule in accordance with AOI Technical Attributes.

The Government will verify the offeror successfully demonstrates a plan to meet the prototype demonstration schedule.

DOD CIO Memo Requirements Summary

In accordance with the Department of Defense Chief Information Officer Memorandum, "Software Development and Open Source Software," dated January 24, 2022, all white paper submissions must adhere to the following requirements:

1. Adopt, Buy, Create Approach: White papers must demonstrate adherence to the DoD's "Adopt, Buy, Create" approach to software, preferentially adopting existing government or OSS solutions before buying proprietary offerings, and only creating new non-commercial software when no off-the-shelf solutions are adequate.

2. Commercial Treatment of OSS: White Papers must recognize that OSS meets the definition of "commercial computer software" and therefore must be given equal consideration with proprietary commercial offerings.

3. Software Component Assessment: White papers must include a comprehensive assessment of all software components addressing:

- Long-term support considerations and risk mitigations

- Identification of trusted sources for all OSS components

- Analysis of dependencies, including subcomponents and libraries

- Component security measures and vulnerability management

- Component integrity verification methods

- Evaluation of potential foreign government influence on OSS projects

4. Software Bill of Materials: Submissions must include a detailed inventory of all software components, clearly identifying open source, proprietary, and custom-developed components.

5. License Compliance: White papers must demonstrate understanding of and compliance with OSS license obligations, acknowledging that most OSS is protected by copyright and Government use must conform to license terms.

6. Source Code Delivery: For any custom-developed (non-commercial) software, proposals must include plans to deliver source code and related materials to the DoD as required by Federal Source Code Policy and 10 U.S.C. § 2322a.

7. Modular Open Systems Approach: Proposals must demonstrate how critical technology implementations will be separated from routine automation functions using a modular open systems approach as defined by 10 U.S.C. § 2446a.

8. Product Support Strategy: White papers must address how OSS components will be included in the Life Cycle Product Support Strategy, including the balance between contractor support, organic logistics support, and OSS community support.

9. Security and Distribution Considerations: Submissions must address:

- How software that implements critical technology will be protected

- How vulnerability information will be handled as Impact Level 2 information

- Appropriate distribution statements for any controlled technical information

10. OSS Contribution Strategy: If proposing to contribute to existing OSS projects, white papers should outline the approach for contributing improvements back to upstream projects to avoid creating DoD-specific versions.