This content is for members only. Please and try your request again.

DHS S&T OTS: Software Supply Chain Visibility Tools

Notice ID 70RSAT22R00000027

1.1 DHS Operational Need

Software has become a key component of infrastructure systems that individuals and organizations rely upon for essential services, including communications, finance, transportation, and energy. Attacks that exploit vulnerabilities in software can lead to outages or damage to safety- and life-critical systems. Strengthening the assurance of the software supply chain is essential to protecting software and software-controlled systems. Transparency is a necessary foundation for a high-assurance supply chain, enabling answers to questions like: What software components are in the system? Who built those components? What other software do those components depend upon?

A Software Bill of Materials (SBOM) “is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships.”2 Tools that support wide availability of trustworthy SBOMs can enable stakeholder visibility into software supply chains and new risk assessment capabilities.

We intend to energize the market to provide SBOM-based capabilities for stakeholders within the enterprise, system administrator and software developer communities. We seek both foundational opensource software libraries and value-added tooling.

This [Silicon Valley Innovation Program (SVIP)] Call seeks technical capabilities that could serve the mission needs of one or more DHS Operational Components and Programs including:

  • Cybersecurity and Infrastructure Security Agency (CISA)…
  1. Topic Description

To fully realize the benefits of SBOMs and software component transparency, machine processing and automation are necessary. This requires widespread interoperability across the supply chain which, in turn, requires standardized data formats and identification schemes. Unfortunately, diverse needs within the software ecosystem have resulted in multiple candidate SBOM data formats and identification schemes that stakeholder tools must handle correctly. Utility software that translates among many of the more common formats and identification schemes will be essential to enable a flexible SBOM tooling ecosystem. While stand-alone tools exist for generating SBOMs in each of the common formats, the need to automatically generate an SBOM during the software build process requires SBOM generators designed to integrate into (i.e., plug in) to build systems.

As shown in the illustrative scenarios, additional tools will be needed to enable human use of machine-readable SBOM data objects that encode software identity and provenance. For business-focused (rather than technology-focused) analysts, tools that support visualization of software provenance and risk, potentially in the context of a specific regulatory domain (e.g., health care, finance) can support risk-informed decisions. Software developers will require capabilities that plug in to popular IDE tools, highlighting software dependencies, warning of vulnerabilities, and providing information about critical mitigations. System administrators use Security Incident and Event Management (SIEM) tools to consolidate security threat information and understand which threats may apply to systems deployed within the operational environment. Capabilities that leverage software identifiers (encoded in SBOMs and vulnerability records) can help SIEM tools to pinpoint vulnerable operational systems and enable system administrators to prioritize mitigations…

Read more here.


This topic has 0 replies, 1 voice, and was last updated 4 months ago by Jackie Gilbert.

Viewing 0 reply threads

You must be logged in to reply to this topic.


Questions?. Send us an email and we'll get back to you, asap.

G2Xchange FedCiv

Log in with your credentials
for G2Xchange Health

Forgot your details?