Software today relies heavily on open source, third-party components, but these reusable dependencies sometimes inadvertently introduce security vulnerabilities into the code of developers who use them. Some of the most serious vulnerabilities discovered in recent years—like the OpenSSL punycode vulnerability, Log4Shell (Log4j), and Dirty Pipe (Linux)—reside in popular open source packages, making them so widespread that they could compromise almost the entire software ecosystem.
In order to help organizations detect such vulnerabilities in third-party software, the US federal government has proposed adoption of a Software Bill of Materials (SBOM)—an inventory of the software components in the codebase of a given product, including third-party dependencies—across the software industry. In Executive Order 14028 on improving national security, Section 4 includes a specific provision for vendors to enhance software supply chain security by “providing a purchaser [an SBOM] for each product directly or by publishing it on a public website.” The order directs vendors of all critical and third-party software used by federal agencies to provide SBOMs for their products on request by the end of this year. Software companies will likely have to start providing SBOMs to non-government customers, too, as expectations for this level of transparency continue to increase.
Creating an SBOM involves taking stock of the dependencies in your product’s codebase. For developers and security engineers, this can be a helpful exercise in identifying vulnerabilities that derive from third-party libraries—but SBOMs have some limitations that can make them difficult to work with for vulnerability management purposes. In this post, we’ll cover:
An SBOM provides information about the composition of a software artifact. The National Telecommunications and Information Administration (NTIA) has put together a collection of resources describing the SBOM. The baseline information required for an SBOM file includes:
| Info | Description |
|---|---|
| Author name | The entity that has created the SBOM; note that this may not always be the supplier |
| Supplier name | Name or other identifier of the supplier of a component in an SBOM entry |
| Component name | Name or other identifier of a component |
| Version string | Version of a component |
| Component hash | Cryptographic hash of a component |
| Unique identifier | Additional information to help uniquely define a component |
| Relationship | Association between SBOM components (e.g., “includes” and “included in”) |
It also can include auxiliary information, such as:
| Info | Description |
|---|---|
| Licensing | The term of use or type of license |
| Provenance and pedigree | Where the component was fetched from |
| Timestamp | Date and time when the SBOM was last updated |
| End of life | End-of-support dates for components |
| Grouping | By product lines or implemented technologies; a group could be treated as a special type of upstream component |
| Unique identifier | Additional information to help uniquely define a component |
| Relationship | Association between SBOM components (e.g., “includes” and “included in”) |
SBOMs can be expressed in a number of formats, notably Software Package Data Exchange (SPDX) and CycloneDX. These are open standards that help organizations create SBOMs quickly and efficiently, without having to build out the structure of an SBOM file from scratch. They also aim to standardize SBOM formats across the industry for easier cross-comparison.
SBOMs are a powerful tool for helping software buyers understand what the dependencies are in the product they are purchasing—and they are also helpful for software vendors as a way to inventory their dependencies and identify vulnerabilities. However, starting with an SBOM and deciding which vulnerabilities need to be remediated immediately is not so simple, as SBOMs are not very actionable themselves.
Having insight into whether or not a dependency is vulnerable is important, but not very informative without context as to whether or not that vulnerability is actually exposed in production, and whether the service leveraging the vulnerable dependency has other risks that could be exploited by attackers (e.g., if the service is deployed on mission-critical container workloads or infrastructure hosts). Runtime context is particularly important when you have to make sense of a large SBOM composed of a huge number of dependencies, with an even greater number of associated vulnerabilities. You might not spot the most critical vulnerabilities out of sheer exhaustion, or you could zero in on noncritical vulnerabilities due to lack of context. This is counterproductive to vulnerability management programs and makes it difficult for organizations to determine whether or not they are in compliance with key regulatory frameworks.
Because of these and other limitations, SBOMs tend to be:
To identify, prioritize, and remediate vulnerabilities effectively, security analysts need a source of information that is informative, queryable, and linkable, providing the necessary context to augment their existing SBOMs and fill in any gaps. Next, we’ll look at how Datadog Software Composition Analysis (SCA) addresses many of the common limitations of SBOMs by surfacing vulnerabilities in open source libraries that are actually running in production, alongside real-time threat insights.
SBOMs typically list dependencies found in source code or during builds. This approach does not indicate whether these dependencies are actually running in production, making it difficult to determine whether vulnerabilities in these libraries are actually important to prioritize for remediation.
SCA uses the information that Datadog APM is already collecting and flags libraries that match known vulnerability advisories. Potentially vulnerable services are highlighted in the APM Security View, which is embedded in the Software Catalog. This helps create a more accurate picture of which vulnerable dependencies are active in your environment, so you can build a more targeted and impactful remediation plan.
Because SBOMs are static documents, they aren’t easily queryable. Organizations need to be able to easily search their SBOMs for their entire suite of applications quickly, in order to spend less time reading the SBOM and more time remediating vulnerabilities.
SCA is tightly integrated within the larger Datadog platform, making it easy to search and filter for specific applications, services, and third-party libraries across your environment so you can surface vulnerabilities in all your services running in production. You can use Datadog’s rich tagging capabilities to query the machines and metrics you’re monitoring and intuitively filter your results by facet, such as service, language, and environment.
Because SBOMs aren’t linkable, you need to rely on your own knowledge or an external database to determine what vulnerabilities may exist in the dependencies listed there. Datadog SCA links with multiple well-known vulnerability databases, including OSV. This helps surface vulnerable dependencies and ensures that the platform is always up to date with the latest known vulnerabilities. You can also navigate from a vulnerability finding in Datadog to linked resources from NIST, GitHub, and others to help you understand the vulnerability, assess its impact, and determine next steps for remediation.
SBOMs will continue to be a critical resource in creating a more secure software supply chain in the coming years. Datadog SCA provides valuable insights in addition to SBOMs, helping address some of their limitations. Through continuous, real-time monitoring of services in production for vulnerabilities in open source software dependencies, SCA provides an informative, queryable, and linkable view into the risks that third-party components introduce into your environment.
To learn more, you can request a personalized demo. If you’re new to Datadog, sign up for a 14-day free trial.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。