NOI_SOW.pdf

PDF 173 KB Posted

Attached to
Software Component/Package Risk and Vulnerability Periodic Database
Solicitation number
Not on record
Issued by

About this file

This document is a Statement of Work (SOW) for a federal contract opportunity related to providing a Software Component/Package Risk and Vulnerability Periodic Database to the Food and Drug Administration's (FDA) Center for Devices and Radiological Health (CDRH).

The key objectives are to acquire a data subscription service that can report on known software vulnerabilities, risks, and exploitations, and integrate this information into CDRH's automated Software Bill of Materials (SBOM) analysis solution. The contractor will be required to provide a consumable test dataset, a final daily updated dataset in a flat relational format, and an automated encrypted delivery of the data to CDRH. The contractor will also provide an anonymous submission endpoint for CDRH to request package analyses. The contract is a firm-fixed price with a 1-year base period and four 1-year option periods. Services can be provided both on and off-premises. This procurement is being conducted as a sole source award to Dark Sky Technology, LLC, as they are the only source reasonably available to meet the government's needs.

View the file

Other files

File Type Posted
NOI_DarkSky.pdf 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

i

STATEMENT OF WORK

Table of Contents

1 Background

2 Objective

3 Scope

4 Tasks

4.1 Task One: Kickoff Meeting

4.2 Task Two: Dataset Tailoring and Integration

4.2.1 Subtask One: Test Dataset

4.2.2 Subtask One: Final Dataset

4.3 Task Three: Encryption, Automated Push, and Decryption

4.4 Task Four: Package Analysis Requests

5 Deliverables

5.1 Format Of Deliverables

5.2 Deliverables Submission Procedure

5.3 Summary Of Deliverables

6 Contract Type

7 Period Of Performance

8 Place of Performance

9 Holidays & Government Closures

Page #1

1 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 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.

2 OBJECTIVE

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 develop and implement a new process which will support data analysis and reporting, and provide detailed information on cybersecurity vulnerability, risk, and exploitation, which will inform reviewers and the Cybersecurity team of potential issues within devices that contain or otherwise leverage software, hardware, or firmware.

Page #2

To accomplish this goal, the objective of this requirement is to acquire a data subscription to a 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.

Data on known vulnerabilities, risks, and exploitations are available through multiple sources, and are 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, allowing for the ability to consider risks across the total product lifecycle.

3 SCOPE

CDRH seeks a data source which will facilitate and support the CDRH automated 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. The data source must provide risk factors that are calculated based on a variety of factors, such as age of the software, exploit issue, length of time the issue has been open, etc. This information will be included within CDRH reporting to more clearly display and quickly expose the threat status and risk of a software enabled device when an SBOM is received and evaluated. The risk factors of interest are imperative to a facile and nimble evaluation for reviewers so there is no guesswork in their analysis and they can specifically determine if a software enabled device does or does not have an issue to be concerned with prior to approval. This contract will involve specialized and 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, the risk factor information will be necessitated to ensure that the vulnerabilities which are described are correctly categorized and specified to the threat level.

4 TASKS

The contractor, though online data subscriptions and correspondences with government personnel, shall provide/accomplish the following:

4.1 TASK ONE: KICKOFF MEETING

Within five (5) business days after the effective date of the Order, the Contractor shall participate in a Kick-Off Meeting with the Technical POC, the COR, the CO, and other CDRH Staff. The Contractor shall provide meeting materials and agenda two (2) days prior to the Kick-off meeting.

The Contractor shall prepare summary meeting minutes, detailing the discussion held, and provide a copy of the minutes to the COR and the Technical POC within five (5) business days after the meeting.

4.2 TASK TWO: DATASET TAILORING AND INTEGRATION

The contractor shall begin by creating consumable test files, coordinating with CDRH personnel until they are presented in an acceptable form. Upon acceptance, the contractor shall provide a dataset that shall refresh daily to be delivered to the CDRH at least once every 24 hours.

4.2.1 Subtask One: Test Dataset

The contractor shall extract and transform their data format into a flat relational format consumable by the CDRH. Contractor will work with the CDRH to provide test files to ensure accuracy and reliability of data and react to any issues by rectifying the concerns.

4.2.2 Subtask One: Final Dataset

The contractor shall extract and transform their data format into a flat relational format consumable by CDRH. After CDRH approves test files and contractor finalizes data files a final dataset will be developed.

The final relational data format agreed upon will be refreshed and delivered to the FDA at least once every 24 hours.

Page #3

4.3 TASK THREE: ENCRYPTION, AUTOMATED PUSH, AND DECRYPTION

An automatic encrypted flat relational database will be delivered to CDRH on a regular schedule (up to once every 24-hour period). An encryption key exchange will also be executed and instructions will be provided to decrypt the encrypted flat relational database for internal use.

4.4 TASK FOUR: PACKAGE ANALYSIS REQUESTS

An anonymous submission endpoint for CDRH to submit package requests for analysis. This analysis will be performed by the Contractor will then include requests subsequently packaged into the next available database update, extraction, encryption, and pushed and decrypted as soon as the analysis is complete.

5 DELIVERABLES

5.1 FORMAT OF DELIVERABLES

Deliverables (both in draft and final versions) shall be provided in hard and soft copy using MS Office products as specified below. Weekly, interim, informal, and working-copy products may be provided by e-mail to the COR. Final soft copies of deliverables shall be developed using the current FDA version of Microsoft Office products and/or other standard application software Final hard copies of deliverables shall be typewritten on 8-1/2"x11" white paper. The Contractor shall not use spiral binding or other binding that interferes with photocopying.

5.2 DELIVERABLES SUBMISSION PROCEDURE

The Contractor shall submit all deliverables to the COR, unless otherwise stated. The COR will be responsible for the review of all draft and final deliverables to ensure accuracy, functionality, completeness, professional quality, and overall compliance with the guideline’s requirements of the task. The Contractor shall ensure the accuracy and completeness of all deliverables in accordance with referenced policy, regulations, laws, and directives. Reports and presentations shall be concise and clearly written; errors, misleading or unclear statements, incomplete or irrelevant information, and/or excessive rhetoric, repetition, and "padding,” or excessive length if a page limit is imposed, shall be considered deficiencies and will be subject to correction by the Contractor at no additional cost to the government. Unless specified otherwise, the government shall have ten (10) working days to complete the review and approve the deliverables. If deficiencies are found or areas require modification, the Contractor will be notified and shall have five (5) calendar days to correct the deficiencies. Upon re-submission by the Contractor, the government will reapply the same acceptance criteria. If the deliverable does not meet the acceptance criteria a second time, the government may consider the Contractor as having deficient performance with respect to the subject task.

5.3 SUMMARY OF DELIVERABLES

Table 1: Deliverables

Task Deliverables Quantity/Frequency Due Date

4.1 Kickoff Meeting

Notes Once Within (5) days of Kickoff Meeting

4.2.1 Dataset Tailoring and Integration –

Test Dataset Recurring

Within (30) days of effective award date Subsequent fixes shall be returned within

(10) business days of reported issue.

4.2.2 Dataset Tailoring and Integration –

Final Dataset

At least once every 24 hours

Within (20) business days of acceptance of format

After acceptance, ongoing daily

Page #4

4.3 Automatic

Encrypted Flat Relational Database

Recurring Ongoing

4.4 Package Analysis Recurring Ongoing

6 CONTRACT TYPE

Firm Fixed Price

7 PERIOD OF PERFORMANCE

The anticipated period of performance for this order is one (1) twelve (12) month BASE period with four

(4) twelve (12) month OPTION periods at the time of award.

8 PLACE OF PERFORMANCE

Services shall be provided both on and off-premises.

9 HOLIDAYS & GOVERNMENT CLOSURES

The Contractor is not required to provide on-site services on the following days that are Federal Holidays or on any other day designated as a Federal holiday, Government closure, or shut-down for the Washington, D.C. area:

New Year's Day Martin Luther King Day President 's Day Memorial Day Juneteenth Independence Day Labor Day Columbus Day Veteran 's Day Thanksgiving Day Christmas Day

The Contractor shall not schedule training during federal holidays or Government closure. As necessary, training scheduled during unexpected Government closures may be rescheduled following coordination with the COR. The contractor shall not bill the Government for any training that the Contractor did not perform due to any Government closures.

1 Background
2 Objective
3 Scope
4 Tasks
4.1 Task One: Kickoff Meeting
4.2 Task Two: Dataset Tailoring and Integration
4.2.1 Subtask One: Test Dataset
4.2.2 Subtask One: Final Dataset
4.3 Task Three: Encryption, Automated Push, and Decryption
4.4 Task Four: Package Analysis Requests
5 Deliverables
5.1 Format Of Deliverables
5.2 Deliverables Submission Procedure
5.3 Summary Of Deliverables
6 Contract Type
7 Period Of Performance
8 Place of Performance
9 Holidays & Government Closures

File details come from the government source that posted it. Updated .