BMC3 Application Factory Integrator SOW Dist A - DRAFT.pdf

Distribution Statement A: Approved for public release. Distribution is unlimited.

National Defense Space Architecture

BMC3 Application Factory & Integrator

Statement of Work and Technical Requirements Document

Nov 8, 2022

Table of Contents

1 (U) Background and Scope

1.1 (U) Background

1.2 (U) Definitions

1.3 (U) Normative Text

1.4 (U) Scope

2 (U) BMC3 Program Management

2.1 (U) Program Management

2.1.0.1 Program Management Contractor Requirements

2.1.1 (U) BMC3 Program Schedule Overview

3 (U) Application Factory DevSecOps

3.0.1 (U) DevSecOps Contractor Requirements

3.0.2 (U) DevSecOps System Requirements

4 (U) Application Factory Operations

4.1 (U) Operations Environment

4.1.1 (U) Operations Environment Contractor Requirements

4.1.2 (U) Operations Environment System Requirements

4.2 (U) Application Developer Support

4.2.1 (U) Application Developer Support Contractor requirements

4.3 (U) AppFac Operations Processes

4.3.1 (U) BMC3 AppFac Operations Processes Contractor Requirements

4.3.2 (U) BMC3 AppFac Operations Processes System Requirements

5 (U) Application Factory Development

5.1 (U) Ideas/Planning

5.2 (U) Factory Development (Tier 1)

5.2.1 (U) BMC3 Application Test Lab (BATL)

5.2.1.1 (U) Tier 2 Unclassified Testing

5.2.1.2 (U) Tier 3 Classified Testing

5.2.2 (U) CtF/CodeCheck

5.2.2.1 (U) BATL Contractor Requirements

5.2.2.2 (U) BATL System Requirements

5.3 (U) Application Factory Tools

5.3.1 (U) Application Factory Tools Contractor Requirements

5.3.2 (U) Application Factory Tools System Requirements

5.4 (U) BMC3 Authorized Repository (BAR)

5.4.1 (U) BAR Contractor Requirements

5.4.2 (U) BAR System Requirements

6 (U) Application Factory Deployment Ops

6.0.1 (U) BMC3 Application Factory Contractor Requirements

6.1.1 (U) BMC3 Ground

6.1.1.1 (U) BMC3 Ground Hardware Contractor Requirements

6.1.1.2 (U) BMC3 Ground System Requirements

6.1.2 (U) Sandbox

6.1.2.1 (U) BMC3 Sandbox Contractor Requirements

6.1.2.2 (U) BMC3 Sandbox System Requirements

6.1.3 (U) Canary Ops

6.1.3.1 (U) BMC3 Canary Ops Contractor Requirements

6.1.3.2 (U) BMC3 Canary Ops System Requirements

7 (U) Secure Interoperable-middleware Layer (SIL)

7.1 (U) SIL Overview

7.1.1 (U) SIL Contractor Requirements

7.1.2 (U) SIL Contractor Requirements

7.2 (U) Mission Packages

7.2.1 (U) Mission Package Contractor Requirements

8 (U) AppFac Security Requirements

8.1 (U) Cybersecurity

8.1.1 (U) Cybersecurity Contractor Requirements

8.1.2 (U) Cybersecurity System Requirements

8.2 (U) Program Security

8.2.1 (U) Program Security Contractor Requirements

9 (U) BMC3 Ecosystem Integration

9.0.1 (U) Integration Contractor Requirements

9.1 (U) BMC3 Government Furnished Property (GFX)

9.1.1 (U) Integration Contractor Requirements

10 (U) References

Appendix A – (U) Definitions:

Appendix B – (U) Acronyms and Abbreviations:

Distribution Statement A: Approved for public release. Distribution is unlimited. 1

1 (U) Background and Scope

1.1 (U) Background

(U) The Space Development Agency (SDA) is issuing this solicitation to establish the Battle Management Command, Control, and Communications (BMC3) software development and hosting environment for the National Defense Space Architecture (NDSA). The chosen Contractor for this effort will be responsible for the implementation of a BMC3 Application Factory (AppFac), the development of interfacing documentation, development processes for BMC3 Application deployment, and middleware to allow the NDSA BMC3 ecosystem to execute mission applications in support of warfighter needs. This acquisition establishes software development capabilities to securely and rapidly field mission applications developed by BMC3 ecosystem participants in support of Joint All Domain Command and Control (JADC2) objectives. The BMC3 ecosystem is made up of the AppFac, Secure Interoperable-middleware Layer (SIL), and all future BMC3 applications to be hosted throughout the NDSA.

This BMC3 ecosystem will also include mission partner efforts as well as Sandbox and Canary Operations environments to perform operational testing before a full deployment of each application. The chosen Contractor will serve as the BMC3 Ecosystem Lead, with the responsibility for leading and coordinating development activities within the BMC3 ecosystem.

The BMC3 AppFac, SIL, Sandbox and Canary Ops, and ecosystem integrator responsibilities defined in this document will enhance the capabilities of the NDSA to provide ubiquitous data communications and accelerated decision-making focused on enhancing the warfighters' ability to find-fix-finish, FAST.

(U) The Tranche 1 Transport Layer (T1TL), a proliferated Low Earth Orbit (pLEO) constellation, will form a resilient network, providing information connectivity and delivering time-sensitive information in support of warfighter missions around the globe. This ability to deliver low-latency data transport and sensor-to-shooter connectivity via Link-16, optical communications, and traditional RF connectivity will be critical to providing JADC2 capabilities. The BMC3 AppFac and SIL, to be developed and delivered under this acquisition, will produce mission applications that will operate on BMC3 modules provided by various Space Vehicle Vendors (SVV) (hardware, operating systems application programming interfaces and firmware) beginning in Tranche 1. Hardware, operating system (OS), and firmware requirements for the BMC3 module capability are specified in the T1TL Statement of Work and Technical Requirements Document – this information is available in the Bidders’ Library.

(U) The BMC3 capabilities will evolve the NDSA Battle Management functions into a robust space capability that is less reliant on ground operations, can process data into information sooner than legacy systems, and will improve the speed of decision making. In addition to helping provide enhanced data transport capabilities, the BMC3 capabilities at the edge will provide for a more resilient NDSA supporting all warfighting domains. Greater autonomy

Distribution Statement A: Approved for public release. Distribution is unlimited. 2 provided by advanced computational capability in space will help manage, coordinate, and integrate space and ground resources in support of multiple mission areas. To execute this vision, various NDSA functions will be hosted onboard BMC3 modules to execute constellation network management, alternative navigation management, mission management, and Command and Control (C2) functions.

(U) The BMC3 Ecosystem development will strive to use a Modular Open Systems Approach (MOSA) for hosting mission data processing capabilities.

(U) The goal of the BMC3 architecture is to shorten the kill chain timeline for all missions that involve data transport through space or data derived from space assets. SDA envisions an end-state where mission application data processing is distributed across the NDSA and pushed to where it is the most effective. Early processing will be ground based and gradually migrated to space. The BMC3 SIL and hosted BMC3 applications will provide capabilities that change depending on mission requirements. Additionally, BMC3 will support NAVWAR resilient operations and will expedite the delivery of threat information derived from different sensing platforms operating at the edge in support of the warfighter.

(U) SDA employs a capability-focused business model prioritizing speed and lower cost by harnessing commercial space systems development to achieve cost-effective proliferation and enhanced resiliency of space architectures. The objective is to rapidly evolve development processes and field capability on a significantly faster timeline than traditional space systems acquisition. In pursuit of this objective, SDA has procured Space Vehicles (SV) from multiple sources, in multiple configurations, to operate in an integrated fashion through a common ground system. Operation of the T1TL constellation and future capability layers and tranches will be conducted from two redundant, geographically-separated, Government-owned and Contractor-operated (GOCO) SDA Operation Centers (OC) via globally dispersed ground terminals. Figure 1 depicts the T1 capability-based approach designed to accelerate kill chain functions from space. The BMC3 AppFac Contractor will work closely with Operations and Integration (O&I) for the implementation of the BMC3 capability.

Distribution Statement A: Approved for public release. Distribution is unlimited. 3

Figure 1 (U) Tranche 1 Operational View

1.2 (U) Definitions

(U) This Statement of Work (SOW) and Technical Requirements Document (TRD) outlines the requirements for the BMC3 Application Factory & Integrator contract. Requirements identified as Contractor Requirements indicate contract deliverables, tests, and other work to be performed by the Contractor. Requirements identified as System Requirements apply to the BMC3 Application Factory and SIL.

(U) Within this document, “Contractor” always refers to the BMC3 Ecosystem Lead contractor team awarded the contract for the BMC3 Application Factory & Integrator work package.

Associate contractors, including examples provided below, will be referenced by name.

SVV: Space Vehicle Vendors O&I: O&I contractor Developer: BMC3 Application Developer

(U) Within this document a unit of time (e.g., days, weeks, etc.) refers to calendar days, unless explicitly stated as “business” time. Calendar time is inclusive of weekends, whereas business time is exclusive of weekends. Hence, 10 calendar days from Monday would be the Thursday of the following week, and 10 business days from Monday would be the Monday of the second following week.

(U) A comprehensive list of definitions is provided in Appendix A. A comprehensive list of Acronyms is provided in Appendix B.

Distribution Statement A: Approved for public release. Distribution is unlimited. 4

1.3 (U) Normative Text

(U) The following conventions apply for the normative specifications in this Statement of Work:

1. (U) The words ‘shall’ and ‘must’ indicate a binding and verifiable specification (when conflicts arise, table entries take precedent).

2. (U) The word ‘should’ indicate an optional, but desirable, specification.

3. (U) The word ‘may’ indicate an optional specification.

4. (U) The words ‘is’, ‘are’, and ‘will’ indicate statements of fact.

1.4 (U) Scope

(U) The BMC3 Ecosystem will establish the facilities and processes necessary to rapidly deploy software to the NDSA. The BMC3 Ecosystem is made up of various elements provided by multiple contracts. These include the:

(U) Battle Management Command Control and Communications (BMC3) Application Factory (AppFac): A DoD DevSecOps Reference Design 1.0 - compliant Continuous Integration / Continuous Deployment (CI/CD) environment providing support for achieving an SDA Authorizing Official (AO) continuous-Authority-To- Operate (cATO) decision. The AppFac is used to produce and sustain secure software used in the BMC3 ecosystem.

(U) Secure Interoperable-middleware Layer (SIL) a hardware abstraction layer providing a common application programming interface (API) and security infrastructure to all BMC3 applications running in each BMC3 module and possibly in BMC3 Ground hardware. The Contractor will determine if the BMC3 Ground HW needs to run the SIL.

The SIL will be produced and validated by the AppFac.

(U) BMC3 Applications created by various contractors to be tested and certified through the AppFac, and running on the SIL on each BMC3 module. *

(U) The BMC3 Modules onboard SDA SVs. The initial scope for this effort covers 126 modules split evenly between three SVVs (currently on contract). For T1, only the Transport Layer will carry BMC3 Modules. *

(U) A BMC3 Community of Interest (CoI) comprised of experts from various organizations and programs (e.g., DARPA, PEO BMC3, XVIII ABN Corps, APNT/S- CFT, NIWC, and mission partner contractors). *

(U) An environment that supports frequent interaction with the aforementioned CoI as a means of identifying new capabilities that require development. These interactions and observations are made without interrupting current operations.

(U) A tiered integration and test environment that ensures BMC3 applications function properly before they are uploaded to the constellation (BMC3 Application Test Laboratory (BATL), Sandbox and Canary Ops). BMC3 applications will be tested within the BMC3 Sandbox and Canary Ops prior to deployment in the operational environment. **

Distribution Statement A: Approved for public release. Distribution is unlimited. 5

A BMC3 Ground solution for distributed ground operations to compliment the on-orbit BMC3 capabilities.

* Out of Scope for this contract – provided for informational purposes.

** A joint effort between the O&I vendor and this Contract.

(U) The Contractor’s efforts are central to the execution of NDSA mission capabilities. The Contractor’s primary responsibilities will include:

(U) Implementing a Development, Security, Operations (DevSecOps) environment that is equivalent to the Navy’s Overmatch Software Armory (OSA) capabilities requirements (if the Contractor chooses not to use the GFX OSA CI/CD environment).

(U) Implementing DevSecOps Pipelines for application developers.

(U) Developing a SIL that hosts future SV applications. The SIL implements an open

API that enables efficient development of applications and a secure operating environment for vendor specific BMC3 modules.

(U) Integration, testing, and certification of externally developed BMC3 applications.

(U) Collaboration with O&I for transitioning functionality from ground to space as

BMC3 applications are tested and deployed.

(U) Troubleshooting BMC3-related anomalies and coordinating BMC3 functionality with the O&I Team.

(U) Monitoring and controlling the implementation of the hardware and software.

This includes collaboration with the Warfighters and other stakeholders on the development of future capabilities.

(U) Design, development, integration, testing, operation, maintenance, and sustainment of the Sandbox system simulation environment within O&I HITL/SITL facilities that includes the SV-Contractor provided Hardware-in-the-Loop (HITL)/Software-in-the-Loop (SITL) for all NDSA segments and components.

(U) Providing BMC3 systems engineering leadership for resolving inter-SV technical issues.

(U) Developing, validating, and providing bills of materials and assembly instructions to create functionally equivalent BMC3 hardware emulators from commercially available parts. The emulators will support external BMC3 application contributor software development and test.

(U) Additional areas of responsibility include software supply chain, software assurance, integration into a Zero Trust Architecture, collecting development metrics, implementation of automated quality gates and/or manual processes where quality gates are not automated, and monitoring configuration drift.

(U) The Contractor will need to work closely with the Operations and Integration (O&I) contractor team. The evolution of the NDSA will be a gradual transition to more autonomous

Distribution Statement A: Approved for public release. Distribution is unlimited. 6 capability being executed by both space and ground assets to enhance warfighting capability and decision making. SDA has defined mission phases which dictates when various capabilities are present. The “when” is really milestone accomplishment based versus specific schedule dates.

Post launch, T1 enters Launch and Early Operations (LEOps) prior to entering nominal operation phases defined as “Crawl”, “Walk”, and “Run”.

Crawl is the initial phase of Nominal Operations; only intra-contractor optical cross-links exist in space – inter-contractor links are established through a Ground path; network management is primarily conducted by SV contractor-delivered ground systems (NOVAs). During this phase, the BMC3 Factory will be established and completing its integration with O&I, application development is likely to have begun, but no uploads to orbit have occurred.

Walk is defined by integrated network management conducted by the O&I contractor-delivered ground system SUPERNOVA, providing a fully-networked constellation enabled by full availability of in-plane and cross-plane links in space. During this phase, BMC3 applications are being developed and tested in Canary Ops. The transition from Walk to Run occurs when BMC3 demonstrates network management via BMC3 Canary Ops.

Run is defined as integrated network management and select mission management functions performed by distributed BMC3 modules on each SV and at SDA Space Network Operations Centers (SNOC) as applicable.

Figure 2 (U) T1 Mission Phases and expected contractor responsibilities during Mission Phases

(U) Cross-coordination with other SDA Contractors, “Associate Contractors” is essential for the success of the NDSA; Associate Contractors include SV contractors, BMC3 Application

Distribution Statement A: Approved for public release. Distribution is unlimited. 7

Development contractors, and the O&I contractor. The Contractor is expected to work with Associate Contractors for the development, test, and integration of BMC3 applications into NDSA operations. In this capacity, SDA envisions that the Contractor will shepherd BMC3 Application Development teams through the AppFac DevSecOps process and pipeline.

(U) The Contractor is responsible for the coordination, installation, and integration of BMC3 hardware and software in the operations centers. The Contractor will keep the O&I contractor abreast of development efforts because O&I owns and manages NDSA integration processes.

Successful integration occurs when application development teams submit successfully tested, certified and approved applications to repositories inside the O&I facilities. At this point, applications will be nominated for Sandbox testing, where use cases can be tried using real-world data on flight representative BMC3 Modules.

(U) The operator training curriculum will be developed by the Application Developer who will coordinate with the Contractor and O&I for scheduling and format. As the user of BMC3 applications, the O&I contractor is expected to provide user feedback to the Sandbox (ground testing) and Canary Ops (flight testing), and send this feedback to the Contractor, who will collaborate with the Application Developers for product improvement. Figure 2 is a notional depiction of the relationship between the O&I systems and the BMC3 AppFac.

Figure 3 (U) BMC3 Development Ecosystem

(U) The Contractor is the program office focal point for all BMC3 application development and will support the O&I contractor with their responsibilities for overall operations system integration, test and operation of BMC3-developed SIL and Applications. In this role, the Contractor will monitor, evaluate and control BMC3 application-level interfaces, data models

Distribution Statement A: Approved for public release. Distribution is unlimited. 8 and application interdependencies and support the management of system level risks, issues, and opportunities. The Contractor will ensure that BMC3 system and mission requirements are verified and validated, that end-to-end system operational performance is acceptable, perform maintenance, and coordinate sustainment activities with O&I mission plans and scheduling.

(U) The Contractor will execute industry best practices for system development and operations such as those defined in INCOSE SEBoK.

2 (U) BMC3 Program Management

2.1 (U) Program Management

(U) This section establishes the Government’s minimum expectations for the Contractor program management (PM). Implementation and execution of sound PM practices increases the likelihood that the system meets the specified requirements while adhering to cost and schedule constraints. The Contractor is responsible for implementing and following necessary processes to guide and manage all aspects of BMC3 contract execution and ensure successful delivery of all end items. The Contractor has an obligation to inform the Government of known risks and issues, and associated mitigations or risk reduction plans for all contract activities. Program and business management reviews, and other management meetings as requested, will be attended by appropriate Government and support representatives throughout the development lifecycle. A minimum set of program management, systems engineering, and functional events and deliverables are specified in this SOW document. Further systems engineering, development and test reviews are expected to occur where appropriate per the Contractor-developed Integrated Management Plan (IMP).

(U) The Contractor shall perform work in a team-based Agile environment while delivering the high-level requirements and capabilities specified in this SOW. SDA will provide a Product Manager to work together with the Contractor team to develop and estimate user stories and establish acceptance criteria. These acceptance criteria will specify expected functionality for a user story, as well as any non-functional requirements that must be met in the development of the story. The SDA Product Manager, supported by subject matter experts and business analysts, will determine whether acceptance criteria have been satisfied.

(U) The IMP will be used to guide and deliver all necessary aspects required for development, operation, and sustainment of a cATO capable Application Factory and SIL capability. To support the IMP, the Contractor will develop and maintain an Integrated Master Schedule (IMS) and an Agile product roadmap. These products will provide a value-driven delivery schedule/development cadence for when new or enhanced capabilities will be delivered, as well as demonstrations of executable and operational code/features/functions. When building their IMP, the Contractor shall coordinate and evaluate stakeholders’ plans, schedules, and needs to identify disconnects between programs, develop closure plans, and work with stakeholders to

Distribution Statement A: Approved for public release. Distribution is unlimited. 9 resolve issues. The Contractor shall also support the SDA Engineering Review Board (ERB) process by continuously reviewing and updating factory artifacts to ensure their contents are current and their priorities are accurate.

(U) There are several enablers to DevSecOps focused on the rapid maturation of software from initial concept to deployed capability and continued improvement. These enablers include the integration and automation of various tools for the planning, building, testing, deployment and monitoring for software. The common thread running through the entire process is configuration management of software artifacts and data generated during the development process, including the software bill of materials (SBOM), that shows that the software does what is expected and its cyber risk is quantified. The Contractor shall establish a Configuration Management Plan (CMP) that identifies all the critical items whose configuration is tracked and establishes a lightweight process to manage them, leveraging the tools provided in the AppFac to the maximum extent possible. In addition to the products generated in the AppFac, the Contractor shall manage data resulting from reported anomalies and other operational data provided by O&I and partner organizations.

(U) The Contractor program management activities shall include the events outlined in section

2.1.0.1. The Kick-off meeting and System Requirements Review (SRR) are important events to ensure the Contractor and Government are ready to proceed with the Application Factory and SIL development. After these events, the Government will use monthly Program Management Reviews (PMRs) and quarterly Incremental Design Reviews (IDRs) to oversee and provide formal cost, schedule, and performance input. Additionally, the Contractor’s management processes shall include Agile management reviews and events, which are to be outlined in the contractor’s Integrated Management Plan.

(U) A key component of the program management activities is the Contractor’s Risk and Opportunity Management Plan (ROMP). The ROMP will define the process used by the Contractor and Subcontractors to manage Risks and Opportunities to the program. Opportunities and Risks with associated burn-down plans are reviewed within the PMR and/or IDR to track ongoing status. Specific attention is focused on risks with a high a probability of occurrence and/or severe consequence(s), but all risks and opportunities are reviewed.

(U) As BMC3 Ecosystem Lead, the Contractor shall participate in milestone reviews and other NDSA activities to maintain situational awareness and ensure interoperability with other aspects of the NDSA. This involvement may be limited by Associate Contractor Agreements, however, with the SDA Product Manager’s coordination, there will be efficiencies realized by the Contractor attending O&I’s system engineering and planning activities (TBX) where appropriate.

(U) The Contractor shall maintain GFX and Giver/Receiver actions and activities for the program. The Giver/Receiver information will be a critical communications tool for the SV

Distribution Statement A: Approved for public release. Distribution is unlimited. 10 contractors, external partners and the Contractor during this effort. The Program Protection Implementation Plan is also discussed in this requirement table and expected to be an initial item on the Giver/Receiver list coupled with the Government-provided Program Protection Plan

(PPP).

2.1.0.1 Program Management Contractor Requirements

ID CDRL Requirement

This Table is Unclassified

PM_CTR_01

x (slides and artifacts)

The Contractor shall coordinate and conduct a kickoff meeting with Government participation no later than (NLT) 30 calendar days but targeting 15 calendar days after Authorization To Proceed (ATP), with the following items as the minimum review content:

- Initial Release Planning Review

- Infrastructure Review

- Facilities Status

- Risk & Opportunity Management Plan (Draft CDRL)

- Staffing Status

- Long-Lead Item Status

- Government Furnished Property (GFX) Inventory

- Integrated Management Plan (Draft CDRL)

- Integrated Master Schedule (Draft CDRL)

- Associate Contractor Agreement (ACA) Plan

- Organizational Conflict of Interest (OCI) Plan

- Contract Work Breakdown Structure and Work Breakdown Structure

Dictionary (Draft CDRL)

- Software Bill of Materials (SBOM) (CDRL)

- Subcontract status

PM_CTR_02

As a part of program kickoff, the Contractor shall participate in post-award orientation activities convened by the contracting activity or contract administration office in accordance with FAR Part 42.5.

Distribution Statement A: Approved for public release. Distribution is unlimited. 11

ID CDRL Requirement This Table is Unclassified

PM_CTR_03

x (slides and artifacts)

The Contractor shall coordinate and conduct an System Requirements Reviewmeeting with Government participation no later than (NLT) 60 calendar days after Authorization To Proceed (ATP), with the following items as the minimum review content:

- AppFac_SIL Product Roadmap

- Data Rights Plan (CDRL)

- Facilities Status

- Risk & Opportunity Management Plan (CDRL)

- Associate Contractor Agreements

- Integrated Management Plan (CDRL)

- Integrated Master Schedule (CDRL)

- Configuration Management Plan (CDRL)

- Contract Work Breakdown Structure and Work Breakdown Structure

Dictionary (CDRL)

- Software On-boarding Plan (DRAFT CDRL)

- Change Management Plan (CDRL)

- AppFac Enterprise Dashboard

PM_CTR_04

x (slides and artifacts)

The Contractor shall coordinate and conduct Incremental Design Reviews (IDRs) with Government participation every three months after ATP, with the following items as the minimum review content:

- AppFac_SIL Product Roadmap

- Integrated Master Schedule (CDRL)

- Software Onboarding Plan (CDRL)

- Software Development Playbook (CDRL)

- AppFac Enterprise Dashboard

- Software Bill of Materials (CDRL)

- BMC3 Mission Application Integration Status

For each IDR, the Contractor shall develop and submit draft materials, to include presentation material and all associated deliverables, 10 calendar days prior to the IDR for draft, 2 calendar days prior for “as presented” and 14 calendar days post for “final.”

Distribution Statement A: Approved for public release. Distribution is unlimited. 12

This Table is Unclassified

PM_CTR_05

x (slides and updated artifacts)

The Contractor shall coordinate and conduct Program Management Reviews with Government participation monthly after SRR, with the following items as the minimum review content:

- Contract Funds Status Report (CDRL). The CFSR reporting elements shall be by Contract Line-Item Number (CLIN) / Sub-CLIN Levels and reconcilable and traceable to the Contract Work Breakdown Structure (CWBS).

- Integrated Master Schedule (CDRL)

- Program Risk and Opportunity Status

- Technical Performance Measures

- AppFac tool and license usage statistics

- AppFac Enterprise Dashboard

- Giver/Receiver List. The Contractor shall coordinate with SDA and external partners for all external dependencies, including need dates and commitment dates.

- Requirements Verification Status. The Contractor shall maintain traceability across the IMS, this Statement of Work, and CWBS.

For each PMR, the Contractor shall prepare and deliver PMR presentation materials to support the review NLT one business day prior to conducting each PMR.

PM_CTR_06

The Contractor shall coordinate and conduct Agile Management events in coordination with the SDA Product Manager to ensure continuous feedback between the Government and Contractor teams. These events will be baselined in the Contractor IMS.

Examples of such events include but are not limited to the following:

- Release Planning Review

- Iteration Planning Review

- Release Backlog Review

- Iteration Backlog Review

- Iteration Retrospectives

PM_CTR_07

The Contractor shall, as BMC3 Ecosystem Lead, support NDSA events to the extent permitted by the Associate Contractor Agreements. Examples of such events include:

- Space Vehicle Vendor milestone reviews

- O&I Contractor milestone reviews

- BMC3 Application developer software development milestone events

(e.g., Kick-off meetings)

- SDA Engineering Review Boards

PM_CTR_08

The Contractor shall, as BMC3 Ecosystem lead, support and coordinate with the O&I contractor on the Verification and Test Reviews for the SIL and BMC3 software/firmware applications.

Distribution Statement A: Approved for public release. Distribution is unlimited. 13

This Table is Unclassified

PM_CTR_09

The Contractor shall, as BMC3 Ecosystem lead, support and coordinate with O&I on the Test Readiness Reviews (TRRs) for the SIL and subsequent BMC3 mission applications.

PM_CTR_10

The Contractor shall implement a Government-accessible, live, AppFac Enterprise Dashboard. The Contractor shall tailor the AppFac Enterprise Dashboard through continuous discussion and feedback with the SDA Product Manager. The AppFac Enterprise Dashboard information requirements are referenced throughout this SOW, and include at a minimum DevSecOps pipeline metrics such as:

- Technical debt

- Test failures

- CVE counts

- Tool usage

- Resource utilization (on-prem or cloud)

- Number of active licenses being utilized per tool

PM_CTR_11 x

The Contractor shall develop and implement a Software Development Playbook. The Contractor may reference the Overmatch Software Armory playbook (in the Bidder’s library) as an example of an acceptable playbook for implementing CI/CD.

PM_CTR_12 x

The Contractor shall develop and deliver a tailored Software on-boarding plan to support the achievement of a continuous ATO (cATO) for the Application Factory. The software on-boarding plan shall be delivered at SRR with updates as required. A fully mature product is expected with the first release of the SIL. The software on-boarding plan shall, at a minimum, include:

- Description of processes and entry and exit criteria that will be executed to certify and bring new tools, hardened containers, hardened virtual machines, and services into the Application Factory by developers of BMC3 applications

- Define the path for BMC3 hardware and software artifacts to receive a Certificate to Field

- Direction to address Cloud Native Applications, Lift and Shift Applications and Re-factored Applications to include a measurement of technical debt

- BMC3 Mission Application Developer prerequisites and necessary training on the BMC3 Application Factory’s DevSecOps processes and services

Distribution Statement A: Approved for public release. Distribution is unlimited. 14

PM_CTR_13

The Contractor, as BMC3 Ecosystem Lead, shall participate in associate contractor Risk Management Boards or equivalent for system-wide risk evaluation, and review risks for impacts, recommend new risks if needed, and report on problems with risks outside the associate contractors’ control.

• At Crawl – Attendance NOT required, Contractor will be notified of important outcomes

• At Walk – Contractor shall attend for SA only

• At Run – Contractor shall fully participate

PM_CTR_14 x

The Contractor shall develop, deliver and maintain a Software Bill of Materials (SBOM) consisting of an explicit inventory of all items in a software product. At a minimum, the SBOM will contain:

- Open-source components in the codebase

- Third-party components in the codebase

- License information governing the components in the codebase

- Versions of components in the codebase

- Patch status for components in the codebase

PM_CTR_15 x

The Contractor shall develop, deliver, and maintain the BMC3 AppFac_SIL product roadmap and Integrated Master Schedule (IMS). The Contractor shall support these artifacts with supporting rolling wave planning information to identify external dependencies, integration specific tasks, programmatic interfaces, system task inter-relationships, iteration and demonstration cadence, reviews, milestones and deliverables, and clearly identified primary and secondary critical paths to key delivery dates. The Contractor shall use the product roadmap to organize the product backlog, prioritize work, and ensure that the appropriate capabilities are being delivered at the right time. The Contractor shall only update the product roadmap and/or the IMS after consultation with the Government Product Manager at an appropriate review event.

PM_CTR_16 x

The Contractor’s Data Rights Plan (DRP) shall maintain an updated explicit listing of all Commercial Off the Shelf (COTS)/NDI components (technical data, software, or hardware), their functionality, and their proposed use in the system.

Distribution Statement A: Approved for public release. Distribution is unlimited. 15

PM_CTR_17

The Contractor shall enter and deliver mutually agreed upon and countersigned ACAs with the O&I vendor, and relevant commercial entities supporting the NDSA within 60 days of contract award, or 60 days of new commercial entities entering contract in support of the NDSA. List of ACAs will be part of the Bidder’s library.

PM_CTR_18 x

The Contractor shall develop a Configuration Management (CM) Plan to be delivered at SRR and updated monthly thereafter. The CM Plan defines the program’s structure and methods for:

- identifying, defining and baselining Configuration Items (CI),

- controlling modifications and releases of CIs,

- reporting and recording status of CIs and any requested modifications,

- ensuring completeness, consistency and correctness of CIs,

- controlling storage, handling and delivery of the CIs

- maintaining a repository of secured CIs for use by BMC3 application developers.

PM_CTR_19 x The Contractor shall provide a draft Program Protection Implementation Plan within 60 days of receipt of the SDA Program Protection Plan (PPP) and an updated version by IDR #2.

PM_CTR_20

The Contractor shall manage the activities conducted under this effort to develop the BMC3 Ecosystem according to the specified requirements listed in the Contractor and System Requirements tables enumerated in this SOW.

2.1.1 (U) BMC3 Program Schedule Overview

(U) The following figure defines the notional top-level BMC3 Program Schedule. This schedule is used for program overview reference. Specific dates are likely to move as additional program definition occurs.

Figure 4 (U) Notional BMC3 Program Schedule

Distribution Statement A: Approved for public release. Distribution is unlimited. 16

3 (U) Application Factory DevSecOps

(U) The SDA BMC3 Application Factory (AppFac) process for continuous, unified Development (Dev), Security (Sec), and Operations (Ops) (DevSecOps) will combine cultural philosophies, practices, and tools, increasing the SDA’s ability to deliver applications and services to the NDSA at high velocity. The SDA BMC3 AppFac DevSecOps integrates security throughout the DevOps process. The SDA BMC3 DevSecOps process complements, as shown in Figure 5, best practices for software assurance and cyber testing, shared infrastructure, security control inheritance, and improved work streams, providing application developers with a streamlined CI/CD path. Enabling DevSecOps with the BMC3 AppFac process lowers the operational community’s risk and significantly improves delivery times for emerging capabilities.

Figure 5 (U) BMC3 DEVSECOPS DIAGRAM

(U) To ensure DevSecOps compliance of application development pipelines, the Contractor SME services provide knowledgeable support for BMC3 Application developers throughout the BMC3 AppFac DevSecOps process to include:

(U) Application Migration - All applications developed outside of the AppFac DevSecOps processes will require cyber security accreditation evaluations and interoperability assessments by the AppFac. The core AppFac assessments during this portion of application ingest will be expected to be automated and supplemented with SME reviews.

(U) Application Transformation - A portion of the development team focus will be to assist new application developers in their decision making and understanding relative to application

Distribution Statement A: Approved for public release. Distribution is unlimited. 17 and SIL integration. This focus starts with API and Software Development Kit (SDK) development for the SIL and continues with SME integration guidance.

(U) DevSecOps Process Implementation - The AppFac teams' key responsibility is to define and operate a continuous integration/continuous delivery cycle, which includes infrastructure as code, security as code, containerization for configuration control and efficiency, automated build and test, and highly automated authorization processes to accomplish cATO.

(U) BMC3 Application Security - Implement best practices for data protection in-transit and at rest, system hardening, and secure operation management.

3.0.1 (U) DevSecOps Contractor Requirements ID CDRL Action Description

This Table is Unclassified

DSO_CTR_01 x The Contractor shall ensure that all BMC3 applications and SIL development complies with the Contractor’s BMC3 Onboarding Plan and Software Development Playbook.

DSO_CTR_02 The Contractor shall support the BMC3 Application developers with DevSecOps subject matter expert services.

DSO_CTR_03

The Contractor shall provide Application Migration support for BMC3 applications developed outside of the AppFac DevSecOps process including automated cyber security accreditation evaluations and interoperability assessments supplemented with SME reviews.

DSO_CTR_04 x

The Contractor shall provide Application Transformation assistance to new BMC3 application developers. This assistance shall include direction and guidance via the Software Onboarding plan, the Software Development Playbook and SME integration guidance.

DSO_CTR_05

The Contractor shall define and operate a DevSecOps CI/CD cycle so that the AppFac maintains a cATO when integrating externally developed BMC3 applications. This CI/CD cycle, at a minimum, includes:

- Infrastructure as code

- Security as code

- Containerization

- Automated build and test

Automated Authorization processes

DSO_CTR_06

The Contractor’s DevSecOps processes shall provide BMC3 Application data security through implementing data protection best practices including system hardening and secure operation management for data in-transit and at rest.

Distribution Statement A: Approved for public release. Distribution is unlimited. 18

ID CDRL Action Description This Table is Unclassified

DSO_CTR_07

The Contractor shall perform all of the REQUIRED activities identified in the DoD DevSecOps Fundamentals Guidebook:

DevSecOps Tools and Activities, Version 2.1.

3.0.2 (U) DevSecOps System Requirements

This Table is Unclassified

DSO_SYS_01

The BMC3 AppFac shall include all the REQUIRED tools provided in the DoD DevSecOps Fundamentals Guidebook:

DevSecOps Tools and Activities, Version 2.1, and the following PREFERRED tools:

- Asset Inventory Management

- Configuration Management Database (CMDB)

- Threat Modeling

- Data Modeling

- IDE Security Plug-ins

- Code Quality Review Tool

- Lint Tool

- Dependency checking /Bill of Materials checking tool

- Test Data Generator

- Test Management Tool

- Dynamic Application Security Test (DAST) tool

- Database Test Tool Suite

DSO_SYS_02

The BMC3 AppFac shall automatically record the baseline and changes of collected IT (i.e., hardware and software) assets in accordance with the CM Plan (Section 2) and RMF process (Section 8).

DSO_SYS_03

The BMC3 AppFac shall automatically report on an Enterprise Dashboard the following:

- Current software baseline (Auto-discovery)

- Artifact dependency mapping

- Utilization of development tools

DSO_SYS_04

The BMC3 AppFac shall provide an integrated Software Design environment that includes tools or services that support Model based system engineering, Requirements management, System architecture design, Module design, and Interface design.

DSO_SYS_05 The BMC3 AppFac shall collect user-configurable development performance metrics.

Distribution Statement A: Approved for public release. Distribution is unlimited. 19

This Table is Unclassified

DSO_SYS_06

BMC3 AppFac metrics shall include a DevOps Research & Assessment (DORA) performance measures and extensible for other (i.e., user-defined) performance measures.

DSO_SYS_07 The BMC3 AppFac shall support Role Based Access Control

(RBAC).

4 (U) Application Factory Operations

(U) BMC3 AppFac operations consists of a hybrid team of Government, military and contractor personnel focused on facilitating the BMC3 ecosystem. The DoD Enterprise DevSecOps Reference Design v1.0 describes the foundation of an ecosystem with three subsystems:

planning, software factory, and product operations. The BMC3 AppFac will provide the processes, infrastructure, and tools underpinning these subsystems for BMC3 application development and integration within the NDSA.

4.1 (U) Operations Environment

(U) The BMC3 AppFac environment may be comprised of a combination of Cloud-based and on-premises tools and capabilities that enable the BMC3 Application Test Lab (BATL).

Additionally, three SVV engineering development units (EDUs) are provided as GFE to be integrated into the AppFac environment and the three SVV EDUs installed in the O&I’s HITL/SITL environment (within the BMC3 sandbox). Each BMC3 application development team will have access to the BMC3 AppFac provided software development environment that includes an approved code repository and licensed tools. Customizable and standardized CI/CD process flows will be options within the environment. Part of the overarching responsibility of the Contractor in conjunction with the OSA operations team will be to continually help automate and modernize infrastructure and application pipelines to support continuous operational improvements. These responsibilities involve automating activities and workflows throughout the life cycle of code development. Tools within this testing and cybersecurity suite will need to meet standards set forth by the SDA Cybersecurity Team, in compliance with integrating the RMF process into the cATO environment. The AppFac will facilitate the development and test of unclassified and classified BMC3 applications within applicable DoD Impact Level (IL) environments.

Distribution Statement A: Approved for public release. Distribution is unlimited. 20

4.1.1 (U) Operations Environment Contractor Requirements ID CDRL Requirement

This Table is Unclassified

OPS_CTR_01

From the start of operations, the Contractor shall support the development of new capabilities and the certification of previously developed code.

OPS_CTR_02

The Contractor shall provide access to development and build management tools for BMC3 application development teams.

OPS_CTR_03

The Contractor shall provide access to testing, information, and software assurance tools for BMC3 application development teams.

OPS_CTR_04

The Contractor shall provide access to release management and container monitoring tools for application development teams.

4.1.2 (U) Operations Environment System Requirements

This Table is Unclassified

OPS_SYS_01

The Application Factory shall provide an approved code repository and licensed tools to facilitate application development, testing, and integration within DoD IL2, IL4, IL5 and IL6 environments.

OPS_SYS_02

The Application Factory shall provide a BMC3 artifact repository hosting service for the source code for all application assets under version control.

OPS_SYS_03

The Application Factory shall automate and modernize infrastructure and application pipelines to support continuous operational improvements.

OPS_SYS_04

The Application Factory shall provide a centralized configuration management service to store configurations across the platform.

OPS_SYS_05

The Application Factory shall provide an automated continuous integration and continuous deployment (CI/CD) pipeline.

OPS_SYS_06

The Application Factory shall provide a platform for application developers to view build processes and operational metrics.

Distribution Statement A: Approved for public release. Distribution is unlimited. 21

This Table is Unclassified

OPS_SYS_07

The Application Factory shall provide a capability for functional, interoperability, cybersecurity and resilience developmental testing (e.g., digital twin, system integration lab, HITL facility, etc.).

4.2 (U) Application Developer Support The BMC3 AppFac will support on-site and remote development teams. The SDA BMC3 AppFac will support application development teams initiating their development within the AppFac (on-site) by guiding and assisting the BMC3 application developers in establishing DevSecOps tool pipelines. However, any BMC3 application development team that utilizes another development environment (remote) may be responsible for providing their own tools and licenses as well as getting their development environment approved by the SDA AO. If a team has previously developed their applications in another factory environment, the BMC3 AppFac Field Service Engineer (FSE), working with the SDA operations team, will be responsible for helping assess, test and onboard this code so that it meets the security standards necessary for integration and deployment.

4.2.1 (U) Application Developer Support Contractor requirements ID CDRL Requirement

This Table is Unclassified

OPS_CTR_05

The Contractor shall support remote development teams and assess, test, and onboard their code and ensure integration and deployment.

OPS_CTR_06

The Contractor shall enable BMC3 developers to use AppFac development and security scanning tools.

OPS_CTR_07

The Contractor shall provide one TS/SCI cleared AppFac FSE permanently located at each SDA SNOC during normal working hours to plan and execute testing, training, maintenance, operate the BMC3 ground hardware and support NDSA operators

OPS_CTR_08

The Contractor FSEs shall be able to perform remote support of both SDA SNOCs from either location.

OPS_CTR_09

The Contractor FSEs shall support BMC3 Ecosystem

DevSecOps CI/CD from the SDA SNOCs.

OPS_CTR_10

The Contractor FSEs shall be trained and able to operate BMC3

Ground Hardware.

Distribution Statement A: Approved for public release. Distribution is unlimited. 22

This Table is Unclassified

OPS_CTR_11

The Contractor FSEs shall be trained and able to perform testing of applications in Canary Ops.

OPS_CTR_12

The Contractor FSEs shall be trained and able to operate BMC3 applications.

OPS_CTR_13

The Contractor FSEs shall support SDA O&I and coordinate with BMC3 App Developers during BMC3 Application anomaly response occurring within normal operations and/or Canary Ops.

4.3 (U) AppFac Operations Processes

(U) The Contractor will possess significant experience in DevSecOps process management, incorporate security in all phases of development, enable frequent deployment of software upgrades within a rapid development cycle and consistent with overarching Agile development processes.

4.3.1 (U) BMC3 AppFac Operations Processes Contractor Requirements ID CDRL Requirement

This Table is Unclassified

OPS_CTR_14

The Contractor shall train NDSA operators on BMC3 Applications before migration of applications to BMC3 ecosystem (Sandbox, Canary Ops, BMC3 Ground, and BMC3 on-orbit).

4.3.2 (U) BMC3 AppFac Operations Processes System Requirements

This Table is Unclassified

OPS_SYS_08

The Application Factory shall provide applications with access to a preproduction staging environment that will test integrations with platform systems and an orchestration vehicle to deploy into the BMC3 production environments.

OPS_SYS_09

The Application Factory shall integrate and test with production-representative infrastructure and platform services early in development.

OPS_SYS_10

The Application Factory shall implement a tool suite that automates development life cycles and automates manual

Distribution Statement A: Approved for public release. Distribution is unlimited. 23

This Table is Unclassified processes to include testing, self-assessment, and third-party validation.

OPS_SYS_11

The Application Factory shall run an automated pipeline and provide immediate feedback to BMC3 application developers of any pipeline failures.

OPS_SYS_12

The Application Factory shall follow a fail-fast approach and immediately terminate the build pipeline if any issues are discovered and alert the…