HR001124S0005.pdf

Broad Agency Announcement

Enhanced SBOM for Optimized Software Sustainment (E-

BOSS)

INFORMATION INNOVATION OFFICE

HR001124S0005

December 11, 2023

TABLE OF CONTENTS

PART I: OVERVIEW INFORMATION

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

A. Introduction B. Background C. Core Technical Challenge, Hypothesis, and Approach D. Program Goal and Structure E. Technical Area 1 (TA1):

F. Technical Area 2 (TA2):

G. Schedule H. Metrics I. Deliverables J. Intellectual Property

II. Award Information A. General Award Information B. Fundamental Research

III. Eligibility Information A. Eligible Applicants B. Organizational Conflicts of Interest C. Cost Sharing/Matching D. Other Eligibility Criteria

IV. Application and Submission Information A. Address to Request Application Package B. Content and Form of Application Submission

V. Application Review Information A. Evaluation Criteria B. Review of Proposals

VI. Award Administration Information A. Selection Notices and Notifications B. Administrative and National Policy Requirements C. Reporting D. Electronic Systems E. DARPA Embedded Entrepreneur Initiative (EEI)

VII. Agency Contacts VIII. Other Information

IX. APPENDIX 1 – PROPOSAL SUMMARY SLIDE

PART I: OVERVIEW INFORMATION

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Information Innovation Office (I2O) Funding Opportunity Title – Enhanced SBOM for Optimized Software Sustainment (E-

BOSS)

Announcement Type – Initial Announcement Funding Opportunity Number – HR001124S0005 Catalog of Federal Domestic Assistance Numbers (CFDA) - Not applicable Assistance Listing Number – Not applicable Dates o Posting Date: December 11, 2023 o Proposers Day: December 13, 2023 o Questions Due: January 18, 2024 o Proposal Due Date and Time: January 30, 2024, 12:00 PM Eastern Time o Proposal Closing Date and Time: June 11, 2024

Program Objective: The E-BOSS program will develop Enhanced Software Bill of Material (eSBOM) metadata technology to enable rapid triage-and-remediation of vulnerabilities in software at scale.

Anticipated awards – DARPA anticipates multiple awards in technical area 1 (TA1) and one award in TA2. Most individual awards are anticipated to be under $4M to reflect the minimum viable program structure.

Types of instruments that may be awarded – Procurement contract or Other Transaction Agency contact o Points of Contact The BAA Coordinator for this effort can be reached at:

Email: E-BOSS@darpa.mil

DARPA/I2O

ATTN: HR001124S0005

675 North Randolph Street Arlington, VA 22203-2114

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

This publication constitutes a Broad Agency Announcement (BAA) as contemplated in Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016 and 2 C.F.R. § 200.203. Any resultant award negotiations will follow all pertinent laws and regulations, and any negotiations and/or awards for procurement contracts will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA.

The Defense Advanced Research Projects Agency (DARPA) is soliciting innovative proposals in the following areas of interest: compilers, linkers, loaders, and runtime design, build and runtime tool chains, reachability analysis, vulnerability triage and remediation, and software sustainment.

Proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, or systems. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

A. Introduction

Pervasive vulnerabilities in software deployed at scale pose a high risk to the United States and the global community. Without effective capabilities to rapidly triage and remediate, computing infrastructures are susceptible to attacks exponentially escalating in volume and diversity. For example, the notorious Log4Shell vulnerability—which allowed for remote code execution and was estimated to affect three (3) billion devices1—approached nearly one million attack instances within seventy-two (72) hours after the public disclosure of the vulnerability, with over sixty (60) different attack variants. By contrast, mitigation reportedly took twelve to seventeen (12-17) days on average2. This asymmetry does not bode well for computing infrastructures where vulnerabilities in popular software dependencies have become ubiquitous yet cannot be quickly remediated at the scale they are deployed.

Moreover, a global survey conducted three months after the start of the attacks revealed that 30% of deployments contained outdated code that had not been updated. Similar findings led the Cybersecurity and Infrastructure Security Agency (CISA) to characterize Log4Shell as endemic and likely to persist2 3. Notably, Log4Shell existed undetected yet widely deployed for eight (8) years. Similarly, ShellShock, another remote code execution vulnerability,4 was latent for twenty

(20) years. The capability for speedy response and proactive detection of devastating vulnerabilities is severely lacking.

Both of these deficiencies have the same root cause—the lack of effective cyber-reasoning methods and tools that could provide certainty as to whether flawed or sensitive code is actually

1 https://accelerationeconomy.com/cybersecurity/why-one-in-four-downloads-still-has-a-log4j-vulnerability/#:~:text=One%20year%20ago%2C%20the%20Log4j,that%20use%20Java%20were%20affected.] 2 Mehul Revankar, Qualys Study Reveals How Enterprises Responded to Log4Shell, Qualys, March 2022, https://blog.qualys.com/qualys-insights/2022/03/18/qualys-study-reveals-how-enterprises-responded-to-log4shell 3 Cyber Safety Review Board, Review of the December 2021 Log4j Event, July 2022, https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf 4 Shellshock (software bug), https://en.wikipedia.org/wiki/Shellshock_(software_bug) https://accelerationeconomy.com/cybersecurity/why-one-in-four-downloads-still-has-a-log4j-vulnerability/#:~:text=One%20year%20ago,%20the%20Log4j,that%20use%20Java%20were%20affected.] https://accelerationeconomy.com/cybersecurity/why-one-in-four-downloads-still-has-a-log4j-vulnerability/#:~:text=One%20year%20ago,%20the%20Log4j,that%20use%20Java%20were%20affected.] https://blog.qualys.com/qualys-insights/2022/03/18/qualys-study-reveals-how-enterprises-responded-to-log4shell https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf https://en.wikipedia.org/wiki/Shellshock_(software_bug) exposed and vulnerable, either during code development or deployment. At today’s infrastructure scales, these deficiencies are becoming untenable.

Executive Order (EO) 14028 recognizes the critical need to protect software supply chains plagued with widespread dependency risks5. EO 14028 creates a policy foundation for software component transparency in software supply chains by requiring a Software Bill of Materials (SBOMs) that specify the components and dependencies of a software product. This policy foundation must be supported by revolutionary technical foundations to be effective at the national infrastructure scale.

Enhanced SBOM for Optimized Software Sustainment (E-BOSS) aims to develop the capability to pre-empt or rapidly triage and remediate software vulnerabilities at infrastructure scale through revolutionary changes in software build chains and runtime systems that enhance and complement SBOM technologies. E-BOSS will enhance SBOM technologies with new types of metadata and cyber-reasoning algorithms to determine whether flawed or sensitive code is actually reachable and triggerable. These new cyber-reasoning capabilities will inform rapid mitigations (such as blocking attack payloads associated with the recovered or discovered vulnerability triggers at appropriate system interfaces and code paths) or program transformations that deny the execution of vulnerability-triggering payloads. Figure 1 illustrates the E-BOSS vision of the new metadata and cyber-reasoning technologies as an intrinsic part of software build systems, development toolchains, and Development, Security, and Operations (DevSecOps) pipelines. The E-BOSS vision will enable early mitigation of software vulnerabilities and optimize software maintenance and sustainment for security.

Figure 1: E-BOSS extracts rich metadata via build tools, implements early defense analysis during the development process, and provides cyber reasoning tools to perform rapid triage, trigger recovery, and remediation.

5 Executive Order on Improving the Nation’s Cybersecurity, The White House, May 12, 2021, https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

E-BOSS is structured to demonstrate the minimum viable capability for effective triage and mitigation at scale, with awards structured to be extensible if the minimum viable capability is successfully demonstrated during the program. Please see Section H Metrics for the program scoping and the relationship between the evaluation metrics and the ultimately desired capability.

B. Background

DARPA is seeking revolutionary advances in software build chains and runtimes to create the capability for rapid triage and remediation of software vulnerabilities at scale that enhance and complement emerging SBOM technologies.

Emerging SBOM requirements break new ground in software transparency and auditability.

The SBOM, envisioned by the EO 14028 on Improving the Nation’s Cybersecurity5 and supported by evolving standards under the guidance of the National Institute of Standards and Technology (NIST)6, National Telecommunications and Information Administration (NTIA)7, and Cybersecurity Infrastructure Security Agency (CISA)8, represents a significant advancement in the capability to triage software systems with known vulnerabilities. By codifying standard and mechanized ways to represent the software components and dependencies of a system, SBOMs can help the system’s owners to automate checking if a known vulnerability, in a particular version of a dependency, affects them. Vulnerability Exploitability eXchange (VEX) extensions to SBOMs aim to provide additional vulnerability assessments to help software asset owners make informed decisions about their risk/benefit tradeoffs.

Additional cyber-reasoning capability is needed for software triage at the national infrastructure scale.

When flaws are found in a popular software component, triage approaches based on SBOMs alone will face severe scaling challenges. As the flawed dependency will be flagged almost everywhere throughout the infrastructure, additional system-specific analysis will be needed to identify where the flawed dependency is actually vulnerable because it is reachable by attackers.

Vulnerable flaws must be triaged first. Moreover, analysis should shed light on how—and with what specific kinds of inputs—the flawed dependency is reachable, so that these trigger inputs can be effectively and efficiently blocked at the appropriate external or internal interfaces of the system.

Reachability and trigger recovery capabilities will enrich SBOM-enabled cyber-reasoning at scale.

Today, a baseline SBOM enumerates the parts that comprise a software product. SBOM’s enumeration of parts and dependencies offers visibility into software dependencies and security issues that affect them. However, as the famous systems engineering saying goes, a system is more than the sum of its parts. In particular, reachability of a flaw notoriously depends on how integrated or distributed components of a complex system fit together, how data flows through

6 https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1 7 https://www.ntia.gov/page/software-bill-materials 8 https://www.cisa.gov/sbom https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1 https://www.ntia.gov/page/software-bill-materials https://www.cisa.gov/sbom and between these systems components, and how these components can interact under various inputs.

These properties are not addressed by today’s baseline SBOMs, yet are urgently needed to respond to infrastructure-scale triage challenges involving ubiquitously deployed components. E- BOSS addresses this need.

C. Core Technical Challenge, Hypothesis, and Approach

Triage of code flaws at scale requires fundamental research breakthroughs.

Our current ways of building and delivering software make it formidably hard to reason about whether a code flaw or a sensitive code region is actually exposed to attacker-controlled inputs— and, if so, to what inputs. This is the key technical challenge for rapid mitigation and pre-emption of vulnerabilities at scale.

This challenge is known as the reachability and/or trigger-recovery problem because a code flaw becomes an exposed vulnerability only if it is reachable by hostile inputs that can trigger it.

Software flaws unfortunately abound, necessitating effective triage techniques to prioritize the limited resources available to fix or mitigate them. However, prioritization runs up against a hard computer science problem that is typically intractable.

In a distributed system with subsystems consisting of components that themselves have many library dependencies, the problem of reachability and trigger recovery grows exponentially, as a flaw is typically located several layers deep inside a component that is itself a few components away from the system’s attack surface. Program analyses that attempt to trace the code logic between the flaw and the system’s boundary must explore too many potential code paths and states, which is colloquially known as path and state explosion. Techniques to make the problem more tractable, such as program slicing, fail to provide the efficacy to analyze full systems. For example, program slicing envisioned backward traversal of a program from a point of interest, but was challenged by slices that were too large to process at the full program scale—and, although often successful at the function and unit scales, suffered from the path explosion at the whole-program scales. Similarly, symbolic execution techniques suffered from state explosion at moderate program scales.

Today’s analyses fail for lack of relevant information in the software deliverable.

A closer look at the path and state explosion obstacles reveals a common theme: today’s analysis algorithms at either source or binary level lack a “trail of breadcrumbs” in relevant information to retrace the likely paths from a code location of interest to the entry point(s) at the attack surface. Essentially, program analyses that attempt to look backwards lack key information to make the search tenable, and must deal with “flying blind” at many points. In particular, they must make a myriad of assumptions about how the execution path reaches the current point, with no hints inherent in the code, only to refute them eventually—but unfortunately, not quickly or otherwise effectively enough to avoid the workload explosion.

Today, this lack of relevant information is accepted as the natural state of the software deliverable. As a consequence, lack of support for program analyses at scale is also accepted as today’s natural state of the art (SOTA) for tools used to build and run software—including compilers, linkers, loaders, build systems, Continuous Integration and Continuous Delivery (CI/CD) tools, orchestration tools, and the like.

Successful at-scale triage requires re-thinking today’s software deliverables and tools.

A solution that overcomes the path and state explosion obstacles to triage at scale must disrupt current assumptions about the software build and runtime tool chains so that the previously intractable reachability and trigger recovery problems can be brought within reach of modern systems.

E-BOSS’ approach is to change software build chains, runtimes, and deliverables to make reachability and trigger recovery tractable and scalable with practical resources while still supporting the significant performance optimizations expected of SOTA compilers and linkers.

The boundaries of compilers and supporting tools have been fixed for decades. By loosening assumptions about these boundaries, E-BOSS will create the opportunity to discover how fundamentally different algorithmic and data structure choices could lead to systems much more amenable to pre-emptive, compositional, and post-factum analysis.

E-BOSS offers a new hypothesis and basis of confidence.

E-BOSS’ key hypothesis is that new metadata and algorithms added to a SOTA software tool chain will dramatically accelerate triage and remediation at scale. Specifically, it is hypothesized that new metadata and algorithms will control the path/state explosion enough to find and effectively block the flows and triggers of a vulnerability in multi-platform, multi-language software in days or hours rather than in months under practical space and performance trade-offs.

A rich source for the new metadata is compilers and linkers. While carrying out many and varied optimization tasks, the compiler already performs rich data and control flow analyses. The compiler already generates complex artifacts that serve as recipes for post-compilation transformations of the compiled binary code, such as Link-Time Optimization (LTO) and relocation. In addition, the compiler generates recipes for transforming the running program's binary memory state, such as the instructions associated with exception handling. These precise and robust post-compilation code and memory transformation recipes are packaged as metadata of the executable binary deliverable. Moreover, recent advances in LTO by both LLVM and the GNU Compiler Collection (GCC) toolchains suggest the practicality of saving dedicated Intermediate Representations (IRs) as a part of the software deliverable9.

The expressive power of these artifacts and transformations increases the confidence that SOTA build and runtime chains could also provide the symbolic ‘breadcrumbs’ to effectively trace back the paths from software flaw evidence to triggers and to overcome the key obstacle of rapid remediation at scale.

To deliver practical results, E-BOSS will leverage, enhance, and complement emerging SBOM standards.

9 https://www.phoronix.com/news/LLVM-Fat-LTO-Objects https://www.phoronix.com/news/LLVM-Fat-LTO-Objects

E-BOSS will enrich SBOMs with additional metadata to advance cyber reasoning about a system beyond a contextual sum of its parts. E-BOSS metadata enhancements will describe how integrated and distributed parts fit together in a complex system, how data flows through the various components, and how the parts interact. This new metadata will be captured in enhanced SBOMs (eSBOMs), giving rise to new reachability techniques capable of analyzing complex inter-component interactions, transfers, and transformations to derive triggers at speed and scale.

The ability to recover triggers improves the actionability of SBOMs because the input triggers themselves provide precise evidence of the ability to exercise detected vulnerabilities in a given configuration or setting. As SBOM and VEX standards are quickly evolving, E-BOSS will engage with CISA and NIST to ensure integration with planned processes, practices, and conventions. Strong proposals will facilitate these engagements.

D. Program Goal and Structure

E-BOSS will produce technologies and tools to enhance SBOMs with new types of metadata, enabling cyber reasoning for triage and remediation in large-scale deployments.

E-BOSS’ envisioned capabilities require novel methods for generating rich and high-fidelity eSBOM metadata during compilation, linking, loading, and other stages of the software lifecycle.

These envisioned methods must capture critical information for reachability and trigger recovery analyses, as well as for enabling effective mitigations such as trigger-blocking and post-compilation transformation of deployed binaries.

New metadata encapsulated in eSBOMs will enable novel algorithms for performant cyber reasoning tools that can be plugged into development build chains and integrated with DevSecOps pipelines. These automated methods will contribute to assuring integrity, maintainability, and sustainability of eSBOM-conformant software deliverables.

The program is divided into two Technical Areas (TAs). TA1 will focus on enriching state-of-the-art build chains with eSBOMs and cyber-reasoning. TA2 will focus on integration and cybersecurity sustainment evaluation.

The program aims to create a capability for large-scale deployments of software, up to the national infrastructure-scale deployments comprised of millions of compute nodes, as discussed in Section H Metrics. Proposals that do not offer detailed technical discussion of the approaches and architectures to achieve such scale may be considered non-conforming to this solicitation.

Please refer to Section H Metrics for the details of metrics and evaluation.

A proposal may only address a single TA. Although proposers may submit proposals for both TAs, proposers selected for one TA cannot be selected for another TA, whether as a prime, subcontractor, or in any other capacity from an organizational to individual level to avoid potential conflicts of interest between the TAs and to ensure the integrity of test and evaluation results. The decision of which TA proposal to consider for award is at the discretion of the Government. DARPA anticipates multiple awards for TA1 and a single award for TA2.

To facilitate the open exchange of information, performers will have Associate Contractor Agreement (ACA) language included in their award, which is described further in Section VIII.

The TA2 performer will be responsible for executing the E-BOSS ACA.

Proposers are encouraged to propose the minimum viable effort to meet program objectives.

Efforts to provide support for additional compiled languages and interpreted languages as compelled by the envisioned use cases of mitigation at scale should be structured as fully separable proposal options. In addition, include in both TA1 and TA2 proposals a three (3) month option for continued work at the same level of effort as the last 3 months of the program (see Section G Schedule). These optional add-ons may or may not be exercised at the sole discretion of the Government.

A Federally-Funded Research and Development Center (FFRDC), not solicited by this BAA, may be chosen to facilitate transition and apply TA1 tooling to Department of Defense (DoD) platforms. The FFRDC partner would lead the engagement with transition partners to inform the design of DoD-relevant eSBOMs and to lead the integration of TA1 capabilities with DoD platforms. If so, subcontractors performing under the FFRDC could not be selected for any portion of TA1 or TA2 in any capacity from an organizational to individual level.

E-BOSS emphasizes transition to open-source communities. Currently, adoption by open-source communities appears to be the only viable path forward for innovations in modern software development to be broadly accepted by industry, thereby also accelerating broad DoD use. As a result, intellectual property rights asserted by proposers are strongly encouraged to be aligned with open source/open architecture regimes. Factors restricting technology transition of proposed E-BOSS solution approaches such as reliance on proprietary components or trade secrets may be considered a weakness of the proposal. Proposed solutions which require the deliverable of proprietary intellectual property should also consider offering alternative data rights solutions that could meet the Government’s transition goals.

E. Technical Area 1 (TA1):

TA1 performers will focus on the generation of eSBOMs equipped with new types of metadata via extensions to compilers, linkers, loaders, runtimes and other relevant tools and environments;

and on developing cyber-reasoning tools that leverage eSBOMs to anticipate, triage, and remediate vulnerabilities. These tools will be integrated with modern software build chains (as depicted in Figure 1) and deployment pipelines to facilitate industry adoption of the underlying methodologies.

The eSBOM metadata is anticipated to include fine-grained information about control and data flows, aliasing, and inter-component interactions. Key to these new types of metadata is generalizing them to coherent sets and representations, and saving them alongside the software deliverables in a format intelligible to cyber-reasoning, testing, and mitigation tools.

Today, outcomes and artifacts of relevant analyses, even though often performed by compilers and linkers, are not cohesively managed and are discarded by build chains, being mistakenly seen as only relevant to specific and disparate performance optimizations. Yet at the same time, cybersecurity and automated code repair tools try hard to partially recover or heuristically guess the same information, at great computational expense and with unsatisfactory accuracy. TA1 will produce this information encapsulated in eSBOMs, in representations effective for use by cyber-reasoning and mitigations at scale. It is also anticipated that this information will be amenable for use by program analysis, compiler, and formal verification communities, who are similarly challenged by lack of relevant information in the traditional optimized-but-opaque form of the binary deliverables.

Mitigation approaches may include, but are not limited to, input filtering policies at respective communication boundaries and/or automated post-compilation program transformations that remedy reachability of flaws or repair flaws. All classes of mitigations effective at scale are in scope. Strong proposals will include a detailed technical discussion of the trade-offs of proposed mitigations, e.g., with regard to simplicity, nativeness to the system, performance, degrees of assurance, and other factors that may facilitate or impede industry acceptance.

The key fundamental research challenge of the envisioned eSBOM designs is to enable effective cyber-reasoning and early remediation, while allowing integration into modern build chains and runtime environments with performance, build time, and storage trade-offs acceptable at the same scale(s) that eSBOM enhancements seek to remediate. It is thus possible that a hierarchy of metadata and algorithmic complexity scopes may be required to enable an acceptable gradation of capabilities at various scales. Strong proposals would include a detailed technical discussion of such hierarchies, gradations, and trade-offs, and will discuss strategies to determine the minimal volumes of artifacts and computing overhead to enable analysis accuracy against compilation, runtime, and program size/storage trade-offs.

To enable pre-emptive or early remediation of compositional vulnerabilities such as Log4Shell and ShellShock as part of the software development process, strong TA1 proposals would envision and provide detailed technical discussions of equipping developers with non-burdensome ways to specify that certain data flow properties are intended or prohibited, and of effective cyber-reasoning capabilities to proactively warn developers if these properties are likely to be violated.

Strong TA1 proposals are expected to combine experience and expertise in compiler internals, software security, build systems, toolchains, program analysis, formal verification, and application binary interfaces (ABIs). Moreover, TA1 proposals should reflect strong expertise in practical compiler implementations to ensure compatibility with existing ABIs and runtimes of interest to the DoD. In particular, support of C/C++ runtimes is required; support of Java and/or JVM-based runtimes and other major programming language runtimes chosen with the view to support DoD use cases will strengthen the proposals.

TA1 performers will work closely with the TA2 performer to integrate their tools with the TA2 testbed. To facilitate adoption, build tools produced by TA1 performers must be amenable to automation within DevOps and DevSecOps pipelines.

F. Technical Area 2 (TA2):

TA2 will define a Program Concept of Operations (CONOPS) and design use cases that are both relevant to open-source communities as well as to DoD software factories. As an evaluator, the TA2 performer will assess the effectiveness of TA1 capabilities to achieve rapid triage, trigger recovery, and risk remediation via a sequence of challenges to exercise these TA1 capabilities at the relevant scales and environments. The TA2 performer will collaborate with transition partners and/or FFRDC partners to align the evaluation objectives and scenarios with the needs of the DoD.

To assist TA1 in preparing for evaluations, the TA2 performer will be responsible for constructing sample challenge tests every three (3) months leading up to evaluation events.

TA2 will establish a testbed for testing and evaluation, leveraging virtualization and simulation technologies if necessary, and will use this testbed to evaluate TA1 performers against program metrics. However, strong TA2 proposals must present detailed technical discussions of scaling this architecture to reflect infrastructure-scale environments (see Section H Metrics discussion for more detail). Leveraging existing testbed(s) is encouraged to reduce costs and minimize risk.

As an integrator, the TA2 performer will also incorporate TA1 tooling into the security analysis process in a DevSecOps pipeline. The TA2 testbed should be remotely accessible to TA1 performers.

Specifically, TA2 evaluations will be conducted on a testbed emulating distributed deployments of use case Software-Under-Test (SUT) with synthetic vulnerabilities and a variety of trigger payloads. TA2 will provide TA1 performers with static evidence of code flaws—such as a crash dump or evidence of command injection—and TA1 will need to determine if and how the flaw is reachable from the SUT’s attack surface. TA1 will use reachability analysis to recover the flow to the flaw from the attack surface and the trigger for the flaw at the attack surface. In addition, TA2 will inject code flaws into the software during the development process and test the efficacy of TA1’s verification tools to perform pre-emptive or early remediation.

Successful remediation will be evidenced by TA1’s ability to block the relevant classes of flows and triggers, under realistic assumptions about the software deployment mechanisms, native Operating System (OS) filtering mechanisms, and other common policy mechanisms available in production environments, which the TA2 testbed will emulate. It is expected that these assumptions will change as the size of the deployment grows from challenge to challenge, to reflect practices and tools commonly associated with deployments of that size, including management and automation tools that can be co-opted for the mitigations. Strong TA2 proposals will discuss these assumptions based on the experience of current production environments.

TA2 examples of flaws and vulnerabilities will cover broad classes of code flaws and related vulnerabilities and exploits, and will comprehensively test TA1’s ability to mitigate maximally broad practical variations of exploit payloads for a vulnerability. However, formally verifiable complete remediation of software errors or a generic bug-hunting capability, though desirable, are not in scope, as E-BOSS emphasizes rapid, effective remediation at scale.

In support of E-BOSS’s goal of enabling rapid triage and remediation, TA2 will also survey SOTA triage tools used for trigger recovery and reachability analysis. The reports will detail recent advances made to the available triage tools external to the program, the tools’ scalability, and emerging research in improving the analysis capability. This review will help assess how well E-BOSS is fostering innovation in those areas. An initial report will be provided at month 9, followed by a second report at month 18.

The TA2 performer will lead Integration events prior to each evaluation to test interoperability and preliminary capabilities (see Section G Schedule discussion for more detail).

Strong TA2 proposals should discuss how test harnesses will be created to automate testing. TA2 must describe the methodology used to obtain program metrics. Details on the test range10 architecture must include plans for broadening the scope to emulate cloud-scale distributed environments.

A strong TA2 performer is expected to have experience and expertise in vulnerability research, testing and evaluation, rapid vulnerability mitigation, as well as with modern software factory development and deployment practices such as DevSecOps. The test range will require system administrators to setup the architecture, and ensure proper configuration and maintenance of the infrastructure.

G. Schedule

The E-BOSS TA1 proposal period of performance (POP) is limited to a twenty (20) month duration. The Government does not anticipate TA1 performers will reach the E-BOSS overall metrics within the 20-month POP. TA1 proposers should indicate what metrics they will reach within this timeframe. The anticipated POP for TA2 is twenty-four (24) months. The Government will attempt to expedite the evaluation and award of TA2 so research may begin four (4) months before TA1 (months a-d in Figure 2). This preparatory period will allow TA2 time to stand up the initial testbed infrastructure, and for TA2 to work with Government teams to establish sample test problems. The testbed and a sample set of test problems are expected to be available to TA1 teams at month one (1) of their POP. Include in both TA1 and TA2 proposals a three (3) month option at the same level of effort as the last 3 months of the program for continued work towards the overall program goals which could be exercised immediately after the end of the TA POP.

There will be a TA2 only meeting soon after its award and then an E-BOSS TA1/2 kick-off meeting at the start of the program. The program Principal Investigator (PI) meetings will be held every six (6) months thereafter to facilitate program activities and to assess progress towards the solution via performer briefings, technical discussions, and demonstrations. PI meetings will focus on open technical exchange. The goals of the PI meetings will be to: (1) review and share innovations/accomplishments of the E-BOSS program; (2) discuss program challenges with potential solutions; (3) review and discuss plans for technology demonstrations and E-BOSS evaluation/challenge exercises; (4) review and discuss results from meetings and

10 In this context, we are using ‘test range’ and ‘test bed’ interchangeably.

events conducted prior to and after the tests and evaluation/challenge exercises; (5) demonstrate prototypes to potential transition partners; and (6) plan for the next six-month period.

During the 20-month POP, evaluations are scheduled at months nine (9) and fifteen (15).

Integration events, led by TA2, are held prior to each evaluation, at months six (6) and twelve (12), and are designed to help performers prepare for an evaluation. System integration, system testing, and early assessments using sample challenge problems provided by TA2 will be performed at integration events to ensure interoperability and serve as informal assessment of capabilities. Integration events coincide with PI meetings. For planning purposes, proposers should assume that each combined PI meeting and integration event, as well as each evaluation event, is three (3) days total in length. The kickoff and last program meetings are anticipated to be two (2) days total in length. These events should alternate between the East and West coast.

Figure 2 below provides a tentative program schedule. Proposers should create a detailed schedule that is consistent with the maturity of their approaches and the risk reduction required for their concepts and their program plan based on the various TA POPs. These schedules will be synchronized across performers, as required, and monitored and revised as necessary throughout the E-BOSS program’s period of performance. A start date of April 1, 2024 for TA2 and August 1, 2024 for TA1, should be assumed for budgeting purposes in Figure 2.

After the second evaluation at month fifteen (15), the Government, at its discretion, may elect to extend the duration of awards by no more than twenty-eight (28) months and allow an equitable adjustment in order for efforts to meet cloud-scale metrics. The Government may exercise the 3-month option if the equitable adjustment efforts have not been finalized to allow continued performance until the extensions are finalized. The Government also reserves the right to extend one, some or all of the awards, or to end any further research after the POPs expire, or rescope the program and resolicit the effort depending upon the results from the 15-month evaluation event.

M A M J J A S O N D J F M A M J J A S O N D J F a b c d 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 a b c d 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

KO

❶ ❷

❶ ❷

FY24 FY25 FY26

Program meetings

Integration events

Evaluation events

TA1: Production build chains for enriched SBOMs and cyber reasoning

Develop enhanced SBOM new types of metadata and compiler / linker / loader extensions Develop cyber reasoning and rapid remediation tools

Ev al ua tio n

TA2: Cyber security sustainment

Design program CONOPS / use cases and derive series of challenge tests Assess effectiveness of TA1 tooling via security analysis as part of DevSecOps pipeline

TA2: Transition

Engagement with transition partners to inform on design of DoD-relevant eSBOMs

System engineering & integration with DoD platform

Proof of Hypothesis

Figure 2: Schedule

H. Metrics

TA1 performers’ progress will be measured by the effectiveness of their approaches to triage and remediate synthetic vulnerabilities with a variety of trigger payloads in emulated distributed deployments of the SUT, within the metric targets in the table below. Evaluation will be carried out by the selected TA2 performer in cooperation with the Government team of Subject Matter Experts (SMEs) and potential transition partners, and will be based on the TA2 performer’s proposed experimental plan, adjusted in consultation with Government SMEs and partners.

At the 15-month evaluation, performers are expected to demonstrate success against the metrics in Figure 3 below. Please note that these metrics represent an intermediate capability that can be considered a natural mid-point towards the desired national infrastructure-scale capability.

Specifically, meeting these metrics will establish feasibility of the technical approaches on the scale of an enterprise. This is a crucial mid-point that will require revolutionary fundamental research breakthroughs to achieve. However, it will not by itself deliver the cloud-scale rapid remediation capability needed for protecting the national infrastructure against a destructive cyber campaign of Log4Shell scale, which may realistically target multiple vulnerabilities across millions of exposed nodes in systems of over ten (10) million lines of code (LoCs) across multiple runtime environments.

Remedition:

Capability at Month 15

Rapid Triage:

Time to recover trigger 1 week

Time to deploy fix* 3 days

Overhead:

Compile time 10%

Runtime 10%

Experimental Setting:

Target Enterprise application scale / 1-1.5M LoC

Platforms 1 CPU / ABI + 1 virtual machine runtime / FFI

Distributed 10-50K network nodes

Figure 3: Intermediate Capability to be tested at Month 15 evaluation

As gleaned from the Log4Shell experience, the estimated metrics of the ultimately desired cloud-scale national infrastructure protection capability suggest trigger recovery and remediation in 24 hours or less, on a cloud system of one to five (1-5) million nodes and over ten (10) million LoCs, across multiple CPUs and runtime systems, under performance trade-offs palatable to the modern cloud industry. Strong proposals will discuss the trade-offs in both compile and run time, based on industry experience, and will aim to achieve an estimated overhead for both compile time and runtime below five (5) percent for the production builds of software, and such overheads for debugging/cyber-reasoning builds that are operationally suitable for CI/CDs and DevSecOps pipelines.

Although the desired national infrastructure-scale capability described above will not be tested and may not be achieved during the program, strong proposals will present a detailed technical discussion of a credible path towards achieving the national infrastructure protection capability.

The technical discussion should include estimates of required effort, duration, and any additional metrics and trade-offs essential to achieving industry adoption and success. Proposals without such plans may be deemed non-conforming.

Successful performer efforts on the trajectory to achieving the enterprise-scale metrics by Month 20, as demonstrated by the Month 15 Evaluation, may be extended to add effort on the proposed path to the national infrastructure-scale capability.

I. Deliverables

Performers are responsible for providing the following deliverables specified in Table 1, as applicable.

Table 1: Deliverables

Deliverables Schedule Technical Areas (TAs)

Slide Presentations - Annotated slide presentations for program Kick-off meeting and program meetings.

1 week after meeting event All

System Development Plan (SDP) – SDP will describe the scope of the design and development effort, provide an overview of the hardware and software architecture, outline the development plan, discuss team organization, and provide a program schedule. The SDP will be shared with other performers for synchronization.

45 days after program start All

Quarterly Coordination Reports - Quarterly technical coordination report describing progress made, accomplishments, risks, publications, resources expended, and any issues requiring the attention of the Government team.

10 calendar days after the end of each quarter

All

Monthly Financial Reporting 10 calendar days after the end of each month

All

SOTA Report – Survey and compare available tools to triage and compute reachability.

Months 9 and 18 TA2

Software - Source and object executable code. Include the source listings and source code for the target computer systems, as well as build scripts, development environments, unit tests, system tests, test harnesses, and other technical information required for the Government and TA2 to compile all delivered source code and perform testing. Delivered

Prior to each Integration and Evaluation event delivered to the Government and TA2, as well as regular code drops to

TA2.

All software under this effort is to be completely maintainable and modifiable with no reliance on any non-delivered computer programs or documentation.

Final Technical Report - Concisely summarizes the effort conducted, technical achievements, and lessons learned.

End of the period of performance

All

J. Intellectual Property

The program will emphasize creating and leveraging open-source technology and architectures.

Intellectual property rights asserted by proposers are strongly encouraged to be aligned with open-source regimes.

A key goal of the program is to establish an open, standards-based, multi-source, plug-and-play architecture that allows for interoperability and integration. The desired properties of this architecture include the ability to easily add, remove, substitute, and modify software and hardware components. The architecture will facilitate rapid innovation by providing a base for future users or developers of program technologies and deliverables. Therefore, it is desired that all software (including source code), software documentation, hardware designs and documentation, and technical data generated by the program be provided as deliverables to the Government, with data rights aligned with open source/open architecture regimes or for non-commercial items, a minimum of Government Purpose Rights (GPR) defined in the Defense Federal Acquisition Regulation Supplement (DFARS) Part 227, as lesser rights may adversely impact the lifecycle costs of affected items, components, or processes.

II. Award Information

A. General Award Information

Multiple awards are anticipated. The amount of resources made available under this BAA will depend on the quality of the proposals received and the availability of funds.

The Government reserves the right to select for negotiation all, some, one, or none of the proposals received in response to this solicitation and to make awards without discussions with proposers. The Government also reserves the right to conduct discussions if it is later determined to be necessary. If warranted, portions of resulting awards may be segregated into pre-priced options. Additionally, DARPA reserves the right to accept proposals in their entirety or to select only portions of proposals for award. In the event that DARPA desires to award only portions of a proposal, negotiations may be opened with that proposer. The Government reserves the right to fund proposals in phases with options for continued work, as applicable.

The Government reserves the right to request any additional, necessary documentation once it makes the award instrument determination. Such additional information may include but is not limited to Representations and Certifications (see Section IV.B.2.d, “Representations and Certifications”). The Government reserves the right to remove proposers from award consideration should the parties fail to reach agreement on award terms, conditions, and/or cost/price within a reasonable time, and the proposer fails to timely provide requested additional information. Proposals identified for negotiation may result in a procurement contract or other transaction, depending upon the nature of the work proposed, the required degree of interaction between parties, whether or not the research is classified as Fundamental Research, and other factors.

Proposers looking for innovative, commercial-like contractual arrangements are encouraged to consider requesting Other Transactions. To understand the flexibility and options associated with Other Transactions, consult http://www.darpa.mil/work-with-us/contract-management#OtherTransactions.

In accordance with 10 U.S.C. § 4022(f), the Government may award a follow-on production contract or Other Transaction (OT) for any OT awarded under this solicitation if: (1) that participant in the OT, or a recognized successor in interest to the OT, successfully completed the entire prototype project provided for in the OT, as modified; and (2) the OT provides for the award of a follow-on production contract or OT to the participant, or a recognized successor in interest to the OT.

In all cases, the Government contracting officer shall have sole discretion to select award instrument type, regardless of instrument type proposed, and to negotiate all instrument terms and conditions with selectees. DARPA will apply publication or other restrictions, as necessary, if it determines that the research resulting from the proposed effort will present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Any award resulting from such a determination will include a requirement for DARPA permission before publishing any information or results on the program. For more information on publication restrictions, see the section below on Fundamental Research

B. Fundamental Research

It is DoD policy that the publication of products of fundamental research will remain unrestricted to the maximum extent possible. National Security Decision Directive (NSDD) 189 defines fundamental research as follows:

‘Fundamental research’ means basic and applied research in science and engineering, the results of which ordinarily are published and shared broadly within the scientific community, as distinguished from proprietary research and from industrial development, design, production, and product utilization, the results of which ordinarily are restricted for proprietary or national security reasons.

As of the date of publication of this solicitation, the Government expects that program goals as described herein may be met by proposed efforts for fundamental research and non-fundamental http://www.darpa.mil/work-with-us/contract-management#OtherTransactions research. Some proposed research may present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Based on the anticipated type of proposer (e.g., university or industry) and the nature of the solicited work, the Government expects that some awards will include restrictions on the resultant research that will require the awardee to seek DARPA permission before publishing any information or results relative to the program.

Proposers should indicate in their proposal whether they believe the scope of the research included in their proposal is fundamental or not. While proposers should clearly explain the intended results of their research, the Government shall have sole discretion to determine whether the proposed research shall be considered fundamental and to select the award instrument type. Appropriate language will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate.