SBOM, a key building block in supply chain risk management

In my previous blog, I talked about what software supply chain attack is all about. It occurs when a threat actor infiltrates a network and employs malicious code in the software before the publisher sends it to their customers and then it compromises the customer’s systems. Such attacks affect all users of the compromised software and can have widespread consequences for organizations and their infrastructure and data.

Traditionally, organizations developed applications in-house and this enabled developers to gain control over the entire codebase. However, this model cannot meet today’s time-to-market demands. As the expectations and pace increase, it’s impossible to meet the demand with home grown software. So, there is a need for open source software contributed by software professionals around the world. Open source software facilitates rapid development and release cycles. It enables developers to incorporate ready-made components into their application so they can quickly release software enabling organizations to deliver software to their end users.

70%+ companies use open source software and the demand for it is growing year by year. The contributions from multiple software professionals, lack of all security controls and faster release cycles expose newer vulnerabilities everyday for attackers to exploit. At the same time, security risks related to the origin of software have become a major concern for organizations recently, in large part due to software supply chain attacks. Hence, it is important for organizations to analyze the composition of software applications and dependencies on open source or other software to identify the exposures.

What is SBOM and why is it important?

SBOM, Software Bill of Material, helps to identify and track all third-party components, particularly open source software, and comply with required licensing requirements. It is something that more and more enterprises are likely to demand from their software vendors going forward. This means that every software publisher will have to manage SBOMs for their software products to remain competitive in the marketplace.

It gained special attention in May 2021 when the White House passed an executive order that requires software vendors to maintain and produce SBOMs for their products. It ensures that organizations use open source software in a secure and compliant way. Hence, it needs to be managed properly for any software application from security point of view.

As a security best practice, it is important to make SBOM management a core part of software development process for building and releasing software.

Composition of SBOM

SBOM is a list of components that form a software as well as metadata about the components.

Common elements of an SBOM:

• Open source libraries that an application uses
• Plugins, extensions or other add-ons that an application uses
• APIs that the application uses
• Cloud services or 3rd party services that the application is dependent on
• Proprietary code written by developers for that software application
• License status of the components
• Known vulnerabilities and patching status

Benefits

For organizations, it’s a point of reference to understand the composition and dependencies of the software application and identify exposures in the business critical applications. From a security perspective, it helps organizations ensure that the software they use is up-to-date and patched against known security vulnerabilities. Generally, open source libraries include licensing terms mandating that the authors of the component receive attribution. The licensing information in the SBOM helps legal team ensure that the software applications comply with licensing requirements.

Standards

SBOMs generally use one of the following two well recognized standards. There is Software Identification (SWID) format in which tags are considered more of a software identifier than an SBOM format. It does provide a simple and transparent way to track software inventory but its use is limited to software identification only.

• CycloneDX - sponsored by the Open Web Application Security Project (OWASP). The metadata describes the elements such as components, services, and dependencies and the relationships between them.
• Software Package Data Exchange (SPDX) - sponsored by the Linux Foundation. It defines 3 elements: a) Documents, metadata about the SBOM, b) Packages, groups of elements c) Files

Stages

There are different types of SBOMs followed today that organizations may source from different product artifacts. Different stages at which SBOM is created are –

1. Design — at this stage, SBOM is a set of components for the new software artifact under design, which is typically derived from the design specification. This highlights the required components ahead of licensing purchase but may be very difficult to generate at such an early stage.

2. Coding — created directly from the development environment, source code, and dependencies used to build artifacts. Generally, software composition analysis (SCA) tools like OWASP dependency check, Snyk, etc are used to identify dependencies and SBOMs are generated from this. This will provide a view of hierarchical component structure, identify unused and vulnerable components. An SBOM at this stage helps to remediate vulnerabilities in the source code. However, this will never discover components used at the runtime.

3. Build — generated as part of build process from source files, dependencies, built components, and other SBOMs. This will be better than coding stage as the representation of all dependent artifacts is more accurate in the build phase. During the build stage, the artifacts can also be signed by giving more secured and confident status, however, the runtime dependencies are still not discovered until this stage.

4. Runtime — at this stage, SBOM is an assembly of other SBOMs that combines configuration options in a deployment environment that includes static components, dynamically loaded components, and external call-outs. This gives a better visibility into what is in use and what it is not and provides a complete analysis of the overall application from all aspects.

Best Practices

The following best practices should be followed to manage SBOMs efficiently and effectively.

• Standard Format — one basic best practice is to ensure that a standard format is followed when structuring SBOM data. Several popular SBOM formats exist, including SPDX and CycloneDX that I explained above. However, there is no mandate to use a specific SBOM format and there is no industry standard has emerged so far.
• Regular Updates — after an SBOM is created, it is the responsibility of the software publisher to maintain and update it as the composition changes over time such as code changes, bug fixes, inclusion of new libraries, changes to external API calls, etc. These changes must be tracked in real time, otherwise the SBOM will be of no use if it is outdated.
• Automation — automatically generating SBOMs should be part of the software CI/CD pipeline and such SBOMs should be cryptographically signed and verified. Non-verification would undercut the value of having an SBOM in the first place.
• Auditability — it is important to audit everything contained in the SBOM like software components, their versions and licenses. It must come from trusted sources and must be verifiable by a third party.
• Release Cycle — SBOMs should be updated with every release of the application and should be updated every time a dependency or version change of a component is added or removed. Doing so ensures that customers will know definitively whether they are affected by vulnerabilities or licensing mandates associated with a specific version of the product.
• Transparency — The SBOM should clearly show the current state of the application and what needs to be done to properly secure it. The SBOM should clearly display existing files and components, files in use, known vulnerabilities, security issues, and known bugs or limitations in software components.
• Extended Format — the lack of universal standards leads to software publishers adding other details like licensing details and patching status. It also positions them to update vulnerable components of the product more quickly in the event that a security vulnerability is announced in one of the components they ship.

How it impacts SaaS applications

Typically, SBOMs are provided for applications installed and managed by customers. But question is should SBOM be provided for SaaS applications? While many may argue this is not required, however, I would recommend SBOMs for SaaS applications too. Providing SBOMs for SaaS applications can alert customers to situations where the SaaS platform may be compromised due to a vulnerability. Even if customers don’t have to fix the vulnerability themselves, knowing about it can help them achieve their own security goals.

Conclusion

SBOMs are amongst the best ways for organizations to maintain the security of their systems, applications and data. They also set a precedent in the industry by increasing transparency between developers, software vendors, and customers. With the help of SBOMs, organizations will be more successful in identifying exposures, zero-day vulnerabilities, and advanced persistent threats.

Adoption of SBOM and its best practices is a clear gain for software supply chain security in the industry and will enable enterprises to focus on their business without a lot of worry for supply chain attacks.

Note: The same blog is also published on https://medium.com/@shubhomohanty/sbom-a-key-building-block-in-supply-chain-risk-management-ce722b74afdc