« Previous 1 2 3 Next »
Security and automation with SBOMs
Unboxing
Regulation
Various events have led to this cyber risk now being recognized. Various US governmental agencies had already begun work on SBOM solutions as a joint project in 2018, including the US National Telecommunications and Information Administration (NTIA) coordinating with the Cybersecurity and Infrastructure Security Agency (CISA) [3] and the National Institute of Standards and Technology (NIST).
Section 4 of the US President's Executive Order made enhancing software supply chain security mandatory with a comparatively short transition period. SBOMs are part of these requirements, but they also generically include the requirement to improve secure software development processes (i.e., secure development lifecycle, SDLC; Figure 1).
The Cyber Resilience Act recently adopted by the European Parliament for the European Union (EU) deals specifically with the technical implementation of SBOMs, which are now a mandatory element of technical product documentation and whose format the EU has the right to define (and update). The links at the end of this article point readers to all the key regulations and standards. The differing approaches also define when and in what form information must be provided and at what level of detail, which involves striking a balance between protection against cyber threats and the protection of intellectual property.
For example, the ingredients generally listed on food packaging only mentions artificial flavors, but not the individual flavors and their proportions, so as not to give away the recipe to the competition. In the same way, SBOMs are also about finding a balance. An important element is therefore also the communication of weak points by manufacturers. The Common Vulnerabilities and Exposures (CVE) system forms the basis for reporting vulnerabilities in a defined format and with a uniform criticality assessment according to the Common Vulnerability Scoring System (CVSS) standard.
Interoperability and Automation
SBOMs are a challenge for both software creators and users, given the variety and complexity of software in use today, including for the Internet of Things (IoT) and machines. Machines have the additional task of analyzing information about new vulnerabilities to determine whether they are affected and ultimately initiate countermeasures as required. This undertaking requires automation functions for quick and purposeful identification of both information on what is not affected and the systems and objects at risk.
Standards have now being developed and established in various areas, initially for the format of SBOMs. The German Federal Office for Information Security (BSI) guideline TR-03813 stipulates that the SBOM must be available as CycloneDX version 1.4 or higher or use the Software Package Data Exchange (SPDX) standard version 2.3 or newer. The US Executive Order acknowledges the SPDX and CycloneDX formats, as well as software identification (SWID) tagging. The NTIA describes the minimum elements required for an SBOM [4]. These internationally established formats enable the exchangeability of SBOM information.
A second area concerns the exchange of information about vulnerabilities, with the focus on Vulnerability Exploitability eXchange (VEX), which was developed by the NTIA. VEX is implemented as a profile in the Common Security Advisory Framework (CASF) of OASIS Open and is supported by CycloneDX [5] as part of its comprehensive SBOM framework.
Two ISO standards, ISO/IEC 5230:2020 [6] and ISO/IEC 5962:2021 [7], which deal with and standardize OpenChain and the SPDX data exchange format, respectively, should also be mentioned. OpenChain is specifically about SBOM in the open source environment.
Better Security Management
A higher degree of clarity about the components contained in applications through SBOM also improves the possibilities for attack surface management (ASM). The aim is to determine systematically which surfaces of an organization can be exploited for cyberattacks. ASM includes many different elements of threat analysis and concrete testing for vulnerabilities and their elimination.
Vulnerabilities that arise directly in applications developed in-house or indirectly through open source components or third-party software and cloud services are a central element of a comprehensive ASM. This process includes risk assessment and the continuous monitoring of new information such as CVEs to enable response to new potential threats.
However, ASM can also benefit greatly from SBOMs because of the greater and faster clarity as to whether a specific threat exists, ultimately resulting in a reduction in risks because companies can take targeted action. Until now, however, the situation had been uncertain because of a lack of information about whether an app or a cloud service was affected by a newly discovered critical vulnerability. However, uncertainty prevents targeted action or requires considerable effort to clarify the status. SBOMs will fundamentally improve this situation while also optimizing incident response management.
When Log4j emerged, for example, even very large companies with strong cybersecurity teams initially had to spend a great deal of time identifying which of the applications in use were potentially affected. As a consequence, the window of opportunity for attackers was longer because IT managers could not act immediately and patch, isolate, or shut down affected systems. In these cases, SBOMs can achieve massive improvements in conjunction with improved and automated vulnerability exchange (VEX) and automation for IT infrastructure and software asset management, as well as for patch management.
Information about a vulnerability, its severity, and the extent to which software and services are affected can be processed automatically so that information about the affected systems is available. This information is in turn used to initiate automatic countermeasures. Ideally, such a process can be fully automated, partly because standards for exchanging the relevant information already exist.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)