In 2021, the U.S. government issued an executive order aiming to shore up the country’s cybersecurity against the skyrocketing number of threats and security incidents the nation was facing.

One of Executive Order 14028’s major focuses was on the security of software used by the federal government. Through the order’s mandates, the U.S. government aims to establish a baseline security standard for any software development services or products sold to government agencies.

Following the launch of the order, the National Institute of Standards and Technology (NIST) has been actively working to improve the software supply chain’s security. So far, they’ve focused on creating guidelines, standards, and best practices that address security deficiencies in software development and deployment processes.

Part of this work has included incorporation of recommendations into version 1.1 of the Secure Software Development Framework (SSDF), a publication providing a comprehensive framework for secure software development. The document outlines a series of best practices to help organisations integrate security throughout the software development lifecycle and improve the security and resilience of software.

Organisations can use the SSDF to guide their secure development processes and enhance transparency, traceability, and security across the software supply chain.  To ensure traceability and transparency throughout the Software Development Life Cycle (SDLC), organizations must maintain Software Bills of Materials (SBOMs) and consider sharing it publicly wherever necessary. This practice, recommended by the NIST SP 800-218, helps manage software inventory, track lineage, identify drift, and enhances the Secure Software Development Framework (SSDF).

What is a Software Bill of Materials (SBOM)?

An SBOM is a detailed inventory of all components, libraries, and dependencies within a software application. Logging all this information with an SBOM means that anyone can see exactly what makes up any given piece of software—much like a list of ingredients.

This makes it a crucial tool for identifying and managing vulnerabilities within an application (especially in complex software systems) and providing transparency about the various elements that constitute an application.

Why SBOMs are essential for securing your SDLC

If you want to properly secure your SDLC, implementing SBOMs is crucial. Since SBOMs provide a comprehensive inventory of all components used in a software application, you get more detailed visibility into all the moving parts within your application. This helps you achieve more proactive vulnerability management, better compliance, and faster incident response and supply chain integrity verification—all of which add up to a more secure software development process.

Let’s take a closer look at why SBOMs are essential for a secure SDLC:

Transparency and visibility: Since SBOMs provide detailed visibility into the components of software products, they can help realise the goal of greater transparency and accountability in the software supply chain.

SBOMs list all open-source and third-party components, making it easier to identify and manage each element. They also help you track dependencies and make sure that all components are up-to-date and all potential vulnerabilities are secured.

Vulnerability management: SBOMs enable the identification of known vulnerabilities within components, so you can be more proactive with your risk management. They improve your patch management too, facilitating timely updates and patches for vulnerable components, and therefore reducing the risk of exploitation by bad actors.

Compliance and regulatory adherence: SBOMs help you make sure you’re in step with regulatory standards, industry laws, and open-source licences by providing detailed, accessible documentation of software components.

Plus, creating an SBOM means you’ll have an audit trail for software components, which is essential for accurate compliance checks and security audits.

Incident response and mitigation: SBOMs also help with incident response, allowing organisations to identify and mitigate the impact of vulnerabilities more quickly once they’re discovered. This makes them especially useful when working with third-party and open-source components, and facilitates trust-building between software producers and consumers.

And once you know which component caused the issue, you can focus your impact analysis, assess the impact of a vulnerability or breach on the software, and create more effective mitigation strategies for next time.

Supply chain security: I Having an SBOM in place can enhance the trustworthiness of your software by ensuring that all components from suppliers are verified and secure. By providing detailed information about the software’s composition, components can be acknowledged, secured, and verified at all touchpoints throughout the software supply chain.

This transparency also reduces the risk of a software supply chain incident; as an SBOM provides a clear view of all components and their sources, the ability to use compromised or malicious code is vastly diminished.

Quality assurance: SBOMs help maintain consistency in software builds by documenting all components, versions, and configurations. Having a comprehensive SBOM will enable tracking of unauthorised changes in production too, allowing development teams to avoid so-called ‘application drift’ and maintain consistent quality by tracking the components used across different versions of software. And, having this clear roadmap of the software’s composition supports ongoing maintenance and quality assurance processes.

Although by no means fool-proof, having a comprehensive, well-maintained SBOM to hand will help create a robust chain of custody for dependencies and internally developed components.

If organisations implement SBOM processes properly and in line with the guidance laid out in the SSDF, they can take significant steps towards a more transparent and accountable SDLC.

What can happen when you don’t have an SBOM in place?

Not having an SBOM can result in significantly unpleasant consequences. By failing to maintain an SBOM, you’re potentially compromising the security and integrity of your software systems, opening yourself and your entire supply chain up to increased risk.

Without an SBOM in place, your SDLC could suffer:

Increased vulnerability to attacks: Without an SBOM, your organisation lacks visibility into the components and dependencies within its software, making it difficult to identify and mitigate vulnerabilities.

Delayed incident response: In the event of a breach, it can be really difficult to quickly identify and isolate affected components without an SBOM, delaying your response and mitigation efforts.

Non-compliance with regulations: Many regulations and industry standards require detailed documentation of software components. Without an SBOM, your organisation may fail to meet these requirements, which can lead to seriously costly penalties. If you’re subject to regulations like the GDPR or CCPA, for example, you could face fines and legal actions if you can’t demonstrate comprehensive documentation and control over your software supply chain.

Increased supply chain risks: Verifying the integrity and security of components sourced from third-party suppliers is tough without an SBOM to refer to, and without this information, you’re at increased risk of supply chain attacks.

Ineffective patch management: Identifying and applying patches to vulnerable components is more difficult without an SBOM, creating delays in updates and leaving software exposed to known vulnerabilities for longer periods.

Operational disruptions: The increased security risk that comes with not having an SBOM can lead to incidents that disrupt your operations, incur financial losses, and cause reputational damage.

Loss of customer trust: Repeated security incidents and breaches—especially those caused by unpatched vulnerabilities and supply chain compromises—can severely erode customer trust and damage your organisation’s reputation.

SBOM failures in action

Few incidents highlight the critical need for an SBOM more clearly than the SolarWinds attack.

The notoriously sophisticated and wide-reaching cyber espionage attack grabbed headlines when it was discovered in December 2020.

When attackers gained access to the SolarWinds network, they were able to insert malicious code into the build environment of SolarWinds’ Orion software, a popular IT management product used by thousands of global organisations and government agencies.

The compromised Orion software was then distributed to customers through regular updates in early 2020, creating backdoors in the affected systems and allowing the attackers to conduct further exploits undetected.

The scale of the attack on the SaaS company, affecting more than 18,000 organisations and the U.S. government, perfectly exemplifies the need for SBOMs to ensure visibility, security, and control over software components. Had SolarWinds maintained a comprehensive SBOM, several aspects of the attack could have been mitigated or even prevented.

An SBOM would, of course, have provided a detailed inventory of all components and dependencies in the Orion software; this visibility would have made it easier to detect unauthorised changes or additions to the code base.

The same goes for its third-party suppliers. An SBOM would’ve verified the integrity of components from third-party suppliers so that any deviation from the expected SBOM could be flagged and further investigation could be carried out before distribution to customers.

And if that didn’t catch the issue, SBOM maintenance could have helped. Routine maintenance would have allowed SolarWinds another opportunity to identify the insertion of malicious code during routine checks or external audits, potentially catching the compromise earlier.

It could also have assisted with incident response, helping SolarWinds and its customers quickly identify all affected versions and instances of the software, once the malicious update was detected. Faster analysis would’ve meant a more swift and targeted response to mitigate the damage.

An SBOM would have detailed all dependencies, too, making it easier to track and manage updates or changes to any part of the software. In hindsight, this enhanced scrutiny of components during the build process could have helped spot the injected code.

And finally, there’s the regulatory aspect. Many regulatory frameworks require detailed documentation and auditing of software components; adhering to these requirements through an SBOM would have enforced stricter controls and may have highlighted irregularities sooner.

While an SBOM is not a silver bullet, it does provide crucial visibility and control over software components, making it significantly harder for malicious actors to insert and distribute compromised code without detection.

In the case of SolarWinds, maintaining an SBOM may have enabled earlier detection of the malicious code insertion, faster incident response, and more robust supply chain security, potentially preventing the widespread impact of the attack.

We’ll never know how things might’ve been different for SolarWinds—all we do know is that the impact is ongoing, with new breaches linked to the hack still occurring.

SolarWinds has already settled a class action lawsuit, paying out $26 million to shareholders who cited SolarWinds’ negligent and misleading internal security procedures. The company is also currently being sued by the U.S. Securities and Exchange Commission, marking the first time the SEC has taken action against a cyberattack victim. The lawsuit alleges that the company misled investors about its cybersecurity practices and failed to disclose known risks.

How do you create an SBOM?

Are you ready to give your SDLC security a boost? Here’s how you can put together your own SBOM.

At the moment, there are no hard-and-fast rules about what information should be included in an SBOM, or how to create and maintain them. However, the National Telecommunications and Information Administration (NTIA) is working to standardise SBOMs, with NIST supporting these initiatives by integrating SBOM requirements into its broader cybersecurity frameworks and creating guidelines and standards to encourage the adoption of SBOMs.

So if you want to create an SBOM, you have a bit of wiggle room. They can be generated in multiple formats, for example, with popular options including SPDX and CycloneDX.

Key elements of an SBOM

Creating an SBOM involves systematically documenting all components, libraries, and dependencies used in a software application. Here’s a starting point for what it should include:

1. Component identification:
   1. Name: The name of each component.
   2. Version: The specific version of the component used.
   3. Supplier: The organisation or entity that supplied the component.
2. Relationships:
   1. Dependencies: Information on how components depend on one another.
   2. Hierarchy: The structure or tree of components, showing which components are nested within others.
3. Licensing information:
   1. Licenses: The licenses under which each component is distributed for compliance and legal considerations.
4. Vulnerability information:
   1. Known Vulnerabilities: Identified vulnerabilities associated with each component, if any.
5. Metadata:
   1. Timestamp: The date and time when the SBOM was generated.
   2. Author: The entity or individual that created the SBOM.

How RiverSafe can help

Providing services both directly and through vendor partners, RiverSafe can help your organisation develop a robust SBOM and ensure the best practices outlined in the Secure Software Development Framework are embedded throughout your SDLC.

Ready to get started?

Contact us