By Yann Albou.
Beyond the Supply Chain Attack, discover the concept of SBOM and improve CI/CD security and better detect vulnerabilities.
This article is part of a series on how to protect yourself from a "Supply Chain Attack"?
As explained in the article The Supply Chain Attack? and in order to facilitate the implementation in application of our recommendations, we have adopted signage. Here is the one concerning our subject:
The scope concerns the Dev and CI (Continuous Integration) part. it is a practice and tools to put in place that require a moderate effort. This recommendation offers detection-type risk mitigation, which makes it very interesting to implement.
This term means "Software Bill of Materials", which means "List of Software Components". It is a document (in a standardized format) that lists all the software components used in the creation of a given software product, including third-party libraries, modules, frameworks and packages.
This Software Bill of Materials lists all the software components used in the creation of a given software package, including third-party libraries, modules, frameworks and packages and not only those of the application but also those of the system on which the application is running. inside a container (ex: lib openssl). It is important to have a complete and exhaustive up-to-date list of components, applications and systems, to ensure that the solution is safe, reliable and complies with quality standards.
The list must identify the direct and indirect dependencies between the different software components. Direct dependencies are components that are explicitly referenced in the source code, while indirect dependencies are components that are required by direct dependencies. It is important to identify these dependencies to understand the complexity of the application and the potential risks associated with these dependencies.
The SBOM must uniquely identify each package and each version of each software component used. This unique identification is essential to guarantee the traceability of components and to enable efficient management of licenses and contracts.
This can be considered as a virtuous approach, as it aims to improve the security, quality and transparency of the software. But it can go further:
This concept will allow us, for example, to answer questions of the type:
The use of tools to extract information from it is not new and it is already integrated into certain development frameworks. For example, the pom.xml file used by Maven for managing Java projects contains information about direct and indirect dependencies, versions, licenses, and repository URLs for each component. Similarly, the package.json file used by js frameworks contains information about direct dependencies, versions, repository URLs, and build scripts for each package. These files are examples of so-called "dependency descriptors" and they are used by dependency management tools to download the appropriate components and install them into the project.
These dependency descriptors are also used to extract information. For example, dependency management tools like Maven, npm, Cargo, Go Modules, etc. can extract information from these files. This automatically creates an SBOM for the project, which can be used to check licenses, vulnerabilities, and indirect dependencies.
This is an extension of the existing tools to provide a complete overview of the software components used in the system. Dependency management tools are generally (not all) limited to direct dependency management. However, it should also include information about indirect dependencies, which may be more difficult to identify. Static analysis tools can be used to identify indirect dependencies, but this can be a tedious and expensive process.
It also provides version information for each component, which is important for managing updates and security patches. Dependency management tools can also manage security updates and patches, but it provides an overview of all components in the system and makes it easier to plan updates and patches.
Ultimately, using tools to extract information from the SBOM is common practice in development environments and is already built into some frameworks. It provides a complete overview of the components used in the system, which facilitates the management of licenses, vulnerabilities, indirect dependencies and updates.
By way of example and in a non-exhaustive way, here are some open source tools for generating SBOM: Trivy(Opensource project by Aquasecurity), [Syft](https: //github.com/anchore/syft)(Opensource project by Anchore), SBOM Tool(Opensource project by Microsoft), [bom](https:/ /github.com/kubernetes-sigs/bom)(Opensource project by kubernetes-sigs), spdx-sbom-generator, [Tern] (https://github.com/tern-tools/tern), …
Note that the new command docker sbom relies on Syft to generate an sbom.
Before using these tools make sure they match your supported packages, frameworks and system needs and that they integrate well with your environment ( offline mode, standards, CI, …).
The SBOM should be generated in a standardized format to ensure better interoperability and wider adoption. Two popular standardized formats are SPDX and CycloneDX. SPDX (Software Package Data eXchange) is an industry standard format for exchanging licensing information and associated metadata. CycloneDX is a metadata format for software components that provides a standardized representation of component information.
Here is an example of SPDX format for an application package:
SPDXVersion: SPDX-2.2
DataLicense: CC0-1.0
DocumentNamespace: http://example.com/project/1.0
PackageName: example-project
PackageVersion: 1.0.0
PackageDownloadLocation: https://github.com/example/project/releases/tag/v1.0.0
PackageChecksum: SHA1:4b74d58f79a74766ca2fbb7201a9e1d3d3e0c6b8
PackageVerificationCode: PACKAGE_VERIFICATION_CODE
PackageHomePage: http://example.com/project
PackageSourceInfo: git+https://github.com/example/project.git#v1.0.0
PackageLicenseDeclared: Apache-2.0
FilesAnalyzed: true
PackageLicenseComments: This package is released under the Apache-2.0 license.
Creator: Tool: SPDX-Tools-1.0
CreatorComment: SPDX Version 2.2 SPDX-Tools-1.0: SPDX-Tools-1.0In this example, we find information such as SPDX version, data license, package name and version, package download location, checksum, package homepage, source information, stated license, etc. This information can be used to generate a complete list of dependencies for the software package.
Here is another example, but with CycloneDX format:
<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1" serialNumber="urn:uuid:562f1c4d-0eb9-4129-8a3a-d6c0e47fd0f8">
<components>
<component type="library" name="example-library" version="1.0.0">
<purl>pkg:maven/org.example/example-library@1.0.0</purl>
<licenses>
<license id="Apache-2.0"/>
</licenses>
<dependencies>
<dependency ref="pkg:maven/org.apache.commons/commons-lang3@3.0.1">
<scope>compile</scope>
</dependency>
</dependencies>
</component>
</components>
</bom>In this example, we find information such as the software component’s name, version and universal package resource identifier (PURL), as well as its licenses and dependencies. This information can be used to generate a complete listing for application dependencies.
It is important to have a standard because it enables effective communication and collaboration between the various stakeholders involved in the development, distribution and use of application solutions by improving transparency and traceability, safety, compliance and efficiency.
This is particularly important in an increasingly complex and interconnected environment.
In the context of containers, it is crucial to understand the software dependencies that reside in a container image. This can help identify vulnerabilities quickly and determine what updates are needed in the event of a security breach. This is where the SBOM comes in, providing a comprehensive list of all components and dependencies of a containerized image.
Adding it to containerized images also helps track version changes and dependency updates over time, providing better visibility into security and compliance. By attaching it to the containerized image, development teams can easily identify vulnerable components and take action to fix security flaws.
Container management tools such as Docker and Kubernetes allow it to be attached to containerized images.
For example, since Docker version BuildKit v0.11 there is support for build attestations and SBOMs, allowing to create images with information of how the image was built, such as the SBOM.
Attestation manifests are attached to the root image index object, under an OCI image manifest distinct. Each attestation manifest can contain multiple attestation blobs, with all attestations in a manifest applying to a single platform manifest. All properties of the standard OCI and Docker manifests continue to apply.
This makes it easier for you to answer common questions, such as what packages the image contains, where the image was created from, and whether you can reproduce the same results locally.
It should be noted that its automated generation is a key point which makes it possible to avoid the CMDB effect which diverges after 2 days and which is totally part of a CI.
It is important to include the publication of SBOM in its pipeline
In sum, attaching SBOM to containerized images in an automated way is essential to ensure transparency and traceability of the software components used in the container environment.
Obfuscated dependencies are software or system components whose source code is difficult to read or understand, making it difficult to identify direct or indirect dependencies.
In particular, obfuscated dependencies, direct or indirect, can pose a security concern when undetected in container images. Container images may include binaries or dependency libraries whose names have been changed to disguise their true origin. This makes it difficult for security tools to detect vulnerabilities in these dependencies.
An example is the compilation of an application in binary (Go, native Java, C, C++, …) which by nature hides all the dependencies which make most scanners or security tools obsolete.
Similarly, some container images may not be directly scannable due to being inaccessible (no package manager, no shell). this is for example the case of some minimalist images: "From scratch" images, Distroless images, Chainguard images, …
From a security point of view, the use of binaries or minimalist images is rather a good thing, but it is much less relevant if we cannot reliably scan the content of these artifacts…
This is where the SBOM also becomes very interesting and makes it possible to solve this type of problem by attaching it to the metadata of the image!
By attaching it to the metadata of the image, it allows to have a complete and precise view of all the dependencies used in the image the use cases described previously and without having to have sophisticated scanning tools.
We will see in another article how to ensure the integrity of the components and in particular the SBOM.
In complex development environments, multiple SBOMs may be generated for different components used. It is important to consolidate these into a single global one to provide a complete overview of the software components used throughout the system. This helps to better understand the complexity of the system and to facilitate the management of risks associated with dependencies.
Comprehensive security solutions have this kind of functionality and even more, such as:
For this need for consolidation, a script can be made manually, but beware of development costs and maintainability.
Also beware of solutions only integrated into the registry because this can generate a lot of false positives (images present but not active)
In conclusion, SBOM is a key element in the security and transparency of the software supply chain. With the latter, DevOps teams can have a complete and precise view of all the dependencies used in their applications, which allows them to manage the evolution of the versions and to have a real governance of the dependencies but also to detect and resolve vulnerabilities faster. This is particularly important in a Supply Chain Attack context, where attackers can infiltrate a software supply chain and insert malicious components into legitimate applications.
By integrating it into a DevSecOps approach, DevOps teams can work in collaboration with security teams to strengthen the security of their applications and detect threats more quickly. It also enables faster response to security compliance requirements, while improving application quality.
In short, it is an essential tool to guarantee the security and transparency of the supply chain!