Secure Software doesn't develop itself.

The picture shows the top layer of the Linux kernel's API subsystems. Source: https://www.linux.org/attachments/kernel-jpeg.6497/

Tag: CycloneDX

Creating Software Bill of Materials (SBOM) for your Code

All software comprises components. Given the prevalence of supply chain attacks against modules and libraries, it is important to know what parts your code uses. This is where the Software Bill of Materials (SBOM) comes into play. A SBOM is a list of all components your code relies on. So much for the theory, because what is a component? Do you count all the header files of C/C++ as individual components or just as parts of the library? Is it just the run-time environment or do you also list the moving parts you used to create the final application? The latter includes all tools working in intermediate processes. A good choice is to focus on the application in its deployment state.

How do you get all the components used in the run-time version of your application? The build process is the first source you need to query. The details depend on the build tool you use. You need to extract the version, the source of the packaged component (this can be a link on the download source or a package URL), the name of of component, and hashes of either the files or the component itself. If you inspect the CycloneDX or SPDX specifications, then you will find that there are a lot more data fields specified. You can group components, name authors, add a description, complex distributions processes, generic properties, and more details. The build systems and package managers do not provide easy access to all information. The complete view requires using the original source for the component, the operating system, and external data sources (for example, the CPE or links to published vulnerabilities). Don’t get distracted by the sheer amount of information that can be included in your manifest. Focus on the relevant and easy to get data about your components.

Hashes of your components are important. When focussing on the run-time of your application, make sure you identify all parts of it. To give an example of C/C++ code, you can identify all libraries your applications load dynamically. Then calculate the hashes of the libraries on the target platform. SBOMs can be different for various target platforms. If you use containers, then you can fix the components. Linking dynamically against libraries means that your code will use different incarnations on different systems. Make sure that you calculate more than one hash for your manifest. MD5 and SHA-1 are legacy algorithms. Do not use them. Instead, use SHA-2 with 256 bit or more and one hash of the SHA-3 family. This guards against hash collisions, because SHA-3 is not prone to content appending attacks.

Software Bill of Materials (SBOM)

No software projects can do without components. Software libraries are the most common ingredient. Some programming languages use the concept of modules or plugins. Then there are frameworks typically used in web applications. All of these parts can feature different versions, because some requirement fixed the version to a major release. If one component exhibits a security vulnerability, then the code in question must be updated. Given the size of modern applications, this can be a challenge. Remember the Log4j vulnerability from last year. Many teams didn’t even know that they were running applications containing Log4j. Attackers know about this and target the supply chain of the code. Finding a critical bug in components can open up a wide variety of code for attacks. This is where the Software Bill of Materials (SBOM) comes into play.

SBOM is simply a list of components that your applications contains. Most teams using build tools have this already implicitly. Basically, SBOM is a standard for the manifest of components your software brings with it. The National Telecommunications and Information Administration (NTIA) has compiled a set of resources describing how to use the standard. The idea is not new. There already exists Software Package Data Exchange® (SPDX®), OWASP CycloneDX, and ISO/IEC 19770-2:2015. Everything boils down to a specification for a JSON document that contains all relevant metadata of all components. The key is to catch all the dependencies. Some libraries depend on others, so package managers can resolve these links and install additional components. Build systems do this automatically, but the SBOM needs to be complete. Another problem is the categorisation. Some parts of the code belong to the runtime, some are managed by the operating system, and others are shipped within the application itself. A full SBOM needs to combine these sources. Your toolchain can help you there. C/C++ compiler can create a list of all headers used during compilation (the Clang/GCC flags -MD and -MF name.out.d take care of it). This is just a part of the development environment. You have to create a manifest for container images and other deployment methods as well. Be as accurate as possible, and make sure that SBOM creating is an automated part of your build pipeline.

Powered by WordPress & Theme by Anders Norén