Modern software is based on thousands of open source packages – which are full of security holes. Thanks to SBOM tools, however, these are not an unknown threat.
A vulnerability in Log4J, which at first glance seemed insignificant, revealed a serious vulnerability in most companies: Actually, it is just a library that simplifies logging in Java programs – but most companies had no overview of the Open used -Source packages on which the own software is based. As a result, administrators in smaller IT departments had to sift through every application on their own, and in corporations they had to frantically compile Excel spreadsheets in which those responsible for an application were supposed to enter whether the affected package was used in it – feedback preferably by yesterday! There has long been a concept that would have solved all the chaos: Software Bill of Materials, SBOM for short.
Bills of materials for software
Every modern application is based on packages that do not come from their own hands, but are freely available via package managers such as Maven for Java, NPM for JavaScript or Packagist for PHP. These are not only large frameworks, but also packages that simplify the handling of time and date formats or offer extended functions for logging. These can be found in almost every application. The effects are correspondingly large if attackers find a vulnerability in them. That’s why it’s important for a company to get an overview of what’s going on in the background. Material lists have long been widespread in industry: For each end product, it is known which steel is used from which manufacturer and from which batch, in order to know exactly which products have to be recalled in the event of material defects. Exactly this concept can be transferred to software development, because the SBOM contains all packages and services on which a program depends and summarizes them together with their version in one document. If a specific version of a package is affected by a security vulnerability, a look at the SBOMs of your own applications is enough to determine the impact on your own IT.
CycloneDX
There are several implementations for this concept. The most common is CycloneDX, which is developed directly by the OWASP Foundation and is under an open source license. The output is in JSON or XML and, in addition to the metadata of the program described, includes all dependent packages and external services that it integrates. So if it obtains share prices via an external interface, the latter will be found there. The format can describe applications, containers, operating systems and firmware, but also libraries and frameworks. Analogous to supply chains in industry, a dependency tree – also known as a dependency tree – can also be included in an SBOM. If security gaps are already known at the time of creation, CycloneDX can also take them into account in the document. The figure shows the complete structure of the specification. In addition, other Bill of Materials (BOMs) can be generated for IT, such as a Software-as-a-Service BOM (SaasBOM), an Operations BOM (OBOM) and a Manufacturing BOM (MBOM).
Establish SBOMs in the company
In order to avoid the Log4J chaos, a SBOM must exist for as many applications as possible. Only in this way can the impact analysis be completely based on these SBOMs. In the first step of the introduction, you have to achieve the highest possible coverage: For programs developed in-house, tools are available that automatically generate an SBOM in their continuous integration pipelines. The CycloneDX Tool Center can handle all common programming languages and makes this step child’s play. In order to cover additionally purchased applications, one should ask the respective developer to supply an SBOM with each new version. In the USA, providers were even obliged to do this with an executive order from the White House in May 2021 – so large software houses are correspondingly well prepared. If formalized change and release processes exist in your own company, it makes sense to request the SBOM as a mandatory document for each new version and thus cover the application landscape as much as possible.
Analyze SBOMs decentrally
As soon as the – ideally entire – application landscape has been described with SBOMs, companies can establish processes and tools that compare the SBOMs with vulnerability databases and raise an alarm in the event of a hit. After all, an SBOM alone does not do much to identify weak points – it only lists the components on which the software is based. There are essentially two different approaches for the comparison: Firstly, SBOMs can be checked for weak points in a decentralized manner immediately after they have been created, for example in the CI/CD pipeline. Dependency Check, for example, is another open source tool developed by the OWASP Foundation. The command line program checks whether an entry in the database for Common Vulnerabilities and Exposures (CVEs), the world’s largest database for vulnerabilities, exists for the listed packages. In larger companies, however, the overview quickly gets lost with this decentralized approach: Even with only 100 applications and dependencies for more than a thousand packages each, a bouquet of vulnerabilities quickly accumulates that the administrators have to manage somehow. That’s why IT security teams in corporations need a central view of things.
Continuous security monitoring
The free Dependency Track of the OWASP Foundation is for exactly this second need. Instead of analyzing them directly in the pipeline, the tool stores each application – whether self-developed or purchased – on the platform with its SBOM and checks it for vulnerabilities at regular intervals. Dashboards show the status quo of the application landscape, and various channels such as e-mail, Microsoft Teams or Slack provide information about significant changes.
Dependency Track has an API and can be automatically supplied with the latest SBOMs of your own software. If the SBOM has been created in the CI/CD pipeline and loaded directly onto Dependency Track via the API, this is referred to as continuos security monitoring – i.e. the fully automatic analysis of all components. This should be the goal, because only then will there be no effort for the developers: If all SBOMs are stored, all vulnerabilities and their severity can be viewed for individual programs or all applications affected for a single vulnerability can be listed.
Conclusion
The number of open source packages and their downloads on the package manager NPM for JavaScript has been increasing for years. At the same time, the number of CVE entries only knows one direction: up. So the question is not if a vulnerability with impacts like Log4J will show up again, but when it will. The probability of being affected increases with every legacy application that is replaced. Companies now have to establish processes that automatically analyze SBOMs, send alerts and list the affected applications with one click. This is the only way to have the clarity and time to concentrate on what should be the focus of vulnerability detection instead of overworked administrators and Excel chaos: mitigating the security gap.
