The Cyber Security Agency of Singapore (CSA) released on Thursday an advisory on Software Bill of Materials (SBOM) and real-time vulnerability monitoring for open-source software (OSS) and third-party dependencies. The document offers software developers guidance on implementing a sustainable and automated approach to vulnerability management. The advisory was collaboratively developed by the CSA and the Open Worldwide Application Security Project (OWASP) Foundation.

The agency recognizes that integrating 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 organizations struggled to assess system compromises due to a lack of visibility into their software components and dependencies, with delayed responses to discovered vulnerabilities. Heartbleed 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 the extent of third-party dependencies and critical vulnerabilities found in software development projects. According to studies, there are on average 68.8 dependencies per project and 5.1 critical vulnerabilities in an application. If developers are unaware of the full composition of their applications, the risks of cybersecurity breaches are significant. In light of such trends, there is an impetus for developers to identify and address OSS dependencies to mitigate cybersecurity risks.

The CSA identified that generating SBOM ensures developers are not using known vulnerable dependencies and provides them full visibility into software components, equipping organizations with a clear view of their software environment, and ensuring that vulnerabilities can be managed more effectively. SBOM also improves response times by allowing developers to identify and fix vulnerable components and collaborate across the organization for holistic vulnerability management. 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 agency prescribed a three-step approach to managing vulnerabilities through SBOMs. This involves selecting a tool that accurately identifies and lists 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. 

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 assures that it originates from a trusted source. Developers should leverage available tools to publish signed records into transparency logs, enhancing trust and verifiability through immutable records of signing events. Lastly, the generated SBOM should be published to a secure repository and automatically ingested by tools like OWASP Dependency Track (DT) for continuous vulnerability monitoring and N-day vulnerability identification.

The CSA emphasizes the importance of managing vulnerabilities in both commercial and OSS projects that rely on open-source dependencies hosted on platforms like GitHub and GitLab. It highlights the need for automated workflows, such as GitHub Actions and GitLab CI/CD, to integrate security practices into development. Developers are advised to remove or update vulnerable components, thoroughly test applications, and maintain accurate SBOM documentation. Additionally, publishing the SBOM along with its signature and certificate allows users to verify the software’s security and monitor for new vulnerabilities.

Detailing that the OWASP DT provides real-time vulnerability monitoring capabilities through SBOM ingestion and continual checking against current threat intelligence, the CSA said that the OWASP DT goes beyond basic scanning by incorporating the Exploit Prediction Scoring System (EPSS), allowing developers to prioritize vulnerabilities based on their likelihood of exploitation. 

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 centralized 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).

In conclusion, the CSA advisory recognizes that SBOMs and real-time monitoring of vulnerabilities provide developers with a sustainable and automated approach to address risks posed by 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.

Last October, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) released the third edition of its Framing Software Component Transparency (2024) document. This edition provides enhanced definitions and clarifications of SBOM Attributes, building on the 2021 version. It includes detailed descriptions of each attribute’s minimum standards, recommended practices, and aspirational goals.

Facebook Twitter Pinterest LinkedIn Tumblr Email
Leave A Reply