Open Source Vulnerabilities: How SBOMs Reveal Code Dependencies

0
9
open source vulnerabilities how sboms reveal code dependencies.png
open source vulnerabilities how sboms reveal code dependencies.png

Practical interview: Vulnerabilities in open source packages are becoming more serious – but SBOMs help. We explain how they work and what tools are available.

 

With Log4Shell at the latest, companies have recognized that the use of open source packages in their software is associated with the risk of undiscovered vulnerabilities. However, developers are not defenseless against these security gaps, because software bills of materials promise a remedy. In an interview, iX title author Udo Schneider explains how these work and which tools are available.

 

A software Bills of Materials is intended to protect against unknown security gaps in open source packages. How exactly is this supposed to work?

All software can contain security gaps that are not known at the time of build. However, Software Bills of Materials (SBOMs) contain the “frozen” versions of the dependencies. If gaps in the dependencies used become known after the build time, both the user and the manufacturer of the software can quickly check whether they are affected and assess the risk. In addition, mitigation measures can be taken in the code or the vulnerable dependency can be replaced with a new version without this vulnerability. Of course, this requires users to import new versions as well.

So SBOMs do not prevent the use of components that will one day contain gaps thanks to clairvoyant abilities. Rather, they are the basis for recognizing and assessing vulnerabilities that were unknown at the time of the build and reducing their effects or eliminating them with new versions.

SEE ALSO  Your Amazfit watch is updated and these are the new functions it releases

Creating and maintaining an SBOM is time-consuming. Is it realistic that such software bills of materials will prevail on a large scale?

Creating and maintaining SBOMs manually is indeed illusory. Even small software projects quickly have a clearly double-digit number of (indirect) dependencies. The use of tools that automatically extract dependencies and store them as a build artifact (SBOM file) is recommended here.

Although this is recommended as best practice, there is no (legal) obligation to create and deliver SBOMs. However, more and more operators are contractually demanding SBOMs in their supply chains, particularly in the area of ​​critical systems. In the USA, for example, there is also a legal requirement to provide SBOMs for critical systems or public tenders. These legal requirements do not yet exist in the German and European legal framework. However, if one follows the discussions in working groups and committees, corresponding legal requirements can also be expected in Europe in the medium term.

And even if you are not part of a critical supply chain, you should expect that (large) customers will see SBOMs as a knock-out criterion in the selection of suppliers in tenders in the long term. It is therefore a good idea to deal with the subject in peace now. If, on the other hand, you are forced to establish SBOM processes “quickly” then this has a similar chance of success as achieving 100% unit test coverage “quickly”…

Keeping an SBOM up to date manually is therefore hardly possible. What tools should developers look at?

For developers there are two(-and-a-half) types of tools that help in the automatic maintenance of SBOMs:

  • The first type are tools that extract dependencies at source code level or integrated into the build process and optionally enable mapping to corresponding security gaps. Examples of this are snyk and built-in functions of SCM platforms such as GitHub or GitLab.
  • The second type are tools that extract dependencies from build artifacts. These can be executable files, firmware images or containers. Examples include grype, tern or trivy. What all these tools have in common is that they may not be able to recognize all dependencies. Be it because package formats/programming languages ​​are not supported or this information can no longer be extracted from statically linked binaries or firmware images, for example.
  • As a remaining half type, there are tools that do not create SBOMs themselves, but help to handle them. This is for example the CycloneDX CLI tool, which allows you to convert SBOMs (JSON ↔ XML), merge them (e.g. between JavaScript frontend code with a Java backend) or between different SBOM formats (CycloneDX, SPDX). translate.
SEE ALSO  This is my essential app to save links and internet readings for later: it is free, open source and cross-platform

A good listing of tools can be found on the CycloneDX and SPDX sites. A look at GitHub or GitLab can also be helpful, as tools and best practices for the respective pipelines are documented there, which in most cases are also open source or use open source projects.

Ultimately, what remains are tools that manage SBOMs. These are to be seen less in the development area and more in the SecOps area, but they are no less important. In addition to commercial tools that manage SBOMs or offer this as an additional function for asset and license management, the open source software DependencyTrack from OWASP should be mentioned here. It enables both manual management of SBOMs and automated integration into CI/CD pipelines. SBOMs are continuously checked for security gaps in the background and corresponding hits are alerted via email, chat and SMS.

Odo, thanks for the replies. A detailed article on SBOM tools and attacks on the software supply chain can be found in the new October iX.

In the “Three Questions and Answers” series, iX wants to get to the heart of today’s IT challenges – whether it’s the user’s point of view in front of the PC, the manager’s point of view or the everyday life of an administrator. Do you have suggestions from your daily practice or that of your users? Whose tips on which topic would you like to read in a nutshell? Then please write to us or leave a comment in the forum.

SEE ALSO  New Samsung Galaxy A55 and Galaxy A35 5G are official: mid-range phones now more powerful