August 13 2022 | 11 min read
Educational | August 13 2022 | 11 min read
As more software is ingrained into almost every organization, software developers are under more pressure to rapidly deliver revenue-impacting applications. With speed of delivery as a requirement, developers use third-party libraries to perform actions that would otherwise take days – or weeks – to develop. The issue, however, is with this benefit comes the introduction of security risks. Risk of vulnerabilities are a concern as organizations depend more on third-party libraries that must be fully maintained and updates must be frequently deployed to remediate security issues.
It’s not uncommon for a corporate application to have dozens of third-party libraries, and they must be tracked so that any updates can be tested and installed as part of the software development lifecycle. This led to the development of a Software Bill of Materials (SBOM), and a recent US Executive Order on Improving the Nation’s Cybersecurity requires any government entity to have one.
An SBOM is similar to a supply chain document in manufacturing and product development. In product development supply chains, the manufacturer uses parts from specific vendors, installs components to build the product, and then tracks a product’s travel history from the manufacturer to the retail store where you purchase it. As an example, server machines in a network environment are built using vendor parts delivered to the manufacturing plant, the server is built, and then it travels from one location to another until it arrives at a data center where it’s installed. Every step in this process is a part of the supply chain.
At any point in the manufacturing process, an attacker has opportunities to manipulate parts, inject their own malicious component, steal sensitive or proprietary information (might it be text, code, tokens etc.), or otherwise damage the integrity of a product. Similar to the manufacturing process, attackers have opportunities to inject their own malicious content into software. Attackers could hack the developer and inject their own code or silently take over an open-source repository. In open-source libraries, a malicious threat actor could contribute code with obfuscated malicious functions that the repository owner does not catch during a pull request review.
An SBOM is a document that tracks the supply chain in software development. It keeps track of every third-party library, script, CI/CD application, artifact (e.g., Docker), license, and version integrated into your applications. For small businesses with just one application, it might seem like tracking the supply chain is simple, but it can soon become overwhelming as your software development lifecycle adds several more moving parts. An SBOM ensures that every element integrated into your software including dependencies are tracked and can be audited for security issues.
You might wonder why you would want to add SBOM generation to your software development lifecycle if you don’t have government customers and don’t plan to work in any public sector. Having an SBOM does more than just keep an organization compliant with government requirements. An SBOM tracks the supply chain in software development, so it has many benefits for software security and license tracking.
Most organizations need an SBOM for compliance and security, but where do you start? Even if you already have means to generate an SBOM, it’s important for you and your developers to understand the anatomy of an SBOM to identify issues and make decisions based on output from the document.
The National Institute of Standards and Technology (NIST) lays out some guidelines for an SBOM document, but organizations can define the document in whatever way works best for their security. Although organizations can format the document in any way that they want, they still must have specific attributes in the SBOM document to stay compliant.
Your developers can determine the way this document and its information are laid out and organized, but they must be present for the SBOM to follow compliance and stay resourceful for the development lifecycle. A well organized SBOM document makes it much easier for developers and security teams to get the information they need in the event of an update/patch, determine if any component was recently compromised, and determine if a review of infrastructure is needed to identify if the organization is at risk.
A good SBOM is more than just data fields. It also has automation behind its generation and your organization should put practices and procedures in place for it. Many development and security teams focus on the data fields, but attention should be paid to the other components in SBOM anatomy.
You could build your own automation tool by using the output from the various generation tools, but products such as Apiiro will perform the automation for you, making it much more convenient and efficient to add automation to the SBOM’s document generation. An SBOM will evolve as more libraries and software are added to your infrastructure, so automation makes the process much more efficient and reduces the risk of mistakes or oversights.
SBOM output can also be in standardized data formats such as JSON or XML. These documents are used by your own software tools to analyze and report information to developers, security teams, and operations people. Output in standard data formats can then be used to build reports in formats best for stakeholders such as Word documents or Excel spreadsheets, but this option must be configured and built by your own developers.
Most development and security teams have their own procedures in place to make the software development lifecycle efficient, and the generation and automation of an SBOM should be no different. Here are a few items to consider when you put your SBOM procedures in place:
To stay compliant, the US government supports three formats, each of which serve a different purpose. The format you choose will depend on the purpose of the document. Most companies use SBOMs for supply chain security, but they also track licensing and any changes to the software development lifecycle.
Here is a brief breakdown of each format:
|Supported by||OWASP||Linux Foundation||NIST|
|Format standard||No standard format, but OWASP defines specifications.||ISO/IEC 5962:2021||ISO/IEC 19770-2:2015|
|Unique identifiers supported||SWID, CPE, PURL||CPE, PURL||SWID|
|Target audience||Developers and Security teams||Developers and administrators||Governments and developers working for governments|
|Output formats supported||json, xml, protobuf||xls, rdf, json, yml||xml|
As you can see from the file formats listed above, CycloneDX has much more flexibility. It’s one reason why many security teams prefer the CycloneDX format, but SPDX and SWID have their purposes depending on your goals.
The CycloneDX format is primarily for documenting the cybersecurity of your software. It’s a flexible standard, because it allows the document creator to generate a custom format best designed for their own customers. OWASP provides an open-source SBOM generation tool in several languages.
Primary output from the generation tool is in JSON and XML, but developers can use this output to create their own documentation format. However, the custom documentation should be thorough with all data fields necessary for it to be considered a compliant SBOM.
The generation tool is built for developers, so stakeholders with no development experience will find it difficult to use. Apiiro’s SBOM generation tool takes care of the technical side and allows a much easier and convenient way to create an SBOM and ensures that it contains enough information to validate the security of your systems.
The following JSON output is an example of CycloneDX output:
Introduced by the Linux Foundation, SPDX formats are used to scan applications and validate that your organization has proper licensing to run them. Licensing violations can be severe for large enterprises that use applications without knowing if they can be used for commercial purposes. Some applications allow individuals to use them for free, but they must be paid for if used for commercial purposes.
As more software licenses structures are introduced, it becomes a challenge for organizations to ensure that they follow regulations properly. An SBOM discovers applications and helps organizations determine if the installed product is compatible with licensing.
Linux Foundation has a Git repository with open-source SPDX generation tools, but again you need to understand code and how to execute it. The following is a simple example of SPDX output:
The SWID format, which was originally created in 2009 and later updated in 2015, is generally used in development environments to validate that software has not had any unauthorized changes, prevent installation of unauthorized software, detect unauthorized changes to installed software, and identify vulnerabilities in software that must be patched. SBOMs with this format are generally integrated with the software development lifecycle especially in large enterprise organizations that have several developers working within a trusted environment.
NIST introduced NISTIR 8060 guidelines as well as modifications that lay on top of SWID to make it useful for security use cases and to show accountability across development.
The following is an example of SWID tagging output:
Since SBOM creation is relatively new, you might wonder where you would fit the automation process into your own systems. An SBOM can help your organization’s credibility in several situations and help improve security.
Here are some examples of where an SBOM process can help an organization:
Defining an entire procedure to handle automation and SBOM generation is a huge challenge, but Apiiro makes it much easier to generate a precise SBOM document. Indeed, our platform will automatically discover your assets and lower the time to remediate risks throughout the software supply chain.
Our inventory functionality is highly valuable for organizations that need automation in SBOM generation. Whether you need to create an SBOM to show to investors or a large enterprise organization that needs better licensing and security control of third-party applications, Apiiro will provide you with a fully automated way to generate it.
Discovering dependencies and software within your organization is the first step in reducing your attack surface. With Apiiro, your developers and security teams will have more visibility into all aspects of your software, open-source dependencies, and installed applications.