After some serious cyberattacks in the past few years, such as SolarWinds in March 2020 and Colonial Pipelines in 2021, most organizations are taking more security precautions regarding their software. 

In fact, in line with these events, the US government published Executive Order 14028 to strengthen the country's cybersecurity and mitigate supply chain risks. Specifically, this document encourages US agencies to only deal with vendors that provide a software bill of materials, also known as an SBOM, to keep their data secure.

By entering your email you agree to the Privacy Policy and consent to receive emails from Cledara.

What is an SBOM?** 

Perhaps you’ve heard a similar term before: BOM (bill of materials), which is used in supply chains and manufacturing. A BOM is a detailed list of materials needed to manufacture a product.

An SBOM, or software bill of materials, is a comprehensive inventory, encompassing all components and dependencies associated with the creation and distribution of an application.

A single piece of software consists of multiple components, including: 

• Databases
• API’s
• Libraries
• Documentation

Besides, each of these elements is constantly updated and releases new features. 

All in all, software systems encompass intricate, ever-changing, and frequently unclear supply chain components. This unclear structure can pose security risks for your company. Therefore, the SBOM is a document that every trustworthy software vendor should provide.   

Why SBOMs Matter**

All in all, any software development company targeting the US public sector should be concerned about SBOMs. They’re essential for qualifying as a state supplier, yet they can also give your company a competitive advantage in non-governmental markets. By providing SBOM, you can ensure your users:

• Enhanced security
• Higher quality standards
• Embedded compliance
• Better customer support 

Enhanced Security

Nowadays, every company relies on multiple software applications for its daily operations. An SBOM allows your users to easily understand the components and dependencies within your product. 

This comprehensive view gives IT teams a greater grasp of the software ecosystem and more control over it. And thus, they can effectively detect and address potential security vulnerabilities before cyberattackers can exploit them. 

In a nutshell, an SBOM ensures that potential risks associated with third-party libraries or outdated components are identified and managed appropriately. By providing an SBOM, you help protect your client's data and systems while also making the job of IT teams easier. 

Higher Quality Standards 

Executive Order 14028 requires U.S. public agencies to do business only with suppliers that provide SBOMs. This may have started with government agencies, but it will largely spread to all companies that want to keep their data secure. 

By providing SBOMs, your users can be sure that you have high software development and documentation standards.

Embedded Compliance

In addition to government entities, many industries are subject to software management and reporting mandates. These mandates include regulations such as the General Data Protection Regulation (GDPR) or the Federal Information Processing Standards (FIPS).

By providing SBOM with your product, you can guarantee your clients seamless adherence to these guidelines. In short, you can simplify the job of Compliance teams. 

Better Customer Support

By having a detailed SBOM, you’re well aware of all the software components of your product. This makes it easier to track and resolve problems that may arise. And therefore, you can ensure better customer support.  

Overall, providing SBOMs entails offering visibility and traceability of the software components at issue. When a company includes an SBOM with its software, it portrays an image of transparency to customers, fostering trust and credibility in the market.

SBOMs’ Essential Elements**

The US National Telecommunications and Information Administration (NTIA) recently published a report defining the minimum requirements for SBOMs in compliance with Executive Order 14028. 

According to this document, there are several ways to create an SBOM. Besides, since software is continually changing, SBOM parameters are constantly evolving as well. 

However, as guidance, NTIA recommends that SBOMs should at least include: 

• Data files
• Automation 
• Practices & processes 

Let's break them down.

Data Files

Essentially, an SBOM represents a consistent, uniform structure that captures and presents the information needed to understand the components of a software piece. Each data field contains baseline information about a component that needs to be tracked and maintained. 

This baseline information includes:

• The supplier’s name
• The component’s name
• The version of the component 
• Other unique identifiers 
• Dependency relationship
• Authorship and the date the SBOM was created

These are essential items, but other information can be added to the SBOM as well. For example: 

• License information associated with each component, such as open source or proprietary licenses. 
• Hash values for each component. This information can help users verify the integrity and authenticity of software components during updates or installations.
• A list of known vulnerabilities associated with each component. This allows organizations to prioritize risk mitigation efforts based on their specific software inventory.
• Information on whether a specific component is up-to-date with patches and security fixes. This helps users maintain secure configurations within your application ecosystem.

Automation

To establish a standardized approach for creating SBOMs, the NTIA advises software vendors against using manual processes. Instead, it's recommended to use automation tools and data formats that streamline the generation of SBOMs. 

By using automation tools and data formats, the SBOM information will be human and machine-readable, as well as easy to track for IT teams. 

The NTIA suggests the following formats: 

• Software Package Data eXchange (SPDX), developed by the Linux Foundation. It provides a standardized way to share license, copyright, security vulnerability, and other component-related information across organizations. 
• CycloneDX, it provides lightweight and easily understandable SBOMs that can be parsed with minimal overhead in various development environments.
• Software Identification (SWID) tags are defined by the ISO/IEC 19770-2 standard and help streamline compliance management and mitigate security risks.

Practices & Processes

An SBOM does not only involve data and specifications. It also involves new practices that software vendors must adopt to stay up to date with these standards. 

A proper SBOM should comply with the following attributes:

• Frequency- in case a software component undergoes an update, vendors should generate a new SBOM that accurately represents the new software version.
• Depth- an SBOM should be as descriptive as possible and provide a comprehensive list of software components.
• Mention the unknowns- SBOMs should list all component dependencies that are present in the software, even if some dependency details are unknown, incomplete, or the component has no further dependencies. 
• Distribution- SBOMs should be readily accessible to authorized individuals in a timely manner, with appropriate access permissions and roles established. The SBOM data can either accompany each instance of the software or be easily accessible and directly associated with the specific versions
• Mistake accommodation- SBOMs are still in their developing phase, so users should tolerate occasional mistakes or omissions that could occur.  

The Challenges of SBOM Implementation**

In the wake of the major cyberattacks and the White House's call for stronger cybersecurity, many organizations are beginning to incorporate SBOM into their software products. 

However, SBOM implementation presents some challenges, such as: 

• Standardization
• Staying up-to-date
• Security itself

Let’s take a closer look. 

Standardization

The lack of standardization in SBOM formatting across the industry poses a significant challenge. While establishing a consistent standard for SBOM creation and sharing is vital to maximizing benefits, reaching a consensus may take time.

Staying Up to Date 

Most organizations develop dynamic software that undergoes periodic updates and introduces new features. As a result, SBOMs must be constantly updated with each software release to preserve their relevance and safety. 

Similarly, organizations need to plan processes to update their security measures as SBOM’s updates are released. 

Security Itself

Lastly, managing the security of the SBOM itself poses a challenge: it contains sensitive information. SBOMs provide information about software components utilized in the development process, including possible security vulnerabilities. As a result, organizations must implement measures to protect the SBOM from unauthorized access or disclosure.

Ensure Security & Compliance with Cledara**

Becoming a supplier for public entities presents an ambitious challenge for any software company. To qualify as a government supplier in the US, companies must adhere to rigorous quality and performance standards. But most importantly, they must ensure that sensitive government information is safe from unauthorized access or security breaches. And keeping your SaaS stack under control is one way to achieve it. 

Why? According to our collected data, companies are only aware of 40% of the software used by their employees. Unauthorized software (also known as shadow IT) can lead to security vulnerabilities, exposing corporate, client, and personal data. 

Here’s where Cledara can help.

Cledara is the only software management platform that: 

• Gives you a centralized view of all your software subscriptions
• Prevents shadow IT
• Streamlines the way you evaluate and monitor your SaaS subscription suppliers  
• Ensure all vendors have the right security measures in place
• Monitors software usage and expenses in real-time
• Provides detailed audit trails
• Natively embeds the key steps required by ISO27001 and SOC2 into your company’s processes
• and more

Curious? Book a Cledara demo today.