Binary-Level Automated Vulnerability Detection and Patching without Source Code

Navy SBIR 25.2- Topic N252-079
Naval Air Systems Command (NAVAIR)
Pre-release 4/2/25   Opens to accept proposals 4/23/25   Closes 5/21/25 12:00pm ET
   [ View Q&A ]

N252-079 TITLE: Binary-Level Automated Vulnerability Detection and Patching without Source Code

OUSD (R&E) CRITICAL TECHNOLOGY AREA(S): Integrated Sensing and Cyber

The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with the Announcement. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws.

OBJECTIVE: Develop innovative approaches to automatically find and fix software vulnerabilities in binaries without source code. The capability should be robust enough not only to identify zero day exploits and vulnerabilities, which can be weaponized for offensive purposes but, also implants (for defense against supply chain attacks) and malware.

DESCRIPTION: Due to the prevalence of programmers copying and pasting code into their projects, or the inclusion of libraries of unknown origin or quality, the security of the software that underpins critical systems is always in question. Because of this, methods to quickly secure new and existing critical software used in the Fleet is needed for all Program Management Activities and Program Executive Offices. Current techniques to secure software involve manual vulnerability discovery and remediation using subject matter experts (SME) and typically requires access to the source code. However, the source code is usually not available for analysis especially for legacy applications, weapon systems, control systems, and communication systems whose software is proprietary. For this SBIR project, the small business awardee will develop novel approaches to automatically perform security assessments on compiled binaries of multiple instruction set architectures to detect known and unknown vulnerabilities (greater than 90% success rate) and automatically develop patches for any found vulnerabilities.

Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. owned and operated with no foreign influence as defined by 32 U.S.C. § 2004.20 et seq., National Industrial Security Program Executive Agent and Operating Manual, unless acceptable mitigating procedures can and have been implemented and approved by the Defense Counterintelligence and Security Agency (DCSA) formerly Defense Security Service (DSS). The selected contractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances. This will allow contractor personnel to perform on advanced phases of this project as set forth by DCSA and NAVAIR in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material during the advanced phases of this contract IAW the National Industrial Security Program Operating Manual (NISPOM), which can be found at Title 32, Part 2004.20 of the Code of Federal Regulations.

PHASE I: Determine the technical feasibility of binary level automated vulnerability detection and patching without source code including:

1. Determination of the major challenges and preliminary feasibility of software algorithms.

2. Development of an initial concept design that supports binary level automated vulnerability detection and patching without source code.

The Phase I effort will include prototype plans to be developed under Phase II.

PHASE II: Develop and demonstrate a prototype for binary-level automated vulnerability detection and patching without source code. The prototype deliverables should include:

1. Design and development the algorithms required to perform binary-level automated vulnerability detection and patching without source code.

2. Demonstrate the ability of the prototype to harden vulnerable binary software.

3. A technical roadmap that takes the program through Phase III must be part of the final delivery for Phase II.

Work in Phase II may become classified. Please see note in Description paragraph.

PHASE III DUAL USE APPLICATIONS: Complete final testing, perform necessary integration and transition for use in monitoring operations/applications with appropriate platforms and agencies, and future combat systems under development.

Commercially, this product could be used to enable security monitoring.

REFERENCES:

  1. Hicks, K. "Department of Defense Software Modernization Strategy". Department of Defense, 2 February 2022. https://media.defense.gov/2022/Feb/03/2002932833/-1/-1/1/DEPARTMENT-OF-DEFENSE-SOFTWARE-MODERNIZATION-STRATEGY.PDF
  2. Gilday, M. M. "Chief of Naval Operations Navigation Plan 2022". Department of the Navy, 2022. https://media.defense.gov/2022/Jul/26/2003042389/-1/-1/1/NAVIGATION%20PLAN%202022_SIGNED.PDF
  3. "ICS/OT Cybersecurity Year in Review 2022." Dragos, Inc., 2022. https://hub.dragos.com/ics-cybersecurity-year-in-review-2022
  4. Schaad, A. & Binder, D. "Deep-learning-based Vulnerability Detection in Binary Executables". G. V. Jourdan, L. Mounier, C. Adams, F. Sèdes, & J. Garcia-Alfaro (Eds.). Foundations and Practice of Security (FPS), 2022. Lecture Notes in Computer Science, Vol. 13877. Springer, Cham. https://doi.org/10.1007/978-3-031-30122-3_28
  5. Wen, M.; Chen, J.; Wu, R.; Hao, D. and Cheung, S. C. "Context-aware patch generation for better automated program repair." Proceedings of the 40th International Conference on Software Engineering, May 2018, pp. 1-11. https://dl.acm.org/doi/10.1145/3180155.3180233
  6. "National Industrial Security Program Executive Agent and Operating Manual (NISP), 32 U.S.C. § 2004.20 et seq. 1993". https://www.ecfr.gov/current/title-32/subtitle-B/chapter-XX/part-2004

KEYWORDS: Source code; binary; vulnerability; Artificial Intelligence; Machine Learning; AI/ML; software; cybersecurity

** TOPIC NOTICE **

The Navy Topic above is an "unofficial" copy from the Navy Topics in the DoD 25.2 SBIR BAA. Please see the official DoD Topic website at www.dodsbirsttr.mil/submissions/solicitation-documents/active-solicitations for any updates.

The DoD issued its Navy 25.2 SBIR Topics pre-release on April 2, 2025 which opens to receive proposals on April 23, 2025, and closes May 21, 2025 (12:00pm ET).

Direct Contact with Topic Authors: During the pre-release period (April 2, 2025, through April 22, 2025) proposing firms have an opportunity to directly contact the Technical Point of Contact (TPOC) to ask technical questions about the specific BAA topic. The TPOC contact information is listed in each topic description. Once DoD begins accepting proposals on April 23, 2025 no further direct contact between proposers and topic authors is allowed unless the Topic Author is responding to a question submitted during the Pre-release period.

DoD On-line Q&A System: After the pre-release period, until May 7, 2025, at 12:00 PM ET, proposers may submit written questions through the DoD On-line Topic Q&A at https://www.dodsbirsttr.mil/submissions/login/ by logging in and following instructions. In the Topic Q&A system, the questioner and respondent remain anonymous but all questions and answers are posted for general viewing.

DoD Topics Search Tool: Visit the DoD Topic Search Tool at www.dodsbirsttr.mil/topics-app/ to find topics by keyword across all DoD Components participating in this BAA.

Help: If you have general questions about the DoD SBIR program, please contact the DoD SBIR Help Desk via email at [email protected]

Topic Q & A

4/25/25  Q. The topic objective requires the detection of vulnerabilities, implants, and malware in binary code. However, the remainder of the description does not mention implants and malware again. Only vulnerabilities. If a proposal addresses only vulnerabilities, will it be considered non-responsive?
   A. If you are making a distinction that implants and malware are not vulnerabilities then it would not be fully addressing the topic. Vulnerabilities include implants and malware.
4/24/25  Q. To ensure that we prepare an accurate and realistic pricing proposal, could you kindly clarify the expected or approximate start date for the period of performance?
   A. For selected proposals, the Phase I contract award is generally in place 4-5 months after BAA Close, but not more than 6 months after BAA Close. For the 25.2 BAA awards on selected proposals should start their contract Period of Performance between late September - November.
4/21/25  Q.
  1. Are there any preferred instruction set architectures (e.g., x86, ARM, MIPS) or operating system targets that would be most relevant to address in a Phase I feasibility demonstration?
  2. Does the government have access to representative binaries or synthetic test corpora that may be made available in Phase I for algorithm validation purposes?
  3. Should the proposed solution support both static and dynamic binary analysis methods in Phase I, or is emphasis on one approach acceptable during early feasibility?
  4. Is it expected that the patching mechanism preserve original functionality (e.g., bit-exact output where possible), or is modifying binary behavior within acceptable bounds permitted?
  5. For Phase I, should vulnerability detection include zero-day discovery heuristics, or is the focus on known vulnerability classes and pattern detection sufficient?
  6. Are there specific evaluation metrics or benchmarks the government intends to use to assess binary patching effectiveness (e.g., runtime behavior, vulnerability re-scanning, system performance impact)?
  7. Will classified environments or secure sandbox configurations be required in Phase I, or is the Phase I effort expected to remain unclassified?
  8. Does the Navy have an envisioned Phase III transition partner (e.g., PMA, cyber defense team, or platform integrator) that this capability is ultimately expected to support?
   A. 1. No, the Navy is seeking a solution which seamlessly addresses the various instruction sets and operating systems from a single software product.

2. During Phase I, the contractor will utilize binary examples to illustrate/highlight their capabilities. During Phase II, the Government will be providing sample binaries to assess and validate functionality.

3. Yes, both static and dynamic binary analysis should be considered as part of the proposed solution.

4. Patching is expected to preserve original functionality to the maximum extent. Consideration is given for complexity of the code. Understanding the impact of the patching/quilting on run-time operation and downstream interaction is envisioned.

5. Yes, the goal is to have detect both known and unknown (zero-day) vulnerabilities at the forefront whilst reducing manual vulnerability discovery and remediation using subject matter experts (SME). An example would be code that incorporates software packages that don't exist and running that code should result in an error when importing a non-existent package.

6. The items identified are benchmark and metrics for considerations.

7. No, Phase I is inherently unclassified.

8. This will be determined in Phase II however the software support, cyber, FRC and others are considerations for Phase III.
4/20/25  Q. 1. How many awards does this topic plan on awarding?
2. What deliverables are you specifically looking for in the phase 1 base and phase 1 option?
3. Phase II mentions a requirement for a facility clearance. How much of the work will be required to be on site or in a SCIF for Phase II?
   A.
  1. The number of selections is dependent on the number of proposals received. The DON is not obligated to make any awards, however, the DON will usually make 2-4 selections per Phase I topic.
  2. Typical contract deliverables for Phase I Base will be the kick-off brief, progress report, final report, and Initial Phase II Proposal. The Phase I Option deliverables will be kick-off brief, progress report, final report.
  3. Details on deliverables will be provided in the Phase I contract. Information on requirements for Phase II will be provided to Phase I awardees.
4/19/25  Q. How firm is the requirement for a 90% accuracy rate for malware detection on binaries? The LCNS Paper cited (Schadd et al.) only has a 77% accuracy for multi-class detection. Additionally, they state that their dataset may be biased, leading to a higher accuracy.
   A. That particular paper was written in 2022 with a specific Word2Vec approach being undertaken at that time. Significant “new” methods and developments have occurred in the interim which is what this topic is attempting to address. As indicated the desired goal of this SBIR is 90% or higher. Bin2vec approaches have prediction accuracy that are over 80% (and over 90% in multiple classes).

The reference article abstract extract which is being referenced for the values noted: "A binary classification was established for detecting the presence of an arbitrary vulnerability, and a multi-class model was trained for the identification of the exact vulnerability, which achieved an out-of-sample accuracy of 88% and 77%, respectively. Differences in the detection of different vulnerabilities were also observed, with non-vulnerable samples being detected with a particularly high precision of over 98%."


[ Return ]