With the growing use of third-party components and lengthy software supply chains, attackers can now compromise many software packages simultaneously via a single exploit. In response to this new attack vector, more development and DevOps teams, as well as security professionals, are looking to incorporate a Software Bill of Materials (SBOM).
The software supply chain includes everything used to make the application, from the unique code engineers write to the development tools they use, and to any third-party components (proprietary and open source) in the code base. While developers take responsibility for their own code, an SBOM tracks the information needed to ensure the security of every third-party component. This includes:
- Where it was sourced
- The specific version in use
- Any known vulnerabilities and patch status
- Where and when it is used in the application
- Licensing information
And any other relevant security information.
By understanding every line of code that goes into the final product, organizations can demonstrate secure development practices and provide assurances to their customers.
With SBOMs finding significantly wider use, IT research and consulting firm Gartner recently released “Innovation Insight for SBOMs,” a report describing the concept, its benefits, the various standards in use, and recommendations for organizations implementing SBOMs.
As many people will not have access to Gartner’s full report, we present some of the key findings as well as our own take on what organizations need to consider for successful SBOM use. But first, let’s discuss the current state of software supply chain attacks.
The rising risks to software supply chains
Although software packages try to differentiate themselves from the competition and focus on what makes them different, there will always be some overlap in terms of basic functionality. For example, every organization will need to encrypt user data, and most need to consider syncing across multiple devices.
While developers could spend significant time and effort writing code to perform these general functions, it is much easier to incorporate ready-made components already in use. Whether purchased or open-source, third-party code simplifies the development process and significantly reduces time to market.
However, it also introduces vulnerabilities. Software today is only as secure as the weakest link in the supply chain. Attackers exploit this fact, targeting commonly used or out-of-date components in the software supply chain at a growing rate.
A recent report found only 216 software supply chain attacks between February 2015 and June 2019. This number took a significant jump to 929 attacks between July 2019 and May 2020, followed by an explosion with over 12,000 software supply chain attacks in 2021, a year-on-year increase of 650%.
Source: Dark Reading
A 2021 Forrester survey of 530 cybersecurity decision-makers found that 33% of external attacks now come from third-party services or software vulnerabilities.
Given the recent acceleration of attacks, it is not surprising the U.S. government has made software supply chain security a new priority. This includes the release of the Secure Software Development Framework (SSDF) and a September 2022 OMB memo setting cyber investment priorities for the 2024 fiscal year, both of which give ample attention to mitigating supply chain risk.
With skyrocketing attacks, famous examples in the news (e.g., SolarWinds, Log4J, etc.), and the U.S. government sounding the alarm, organizations need to increase the visibility of their software supply chain and maintain a comprehensive Software Bill of Materials for each of their products.
SBOMs to the rescue! Increasing visibility, trust, and security in software supply chains
Necessity is the mother of invention, and a threat as significant as supply chain attacks certainly necessitates a solution. Thankfully, the invention of SBOMs means we now have the tools to fight back, ensuring only secure and trusted components make it into the codebase.
SBOM is based on the physical Bills of Materials (BOMs) commonly found in manufacturing or construction. For example, automobile manufacturers utilize a BOM to inventory every component used in each vehicle, whether it was built by the OEM or a third party. If a problem arises with a particular part, BOMs allow manufacturers to identify every affected vehicle and inform the owner.
SBOMs are the software industry’s equivalent. Acting as an inventory for every software component present in each product. If a component is found to have a vulnerability, organizations can quickly determine the affected users and make plans to inform and mitigate the risk.
With complex software stacks incorporating a vast number of open-source and other third-party components, it can be challenging to keep track of every risk a product is exposed to. SBOMs allow development, DevOps, and security teams, and even customers, to understand this risk, quickly looking to see if a newly identified vulnerability affects them.
SBOMs also help to:
- Prevent license poisoning—When open source components open your intellectual property, exposing your product for everyone to see.
- Identify risk in legacy code—Breaking down existing code bases to identify every third-party library, open-source repositories, development tools, and more to determine potential out-of-date components or any other risks present.
With many benefits on offer, SBOMs are seeing significant uptake. However, a recent report found that while 76% of organizations have a degree of SBOM “readiness,” only 47% were actively using SBOMs in 2021. This figure is predicted to rise to over three-quarters of organizations in 2022 (78%) and almost 90% the following year.
Source: VentureBeat
Gartner’s Innovation Insight report for SBOMs—High-level summary
Gartner’s 2022 Innovation Insight Report on SBOMs offers critical information on the importance and implementation of Software Bill of Materials:
“Software bills of materials improve the visibility, transparency, security, and integrity of proprietary and open-source code in software supply chains. To realize these benefits, software engineering leaders should integrate SBOMs throughout the software delivery life cycle.”
Organizations often struggle to maintain the visibility of proprietary and open-source dependencies, generating significant software supply chain security risks and potential compliance issues. This is because they lack adequate tools or fail to implement secure development practices and standards.
With an SBOM, developers can discover and compile security details on every piece of third-party code in their software package. The rise of software supply chain attacks demonstrates the failure of treating open-source or commercial code as an airtight, secure “black box.”
Without knowing what’s inside the “box,” you can never truly understand the risks your software is exposed to. Therefore, the best solution is to meticulously track every “box” you use to check against known vulnerabilities.
Gartner recommends every organization:
- Generate an SBOM for every software package they produce
- Verify SBOMs for all software consumed (either open-source or commercial)
- Continuously reassess SBOM data to understand new security risks (both before and after deployment)
Given the increasingly threatening software supply chain landscape, Gartner predicts 60% of organizations building or buying software for critical infrastructure will mandate SBOMs. That’s triple the current number (20%) in 2022.
“SBOMs are an essential tool in your security and compliance toolbox. They help continuously verify software integrity and alert stakeholders to security vulnerabilities and policy violations.”
How does it all affect you?
So, what does this all mean for you and your organization? Gartner recommends that organizations:
- Utilize SBOMs to track dependencies across the entire software supply chain, taking into account every component in the software development life cycle
- Automate the generation of SBOMs using tools to scan and verify your products systematically
- Rapidly respond to any affected components found within the software supply chain
- Update SBOMs with every new software artifact, i.e., creating SBOMs during the build process rather than only at the start of a project
- Only reuse modules with verified and secure SBOMs
- Implement a standards-based SBOM process based on widely supported formats, such as Software Package Data Exchange (SPDX), Software Identification (SWID), or CycloneDX
- Ensure any commercial software providers you work with also utilize SBOMs with a standards-based approach
- Share SBOMs and provenance data with stakeholders, making them aware of affected components and risk-related data
SBOMs are critical tools for modern software security. But to improve the situation across the industry, they need to be made accessible in and outside the organization. Sharing vulnerability data in the form of an SBOM also increases the confidence and trust of stakeholders, letting them know that no known vulnerabilities are present in the software they use.
Scribe Security offers a hosted SBOM management platform with sharing capabilities. Helping organizations guarantee container integrity and provide actionable insights on the software they produce. Get started for free by signing up for early access to the Scribe Platform.
The Scribe Security take on Gartner’s report—transparency and evidence are key
At Scribe Security, we believe SBOMs are key to protecting modern software packages built on top of expanding supply chains. SBOMs comprehensively document the development process to guarantee end-to-end visibility of the entire supply chain. Our platform combines an SBOM’s visibility with transparency, thanks to sharing features across teams and organizations.
Scribe provides a hub where both software producers and consumers can come together to share attestations on the trustworthiness of various software packages or components. We utilize cryptographic techniques to collect digital signatures tracking changes during development. These signatures ensure an evidence basis guaranteeing the validity and security of a software’s supply chain.
Even smaller operations that might not consider generating SBOMs at the moment can benefit from understanding the process. Scribe offers continuous scans, even if you have a stable version in production, so you can check for new vulnerabilities and identify trends throughout your software development lifecycle.
Summary
With the incredible growth of software supply chain attacks, organizations need to consider new methods for guaranteeing the safety of the software products they build and the software products they use.
The first step is generating a Software Bill of Materials detailing all components present in software package codebases. Understanding what is running allows organizations to stay ahead of vulnerabilities and share the integrity of application builds.
Gartner’s recent report on SBOMs sums up the situation well:
“SBOMs help organizations to determine if they are susceptible to security vulnerabilities previously identified in software components. These components could be internally developed, commercially procured or open-source software libraries. SBOMs generate and verify information about code provenance and relationships between components, which helps software engineering teams to detect malicious attacks during development (e.g., code injection) and deployment (e.g., binary tampering).”
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
