Advisory on Software Bill of Materials and Real-time Vulnerability Monitoring for Open-Source Software and Third-Party Dependencies

The integration of Open-Source Software (OSS) in software development introduces significant cybersecurity challenges, particularly regarding vulnerabilities in third-party dependencies. Notable incidents, such as Log4j and Heartbleed, underscore these risks. On Log4j, many organisations struggled to assess system compromises due to a lack of visibility into their software components and dependencies, with delayed responses to discovered vulnerabilities. On Heartbleed, it affected the widely used OpenSSL cryptography library, leading to the theft of 4.5 million medical records from a major overseas hospital chain.

These dependency threats are exacerbated by extent of third-party dependencies and critical vulnerabilities found in software development projects. According to studies, there are on average 68.81 dependencies per project and 5.12 critical vulnerabilities in an application. If developers are unaware of the full composition of their applications, the risks of cybersecurity breaches are significant. In the light of such trends, there is an impetus for developers to easily identify and address OSS dependencies to mitigate cybersecurity risks.

The advisory is intended for all software developers, especially those who incorporate OSS and third-party dependencies into their projects. While many developers are aware of cybersecurity risks, they may not have the resources and guidance to enforce cybersecurity during software development and implementation. To aid developers, the advisory offers guidance on a sustainable and automated approach to vulnerability management through Software Bill of Materials (SBOM) and real-time vulnerability monitoring.

The traditional way of manually managing OSS dependencies is inefficient and prone to errors. Furthermore, developers must sift through complex codebases to identify and fix vulnerable software components.

Generating Software Bill of Materials (SBOM) ensures developers are not using known vulnerable dependencies and provide them full visibility into software components. SBOM provides a structured and formal record of components used to build software. It equips organisations with a clear view of their software environment, ensuring that vulnerabilities can be managed more effectively. Through the integration of SBOM tools into software development workflows, developers can automatically track each component from the start, reducing manual effort and human error. It enables them to significantly reduce technical debt by identifying outdated or vulnerable components much earlier, in turn decreasing future remediation workloads.

SBOM also improves response times by allowing developers to quickly identify and fix vulnerable components and collaborate across the organisation for holistic vulnerability management. This streamlined process not only minimises complexity but also fosters collaboration among developers and cybersecurity professionals, allowing cybersecurity risks to be addressed proactively without stifling innovation. If SBOM is integrated into CI/CD pipelines, it allows real-time monitoring of new vulnerabilities through automation of SBOM generation, signing and alerts. The SBOM can also be used to foster collaboration across teams, including SecOps, Incident Response (IR) and development teams for holistic vulnerability management and improved response times.

The three-step approach is as follows:

• Select tool: The chosen tool should accurately identify and list components as well as direct and indirect dependencies of the software. The tool should also integrate seamlessly with continuous integration/continuous deployment (CI/CD) pipelines such as GitHub Actions, GitLab CI/CD or equivalent software.
• Generate and sign the SBOM: The tool should be used to generate an SBOM that complies with industry standards such as CycloneDX or SPDX. Signing the SBOM after its generation ensures authenticity and provides assurance that it originates from a trusted source. Developers should leverage on available tools to publish signed records into transparency logs, enhancing trust and verifiability through immutable records of signing events.
• Proactive vulnerability management: The generated SBOM should be published to a secure repository and automatically ingested by tools like OWASP Dependency-Track for continuous vulnerability monitoring and N-day vulnerability identification.

As the software development environment varies for each system, developers should also take note of the following practical considerations:

• The SBOM is only as comprehensive as the manifest files generated. If the codebase includes obscure or less common programming languages, some dependencies may not be detected;
• For SaaS and closed-source software, developers should request the SBOMs from their third-party providers as these SBOMs provide the most comprehensive coverage of the software components and dependencies. If developers are unable to obtain SBOMs from their third-party providers, the selected SBOM generation tool need to be able to perform supplementary checks in the respective environments. In particular, SaaS software could use runtime SBOMs 10 , capturing dynamically loaded or run-time injected components during execution. For closed-source software, binary-based SBOM tools could be used to create an inventory of the software components used. Such tools inspect the compiled binary code, which is the final product of the software. Once developers discover vulnerabilities through the SBOMs, they need to inform their third-party providers to remediate them;
• Developers need to verify identified vulnerabilities for exploitability as the vulnerabilities may not be relevant in their software development environments. Without appropriate verification, there could be a high volume of vulnerabilities surfaced through the SBOM and developers risk being overwhelmed with false positives and time spent on subsequent remediation. Developers should start the verification process by using industry filters such as CISA’s Known Exploited Vulnerabilities (KEV) that only alerts on CVEs that are actively exploited. Once the vulnerabilities are filtered, vulnerabilities can be assessed for the likelihood of being exploited through the Exploit Prediction Scoring System (EPSS). After identifying vulnerabilities that are likely to be exploited, they can be prioritised for remediation using Common Vulnerability Scoring Systems (CVSS), which rates the severity of vulnerabilities.

Both commercial and Open-Source Software projects commonly rely on open-source dependencies, typically hosted on code repository platforms such as GitHub and GitLab. As central hubs for OSS development, GitHub and GitLab are used by developers who collaborate on projects of varying scope and complexity. Given the widespread use of such code repository platforms, managing vulnerabilities are even more critical for maintaining a secure software ecosystem. Such environments provide automated workflow functionalities on managing vulnerabilities, with automation enabling a seamless integration of security practices into the development process.

Developers should use tools such as GitHub Actions and GitLab CI/CD that allow for the automated creation and vulnerability checking of SBOMs. While SBOM signing is not a native feature, external tools can be integrated into the workflow. Refer to Annex A for the full script that automates these actions for GitHub Actions and a similar workflow can be implemented for GitLab CI/CD (Annex B).

Developers should either remove vulnerable components if the functionalities provided through these components are not crucial or update these components to non-vulnerable versions. Developers should thoroughly test their applications to verify the application works as intended and update the SBOM documentation to record which components were removed and updated. This approach enhances the cybersecurity of the software and protects users from known exploits.

Developers should publish SBOM, its signature and certificate alongside the digital files. This allows downstream users in the software development ecosystem to easily access and verify the SBOM, ensuring that they are working with a secure and authentic version of the software. Users can also leverage the SBOM to continuously monitor for new vulnerabilities.

OWASP Dependency Track (DT) provides real-time vulnerability monitoring capabilities through SBOM ingestion and continual checking against current threat intelligence. OWASP Dependency Track (DT) goes beyond basic scanning by incorporating the Exploit Prediction Scoring System (EPSS), allowing developers to prioritise vulnerabilities based on their likelihood of exploitation. Refer to Annex C for more details on the deployment of OWASP DT.

Developers should integrate the OWASP DT tool into CI/CD pipelines for real-time monitoring, consistent automation of SBOM generation and signing, and alerts for new vulnerabilities. Developers should securely store signed SBOM into centralised repositories to support collaboration across teams, including SecOps, Incident Response (IR) and development teams. In addition, developers need to establish governance policies for SBOM storage, access control and lifecycle management in collaboration with their Chief Information Security Officers (CISOs).

SBOMs and real-time monitoring of vulnerabilities provide developers a sustainable and automated approach to address risks posed by Open-Source Software (OSS) and third-party software components, in turn enhancing the cybersecurity posture of the software supply chain. Such an approach allows developers and system owners to have visibility on software components and dependencies and improve response times to address vulnerabilities.

This advisory was jointly developed by the Cyber Security Agency of Singapore and OWASP Foundation.

The information and advice contained in this document is provided "as is" without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by the Cyber Security Agency of Singapore, OWASP Foundation or GitHub. This document shall not be used for advertising or product endorsement purposes.