JA_Redact.pdf
PDF 287 KB Posted
- Solicitation number
- 75F40124P00413
About this file
This document is a Justification for Other than Full and Open Competition for the acquisition of a data subscription service that reports known software vulnerabilities, risks, and exploitations. The FDA's Center for Devices and Radiological Health (CDRH) is seeking this data to support the development of an automated Software Bill of Materials (SBOM) analysis solution. The objective is to acquire a data subscription service that provides up-to-date information on vulnerabilities, risks, and exploitations, as well as associated alias information to facilitate accurate comparisons to SBOMs submitted by medical device manufacturers. The proposed sole source contractor is MedCrypt, as they have built a proprietary dataset with the required alias information that is not widely available. The total estimated value is not provided. This acquisition is being conducted under the authority of FAR 6.302-1, as CDRH has determined MedCrypt is the only responsible source that can meet its requirements.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| SOL_RFP.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Last Modified: April 5, 2017 Page 1 of 7
Justification for Other than Full and Open Competition
1. Identification of the agency and contracting activity:
a. Federal agency and contracting activity.
Food and Drug Administration/Center for Devices and Radiological Health/Office of Strategic Partnerships and Technology Innovation (FDA/CDRH/OST)
b. Sponsoring organization.
OST Data Modernization and the Division of Medical Device Cybersecurity
c. Contracting Officer’s Representative (COR)/Requiring Activity Point of Contact (POC) information.
2. Nature and/or description of the action being approved.
The acquisition of a data subscription service, which reports known vulnerabilities, that can be compared to vulnerabilities discovered within our own data, as well as to determine the severity of said vulnerabilities is peculiar to one manufacturer because only MedCrypt can provide the data required. CDRH seeks a contractor to develop and/or provide a more interconnected, automated Software Bill of Materials (SBOM) analysis solution in which the data reporting on software risks is cohesively integrated into the point of review as well as in an ongoing feedback loop of known vulnerabilities, risks, and exploitations, which are constantly being found (or added) within devices that contain or leverage software, hardware, or firmware. This contract will involve proprietary data which provides insights into vulnerabilities which exist within software components on a daily basis, as well as information on the severity of said vulnerabilities. Similarly, alias information will be necessitated to help facilitate the matching protocols that CDRH will be developing.
a. Acquisition purpose and objectives.
The Medical Device Cybersecurity Team (Cybersecurity Team) within the Food and Drug Administration’s (FDA) Center for Devices and Radiological Health (CDRH) is seeking to procure a dataset which can facilitate the automation of the automated SBOM analysis solution that CDRH is developing. This data source will support an ongoing feedback loop of known vulnerabilities, risks, and exploitations, which will inform reviewers and the Cybersecurity team of potential issues within devices that contain or otherwise leverage software, hardware, or firmware. These data will also include a comparator file “alias file” which can provide a crosswalk of all the different permutations of a software component to all the varied entries that may occur.
Understanding that there are no specific identifiers required in the vulnerability data nor
Last Modified: April 5, 2017 Page 2 of 7 in SBOMs, this file is imperative for the comparisons to occur correctly. Using these data CDRH can accurately identify a software component vulnerability and/or exploitation regardless of the entry used (e.g. Windows 11, Windows11, WIN11, WNDWS11, etc.).
To accomplish this goal, the objective of this requirement is to acquire a data subscription to a service, which reports known vulnerabilities and the multiple permutations of the component identification, which can then be used to compare to SBOMs which are received from manufacturers.
Data on known vulnerabilities, risks, and exploitations as well as the associated alias information are available and updated on a timely basis (typically daily) with the latest issues and concerns that have been identified. These data will need to be integrated into the solution that CDRH is working on, allowing for the ability to consider risks across the total product lifecycle.
b. Project background.
The Food and Drug Administration (FDA) is responsible for protecting the public health by assuring the safety, efficacy, and security of human and veterinary drugs, biological products, medical devices, our nation’s food supply, cosmetics, and products that emit radiation. The FDA is also responsible for advancing the public health by helping to speed innovations that make medicines and foods more effective, safer, and more affordable, and helping the public get the accurate, science-based information they need to use medicines and foods to improve their health.
The mission of the Center for Devices and Radiological Health (CDRH) is to protect and promote the public health. CDRH assure that patients and providers have timely and continued access to safe, effective, and high-quality medical devices and safe radiation-emitting products. We provide consumers, patients, their caregivers, and providers with understandable and accessible science-based information about the products we oversee. We facilitate medical device innovation by advancing regulatory science, providing industry with predictable, consistent, transparent, and efficient regulatory pathways, and assuring consumer confidence in devices marketed in the U.S.
Section 3305 of the Food and Drug Omnibus Reform Act of 2022 (“FDORA”), enacted on December 29, 2022, added section 524B “Ensuring Cybersecurity of Medical Devices” to the Federal Food, Drug, and Cosmetic Act (FD&C Act). Under section 524B(a) of the FD&C Act, a person who submits a 510(k), PMA, PDP, De Novo, or HDE for a device that meets the definition of a cyber device, as defined under section 524B(c) of the FD&C Act, is required to submit information to ensure that cyber devices meet the cybersecurity requirements under section 524B(b) of the FD&C Act, and to submit an associated Software Bill of Materials (SBOM) under section 524B(c) of the FD&C Act. For devices that are not cyber devices that nonetheless may be exposed to cyber risk, FDA recommends that SBOMs be included as part of their premarket submissions to help demonstrate a reasonable assurance of safety and effectiveness. An SBOM is a nested inventory that makes up a full listing of all of the software components (components, packages, and libraries) which are part of a medical device (when applicable).
SBOMs are typically provided in a machine-readable format, and will be part of premarket submissions (510(k), premarket approval application (PMA), Product Development Protocol (PDP), De Novo, and Humanitarian Device Exemption (HDE)) for review. It will be imperative for the reviewers to have a way to easily determine if the software components associated with the device present risks that could impact the device’s safety, effectiveness, or cybersecurity, including
Last Modified: April 5, 2017 Page 3 of 7 whether the components have any known vulnerabilities.
Known vulnerabilities, risks, and exploitations are different than more typical anomalies or defects in devices in that they are largely unseen, and they can “appear” at any point in time based on the technology that is being used, including technology that may be added as the device is modified or maintained. The product can work perfectly throughout clinical trials and thereafter, but then tremendous adverse effects can be introduced with the exploitation of a single vulnerability all at once. This could potentially impact all users of the device at once and cause multitudes of adverse events in a very short period of time.
3. Description of the supplies or services required to meet the agency’s needs (including the estimated value).
This acquisition is to require a Data Subscription Services to facilitate the development and implementation of the SBOM comparison tool and provide a new Vulnerability Data Dictionary inclusive of alias data that will support data analysis and reporting, and provide detailed information on cybersecurity vulnerability, risk, and exploitation, an ability to accurately match components regardless of their identification in the vulnerability data or the SBOM. This will help to inform reviewers and the Cybersecurity team of potential issues within devices that contain or otherwise leverage software, hardware, or firmware. These data will also include alias information, thus allowing for a more accurate and clarifying matching protocol to provide the information required to enable a facile and nimble evaluation for reviewers.
The scope of work is to develop a data set which has Vulnerability Data and the associated alias file for matching purposes as well as an associated dictionary that provides an overview of the structured database model, which is tailored for managing product releases, vulnerabilities from the National Vulnerability Database (NVD), products from the National Vulnerability Database (NVD) and numerous package managers, and exploit data from CISA KEV, ExploitDB, and Metasploit. The data dictionary includes the data types of each field additional notes to give context to the data. The data itself will include all the data elements of interest, including the data elements related to the alias information to make reviewer decision-making more nimble, accurate and concrete.
a. Project title.
SBOM Validation Comparison Dataset
b. Project Description.
CDRH requires an up-to-date, daily data feed which provides information regarding exploitations, concerns, and vulnerabilities associated with software components and packages. These data will facilitate the comparison of an SBOM to the vulnerabilities and associated risks and provide a more facile and nimble approach to review software enabled devices as well as for reviewers to make quick and clear-cut decisions. The reviewer will use a programmatic approach, which is currently in development, to match and compare the individual component/package information to the data included in the daily feed and upon completion of the comparisons, understand through a finalized report any vulnerabilities, exploitations, and/or concerns, including, but not limited to, the component alias permutations which also more accurately match the component which is being evaluated.
Requirement type.
Information Technology (IT)
Last Modified: April 5, 2017 Page 4 of 7
Other: Data
Type of action.
New requirement
Proposed contract/order type.
Firm-fixed-price
Acquisition identification number.
c. Total estimated dollar value and performance/delivery period.
4. Identification of the statutory authority permitting other than full and open competition. Check the applicable block below based on the acquisition circumstance.
Federal Acquisition Regulation (FAR):
6.302-1 Only one responsible source and no other supplies or services will satisfy agency requirements. This acquisition is conducted under the authority of United States Code (U.S.C.) 10 U.S.C. 2304(c)(1) or 41 U.S.C. 3304(a)(1).
6.302-2 Unusual and compelling urgency. This acquisition is conducted under the authority of United States Code (U.S.C.) 10 U.S.C. 2304(c)(2) or 41 U.S.C. 3304(a)(2).
6.302-3 Industrial mobilization; engineering, developmental, or research capability; or expert services. This acquisition is conducted under the authority of United States Code (U.S.C.) 10 U.S.C. 2304(c)(3) or 41 U.S.C. 3304(a)(3).
6.302-4 International agreement. This acquisition is conducted under the authority of United States Code (U.S.C.) 10 U.S.C. 2304(c)(4) or 41 U.S.C. 3304(a)(4).
6.302-5 Authorized or required by statute. This acquisition is conducted under the authority of United States Code (U.S.C.) 10 U.S.C. 2304(c)(5) or 41 U.S.C. 3304(a)(5).
6.302-6 National security. This acquisition is conducted under the authority of United States Code (U.S.C.) 10 U.S.C. 2304(c)(6) or 41 U.S.C. 3304(a)(6).
6.302-7 Public interest. This acquisition is conducted under the authority of United States Code (U.S.C.) 10 U.S.C. 2304(c)(7) or 41 U.S.C. 3304(a)(7).
13.501(a)(1)(ii) Sole source, including brand name, under Simplified Procedures for Certain Commercial Items. This acquisition is using this justification format, modified to reflect that the procedures in FAR subpart 13.5 were used in accordance with 41 U.S.C. 1901 or the authority of 41 U.S.C. 1903.
Last Modified: April 5, 2017 Page 5 of 7
5. Demonstration that the proposed contractor(s) unique qualifications or the nature of the acquisition requires use of the authority cited.
a. Name and address of the proposed contractor(s).
MedCrypt 125 S. Hwy 101 #101 Solana Beach, CA 92075
b. Nature of the acquisition and proposed unique qualifications of the contractor(s).
While there are other entities that collect and disseminate data associated with software and the potential exploitations, vulnerabilities and issues, this dataset collates a variety of factors regarding those packages and components into one single dataset and creates a fuzzy matching ability between a submitted software component/package and the listed vulnerability or exploitation associated with the information. These alias data are imperative to compare various packages and components more accurately and comprehensively to the risk and vulnerability information which is needed.
These data are not widely available, and MedCrypt has been building these data and resultants over the past ten years to help identify and integrate Cybersecurity into the next generation of healthcare technology. Their integrated data assets include specific and necessary data which are not available outside of their organization. These data include unique aliases datasets and corresponding correlated variables which can inform software component and package concerns.
6. Description of efforts made to ensure that offers are solicited from as many potential sources as is practicable, including whether a notice was or will be publicized as required by subpart 5.2 and, if not, which exception under 5.202 applies.
The action was synopsized as required by subpart 5.2. This justification was made publicly available on SAM.gov in accordance with 5.102(a)(6) on Wednesday, August 28th, 2024.
7. Determination by the Contracting Officer that the anticipated cost/price to the Government will be fair and reasonable.
The Contracting Specialist (CS) will, prior to award, obtain pricing information from the proposed contractor for the same or similar services and perform a price analysis to document and sufficiently determine that the cost to the Government will be fair and reasonable.
8. Description of the market research conducted (see FAR Part 10) and the results, or a statement of the reasons market research was not conducted.
During Market Research, CDRH met with other commercial entities who conduct work in this space. Results from this research determined that these other entities were missing the alias information, which is critical to the success of the automation of comparisons, as without this accurate and direct matching would not be possible. Results of those discussions are listed below:
Sonatype: (Michael Croll; mcroll@sonatype.com; 703-400-4000): The data proffered by Sonatype does not have the required salient characteristics that would be of use to FDA for CDRH’s needed purposes. Their data does not contain the alias information and correlated variables that would be required for CDRH and the SBOM comparisons.
Asimily: (Peter Hancock; Peter.Hancock@asimily.com Asimily does not have a solution which meets the needs of the FDA based on the construct of their data within their software and their solution does not have the information needed readily available.
File details come from the government source that posted it. Updated .