Skip to Main Content
white paper

Software Threats Only Come in One Size: Devastating

Software vulnerabilities are much like an iceberg. Like the tip of an iceberg, a software development team has great visibility into the software source code the team is developing. Like an iceberg, though, much of any software product is not visible to the software development team. The development team has complete visibility into the code they author. Beyond the source code managed by the software development team, typical software builds include source code and objects that come from external libraries, open-source projects, and third-party vendors. Much of this is opaque to the software product development team.

What is a Software Bill-of-Materials (SBOM)?

Software is increasingly a key part of today’s products, so it is now more important than ever to know how it is built. Software is often represented as a single component in an EBOM or MBOM without any breakdown of how that software is built. A software bill-of-materials (SBOM) identifies all the components that make up a software build and the environment in which that software was built. The SBOM identifies and lists the software components within a built software product including important metadata on each component and the structure of the relationships between those components.

Identify Software Threats and Vulnerabilities with SBOM

A key component for protecting an organization from vulnerabilities is ready access to the components that make up the software. The SBOM provides the foundation for identifying threats and vulnerabilities that may be incorporated into software products by constantly comparing SBOMs with published vulnerability databases. In virtually every industry, identifying and responding to threats and vulnerabilities in software products is an essential capability.

SBOM and Application Lifecycle Management (ALM) tools

Generation of the SBOM is incorporated into the continuous integration/continuous deployment (CI/CD) pipeline that is managed as an integral process of the application lifecycle management (ALM) domain. ALM processes offer comprehensive tracking across the lifecycle.

Managing software threats and vulnerabilities includes the need to identify risks and develop requirements for risk mitigation. The requirements for risk management are traced directly to the metadata elements that drive SBOM creation. This traceability, combined with verification against a vulnerability database, creates a closed-loop solution for software threats and vulnerability management.

Share