Resilient Software Systems Capstone

A strong, lethal military demands cutting-edge and resilient software to power every weapon and support system our U.S. warfighters depend on.

However, the Department of Defense’s (DOD) reliance on aging IT infrastructure, which utilizes security policies developed over the past 30 years, creates inherent vulnerabilities in its systems, ranging from legacy architectures to advanced weapon systems.

Meanwhile, threat actors are actively exploiting these vulnerabilities, targeting critical infrastructure, stealing sensitive military code, and reengineering sensitive systems to compromise national security.

In response, we have been developing powerful tools leveraging formal methods—a mathematically rigorous approach to software development that helps eliminate exploitable vulnerabilities before software is deployed.

Rather than testing software for vulnerabilities after it’s been built, formal methods use mathematical proofs to verify software behavior as it’s developed. This approach ensures software performs exactly as intended, making it inherently more secure.

Many of our formal methods tools have already transitioned to military services for further development and operational deployment. However, comprehensive cyber resilience requires urgent, broad adoption across the DOD.  

We’re partnering with each of the services via its Resilient Software Systems Capstone program to address this pressing need. The Capstone program comprises jointly funded projects on operational platforms aimed at assessing critical findings, including the level of resiliency, cost, time, and level of expertise required to adopt various formal methods capabilities.

Each project will run for approximately 24 months. Objectives include:

• Achieving inherently more secure software
• Accelerating the Authority to Operate (ATO) process
• Streamlining software development and testing
• Developing a “Best Practices Guide” to support broad adoption

The goal of the Capstone program is to fund the transition of DARPA-developed Resilient Software System tools to U.S. military services. Ultimately, by providing organizations within the DOD and defense industrial base a template, we anticipate that the Best Practices Guide will help jumpstart their efforts to incorporate resilient software tools into their platforms and development pipelines.

Resilient Software Systems Accelerator

We’re exploring additional pathways to support the transition of these critical tools, including the establishment of a Resilient Software Systems Accelerator.

The Accelerator incentivizes formal methods tool developers to partner with defense contractors by providing seed funding for projects like the Capstone efforts, but smaller in scope.

DARPA funding will support multiple 18-month projects that include an initial red team assessment of the DOD system vulnerabilities, the application of the formal methods tool(s), and a follow-on assessment to measure impact and level of effort.

Conclusions from the efficacy of the tool would be incorporated into the Best Practices Guide.

Learn more about formal methods

FAQs

I. Proposal Content and Format

1: At the Industry Day it was stated that the orals slide deck would serve as the final proposal. But then during the contracting discussion it was stated that something more like a traditional proposal document would be requested. Section 6.4 of the solicitation says that the invitation to proceed will include proposal templates and instructions. Section 7 then gives oral presentation evaluation criteria and also says the slide deck in English will be the full proposal. Will the oral presentation slides be the complete final proposal?
A: In accordance with the solicitation, the notification letter titled "Invitation to Proceed," will serve as the formal request for full proposal, to include comprehensive instructions what constitute a full proposal submission.

2. The solicitation package posted on Sam.gov includes various OTA templates. Are proposers expected to submit anything with respect to the templates with the abstract on 3 October?
A: No, the Invitation to Proceed will include information regarding proposal requirements.

3. Is additional information available on the DARPA pricing templates or cost volume contents?
A: In accordance with the solicitation, the notification letter titled "Invitation to Proceed," will serve as the formal request for full proposal, to include proposal templates.

4. For the abstract submittal, do we need to include Reps and Certs, Biosketch, or any other forms with the submission? Or is that only if/when we receive an invitation to submit a full proposal?
A: In accordance with Section 6.1 of the solicitation, Abstract formatting and content requirements are stated in Attachment A1, Abstract Template. Use of Attachment A1 is required in the development of abstract submissions. Information not explicitly requested in Attachment A1 will not be reviewed.

5. Can the abstract include an appendix with supporting documentation beyond the 5-page limit? For instance: an expanded version of a table that is summarized within the 5-page document. The question assumes that the material may not be reviewed, but that the interested reviewer may want the option to see more detail than is possible in the page limit. 
A: Per DARPA-PS-25-29 Attachment A1, Abstract Template, the page limit does not include the abstract cover sheet, table of contents, bibliography/technical papers, and security plan. 

6. Would an abstract be found non-conforming if a proposer does not provide the price breakdown table found in the abstract template if submitting an OTA FFP contract type?
A: In accordance with Attachment 1A, Proposers must include all information in this template to constitute a fully conforming abstract submission. 

7. Please clarify the required deliverables. Is it only the final report per 3.2.6, and nothing else?
A: It is more than just the final report. While Section 3.2.6 outlines the Interim Report, Final Report, RSS Guide Chapter(s), and Security Plans as deliverables, this section should be read in conjunction with the data rights information. The total deliverables are anticipated to be:

• Interim Reports (Monthly)
• Final Report (30 days after the period of performance ends)
• RSS Guide Chapter(s) (30 days after the period of performance ends)
• Special Access Program (SAP) Security Plan (30 days after contract award, if applicable)
• Collateral Security Plan (30 days after contract award, if applicable)

8. Will Government-supplied, high-side large language models be made available to projects? If not, can performers introduce the use of such models on existing high-side development infrastructure?
A: The Government will not be providing any large language models to performers. The use of any models on existing development infrastructure is up to the DIB performer and Formal Methods teams to determine amongst themselves. All “developmentinfrastructure” will need to be brought to the program by the proposing teams.

II. Technical Approach and Scope

1. If there is an existing red team set of details, can that substitute for the government red team step?
A: No. The solicitation explicitly states that a Government Test and Evaluation (T&E) team will conduct both the initial and final red team assessments. The program is designed to provide independent verification of improvements achieved through the application of formal methods tools.

2. Will the gov red team go to the platform providers' facility to do the red teamwork, or does the compute and software need to be provided external? / How flexible is the red team step in practice?
A: The solicitation specifies that the T&E team needs access to both the DoD-relevant software and the security tools. The solicitation does not definitively state where the red team assessment work will be conducted. The solicitation requires technical solutions to describe how support will be provided to the T&E team in configuring the formal methods tool, including libraries, dependencies, and other components in the initial and post-red team testing assessments.

3. DIB Software Criteria: What are the criteria for the DIB software system to be used in the program— e.g., does it have to be an accredited system? A POR? In any specific language? Does it have to be a certain size?
A: The solicitation targets critical DoD software systems including command-and-control systems, weapon guidance and fire control, communications infrastructure, autonomous platforms, encryption systems, and real-time embedded systems in aircraft, ships, and vehicles and the underlying development systems that are used to develop them such as compilers, code development suites, etc. Additionally systems such as critical infrastructure which the DoD relies upon are within scope such as control systems, powersystems, etc. There are no specific criteria regarding accreditation status, POR designation, programming language, or exact size mentioned in the solicitation. The focus is on DoD relevance and criticality.

4. How will FM tools and DIB codebases be provided to the red team?
A: The program leaves flexibility in how Formal Method tools and DIB codebases are provided to the red team. Setting up a cloud environment containing the Formal Method tools and DIB codebase and providing access to said environment for the Red Team to perform their assessment is a valid consideration. 

5. The PS states that "the expectation is that the proposed formal methods tooling will resolve some (or all) of the T&E identified vulnerabilities." from which we conclude that the initial red Team assessment will involve identifying vulnerabilities in the DoD-relevant software (SW). Will this be done using the "proposed formal methods tooling" itself, or using other "neutral" means?
A: The initial red Team assessment will involve identifying vulnerabilities in the DoD-relevant software (SW) which includes both formal methods tools proposed and open commercial tools that will allow for a measurement of the relative impact of the formal methods tools and how they improve over current best practices.

6. The T&E team must have access to the DoD-relevant SW. does this have to be the same extent as the FM developer has access to the DoD-relevant SW? or is an arrangement possible whereby T&E gets access to the software but not the compiler, the build process, etc. (likely not needed to evaluate the FM tools). This may make it easier for a DIB company to share the SW with T&E.
A: The T&E team must have access to the DoD-relevant SW. The solicitation does not specify the extent of access the T&E team has to have versus the Formal Methods developer. Regardless of approach the team must consider if they are able to deliver the requested measurements and best practices information. Proprietary information will remain with the incumbent developer.

7. Is geospatial forecasting of interest for this program, or to DARPA in general?
A: See answer to II. Technical Approach and Scope, number 3.

8. When does the first red team start? The program plan shows M3 where I assume that's the finish of Red Team #1.
A: The conceptual timeline in Figure 1 (referenced in Section 3.2.5) outlines key program milestones. The program is anticipated to start in December 2025; therefore, it is estimated the first red team to be in March 2026. Again, dates are conceptual and will be adjusted depending upon negotiated Agreement awards and the subsequent program kickoff date. The red-team phase is meant to allow the DARPA to ‘triage’ the findings and prioritize the order of remediation that fits the program schedule best but within the 18-month window. 

9. Are reusable end products of formal verification, e.g. seL4, in-scope as “security tools” for the purposes of this program? In other words, would evaluating the cost, time, and performance of integrating an seL4-based solution into a DIB system be in-scope proposal? 
A: The solicitation mentions that the RSS Accelerator program aims to drive broad adoption and deployment of formal methods tools across diverse sectors to create broad impact across multiple industries, technology platforms, software development processes, and varied application domains. As seL4 or other reusable products of formal verification fall under the goal of formal method tools, integrating them in DIB to evaluate cost, time, performance, etc. would be applicable to the program. (Inferred based on the program description but not explicitly stated).

10. Are only “security tools” developed under DARPA programs in-scope (e.g., capabilities from V-SPELLS, AMP, Provers, etc.), or are other tools also in-scope?
A: No, DARPA is open to a wide variety of tools that the company can use.

11. Some moderate amount of development on an existing formal methods tool is often necessary to fit the use case for a transition partner. How much effort/resources and time can/should be devoted to such needs? 
A: These resources and time would fall into the lessons learned that the RSS Accelerator is looking to gather information on as referenced in 3.2.2. Please also reference 3.2.4 for Program Measurements and Criteria information. It is up to proposing teams to determine if their tool is mature enough for this program.

12. Are tools and methods that diagnose and repair configuration errors in scope for this solicitation?
A: Yes, as long as these tools and methods rely on Formal Methods techniques and help drive broad adoption. 

13. Should the performers select a set of tools optimized for vulnerability detection for the initial red team assessment and a separate set of tools optimized for creating code without classes of vulnerabilities for use in the Applying Security Tools phase?
A: No, the solicitation describes using the same formal methods tools throughout the entire process. The T&E team uses the performer's tool(s) to identify vulnerabilities in the initial red team assessment, then the performer applies those same tools to remediate the vulnerabilities. The final red team assessment then uses the same tools to measure the effectiveness of the changes. The focus is on demonstrating how formal methods tools can be integrated and used to improve security. 

14. Will example implementations of the formal method be acceptable if they are not directly linked to an existing program?
A: In accordance with the solicitation, technical solutions should demonstrate how they can integrate formal verification tools into existing defense software development processes. 

15. Does DARPA expect the DIB organization to be currently engaged with a specific DoD system as per the provided guidance in the Abstract template, Section 3?
A: In accordance with the solicitation DARPA expects that the DIB organization, as part of the integrated team, will be actively working against a specific DoD relevant system.

16. Specifically for the DIB/ transition partner role, is there anything particular DARPA would like to see prioritized as part of the research?
A: Proposing teams may find it beneficial to have a strong broader adoption strategy.

III. Intellectual Property and Data Rights

1.The IP rights desires in Section 9 has: "Data rights: The Government desires all noncommercial software (including source code), software documentation, hardware designs and documentation, and technical data generated under resultant awards be provided as deliverables to the Government, with Unlimited Rights, as lesser rights may adversely impact the broad adoption of formal method tools". Is this desired only for the formal methods tools? Does the government expect any rights to the subject system, or is it sufficient that the T&E team is given access sufficient for its T&E role, but that the system is not a deliverable, and the use of DARPA funding to pay for modifications to the system do not result in any change of rights?
A: The Government does not anticipate receiving any proprietary information regarding the DoD relevant system.

2. The solicitation (and the Industry Day presentation) both said that content not requested in the abstract template will not be reviewed. Since the abstract does not request any IP Rights information, does this mean the IP information discussed in sections 9 and 10 of the solicitation are not to be included in abstracts?
A: While the Attachment 1A, Abstract Template does not explicitly state Data Rights or Intellectual Property in the form of written word, Section 5. Sustainability & Adoption Plans asks proposers to describe broader adoption strategies, which should include consideration of IP rights.

3. For non-commercial software, are the unlimited rights granted to the government required only during the RSSA project performance (i.e., 18 months) or is it for all time?
A: The duration of rights in data will be negotiated prior to Agreement award. Proposers are reminded the RSS Accelerator's primary mission is to drive broad adoption and deployment of formal methods tools across diverse sectors.

4. We may plan on using a commercial software tool that we would need to assert under a commercial license - is this allowable? Can you advise on how this type of IP assertion will be seen in terms of favorability (i.e., less favorable or least favorable)?
A: Using a commercial software tool requiring a commercial license is allowable but the solicitation states a commercial license is considered less favorable. An IP Assertion where the formal method tools require the user to purchase a proprietary license for all uses, is significantly less favorable.

5. Can tools with commercial licenses (e.g., MathWorks Simulink Design Verifier) be used? These require the user to purchase a license, but they are readily available and accessible to industry.
A: See answer to III. Intellectual and Property Rights, number 4.

6. Acknowledging the explicit emphasis on “open-source,” would a proposal that utilizes a closed-source tool be in-scope as long as key outcomes and identified best practices are reasonably transferrable to a comparable open-source tool? As an example, would using a commercial tool to achieve key security and resiliency properties in a DIB system be seen as in-scope, as long as the best practices for achieving those properties are also reasonably accomplishable using comparable open-source tools?
A: While the solicitation does not explicitly exclude the use of closed-source tools, the overall emphasis on open-source and the desire for broad adoption and scalability suggest that a proposal heavily reliant on closed-source tools might be viewed less favorably. A proposal using a closed-source tool could be in-scope if it clearly demonstrates how the key outcomes and best practices are transferable to comparable open-source tools. 

7. Section 3.2.6 (deliverables) does not mention software deliverables. However, section 9, data rights & IP states that DARPA expects software to be provide as deliverables. Please define the expectations (to included due dates) for software deliverables.
A: While Section 3.2.6 does not explicitly list "software" as a deliverable, the Government expects any data generated under resultant awards will document the entire formal methods tools process that will become a part of the RSS Guide Chapter(s), which is due 30 days after the period of performance ends. The Government anticipates the formal methods tools will remain under its existing licensing structure, with the exception to the data provided as part of the Best Practices Guide(s). Further, the Government does not anticipate receiving any proprietary information regarding the DoD relevant system. See Amendment 01, which addresses revisions to the Section 3.2.6, RSS Accelerator Anticipated Deliverables.

8. Is your data rights section talking about IP part of your evaluation of the abstract?
A: Yes, per Section 6.3 of the RSS Accelerator Program Solicitation, abstracts will be evaluated against 5 evaluation criteria to include broad impact.

9. What is the criteria for evaluating the data rights provided by offerors? 
A: The RSS Accelerator Program Solicitation links data rights specifically to “broad adoption of formal methods” thereby linking both Section 6.3, Abstract Basis of Evaluation and 7.1.2, Basis of Evaluation to criteria evaluating “broad adoption.”

10. Are the data rights negotiable?
A: Yes, the Government Agreements Officer reserves the right to negotiate directly with the proposer on the Award Articles (terms and conditions) prior to execution of the resulting OT agreement. 

11. What data rights are specifically asked of the industry partner, rather than the formal methods partner?
A: The Government requests software documentation, documentation, lessons learned, and technical data impacts by the formal methods tools generated under resultant awards be provided as deliverables to the Government, with Unlimited Rights, as lesser rights may adversely impact the broad adoption of formal method tools. Industry partners are encouraged to propose rights in data that enable wide adoption and significant impact across industries, defense technology platforms, and software development processes.

IV. Security and Personnel

1. Can a proposer submit an unclassified abstract but include a classified addendum that covers the exemplar system selection.
A: Yes, See Section 5.1 for classified submission requirements. 

2. As someone who is still in the process of obtaining a green card and currently holds citizenship with a foreign country, how likely is it that I could participate in this program if appropriate mitigation strategies are well justified under FRRBS.
A: Refer to Section 5 of the solicitation for questions surrounding foreign participation.

3. Can you please clarify if there are any restrictions to participate in the RSS accelerator for foreign nationals (and what they are)?
A: Refer to Section 5 of the solicitation for questions surrounding foreign participation.

4. Many formal methods and their tools have been developed or are being developed by non-US citizen researchers. Could DARPA clarify what is meant by the security challenges of foreign participation or prior foreign involvement in developing formal methods tools? Specifically, does this restrict the use of tools developed by non-U.S. citizens?
A: The solicitation does not explicitly prohibit the use of tools developed by non-U.S. citizens. However, it highlights the security challenges of foreign participation or involvement. These challenges primarily concern managing security risks associated with uncleared or foreign national formal method tool developers and academic team members. This concerns is directly related to potential vulnerabilities, backdoor, or supply chain risks that could be introduced through foreign involvement. Therefore, all submissions should demonstrate how they will mitigate these risks to ensure the security and integrity of the developed or integrated tools.

V. Miscellaneous/Administrative

1. Could DARPA provide information on the timeframe between receiving the Oral Presentation invitation and the potential date of the oral presentations? This will help proposers plan their travel logistics.
A: Oral presentations are tentatively scheduled for Nov. 5 - 7, 2025; however, these dates are subject to change. Proposers are reminded the Government is not responsible for travel costs.

2. Will a DIB company be considered deficient if it is not currently involved in software development or implementation for the DoD?
A: In accordance with Section 4.1 of the solicitation, all responsible sources capable of satisfying the Government’s needs may submit a technical solution. To that end, technical solutions should demonstrate how they can integrate formal verification tools into existing defense software development processes.

3. Will DARPA be the contracting entity or will it be another entity?
A: DARPA will be the contracting entity.

4. Are deliverables due within 30 days after the 18-month Period of Performance or within the final month of the Period of Performance?
A: Please refer to Section 3.2.6, RSS Accelerator Anticipated Deliverables.

5. Is the RSS Accelerator CUI guide available?
A: The CUI guide will be distributed to RSS Accelerator selected performers. 

6. Are proposers required to contribute cost sharing? If no cost sharing required, if a traditional contractor is going to submit a prime response, with a non-traditional defense contractor as a partner, can the prime contractor propose a cost reimbursable award?
A: Please see 10 U.S.C. § 4022, regarding cost share requirements. Any resulting Other Transaction for Prototype awards will be based on fixed payable milestones.

7. Can you apply if you have not had a contract yet, but if offered, can you take a parchment contract later by other government groups for buying products?
A: The solicitation encourages submissions from all responsible sources, including small businesses and non-traditional defense contractors. An entity that has not yet received an award from DARPA may submit against the solicitation. Please note, DARPA does not award parchment contracts, and the DARPA Resilient Software Systems (RSS) Accelerator program is not soliciting the procurement of products. Note, DARPAConnect offers free resources to potential performers to help them navigate DARPA, including, “Understanding DARPA Award Vehicles and Solicitations”, “Making the Most of Proposers Days”, and “Tips for DARPA Proposal Success”. Join DARPAConnect at www.DARPAConnect.us.

8. If I am a small business and have a product, can I apply to update and advance my technology and grow and evolve my technology?
A: The goal of the RSS Accelerator is not to improve existing Formal Methods tools but to drive the broad adoption and change the state of practice to leverage correct by construction techniques.

9. Is it permitted for a formal methods performer to be part of multiple submissions, each with a different DIB contractor on different systems, possibly bringing different tools to each system as is appropriate? 
A: The solicitation does not explicitly forbid a formal methods performer from being part of multiple submissions with different DIB contractors. However, each proposal will be evaluated on its own merits. Proposers should be mindful of key personnel proposed on more than one submission. Specifically, the level of effort a key personnel is spread across multiple proposals should be realistically and reasonably feasible and achievable if selected to perform on multiple efforts. 

10. Does DARPA have a preferred teaming structure? That is, would DARPA prefer that FM tools developers prime or sub to DIB companies who are functioning as the transition partner?
A: No, the solicitation only requires an integrated team where the DIB company and formal methods developer are distinct, separate organizations. It does not state a preferred prime/sub relationship.