Let’s try to understand the buzz about SBOM before we jump into the definitions and granularity of this!
Over the years, SDLC and supply chain has changed drastically and climbing higher with every update in this global software industry. Most Organisations have moved from a monolithic to a microservice architecture for flexibility, scalability, resilience and efficiency.
2021 saw a series of software supply chain attacks and breaches like Apache Log4j, Codecov, etc., cause widespread damage with a single exploitation stroke. Such recent attacks have been highly disruptive and exposed significant supply chain vulnerabilities.
So when the stakes are high for organisations globally, could the SBOM be the Silver Bullet to secure the Supply Chain?
SBOM stands for Software Bill of Materials. An SBOM is a detailed granular list of components packaged into any given application or software installation file, with their metadata included.
It carries a complete inventory rundown of a codebase that lists the open-source and third-party components, licenses, patch status and version information.
They provide critical visibility into software components and supply chains.
In the wake of the Uber hack and the recent Log4Shell vulnerability, organisations are prioritizing cybersecurity and are actively mapping out plans to ensure their departments, partners and stakeholders are building greater cyber resilience.
The concept of an SBOM is not new, but it has garnered much more interest lately due to the recent U.S. Cybersecurity Executive Order and the UK Government Cyber Security Strategy: 2022 to 2030.
First, there is the code for your application, which could be of an NPM project, Python scripts, etc. The Code then goes through the CI/CD pipeline, and if all goes well, there is an artifact which might be a container or a package.
Now that we have the inputs, we can now generate an SBOM which can be digitally signed and given to clients
1. An SBOM must describe the supplier of the software and the author of the SBOM:
2. The organization/person that created the artifact.
3, The tool used to generate the SBOM.
4. The timestamp when the SBOM was generated.
5. Complete description of the artifact components, including:
A. Component name and version.
B. A unique identifier (e.g. CPE / PURL / SWID).
C. Relationship with other components.
It can be leveraged in various cases but are most helpful during a Company merger or acquisition.. It also saves the organization's finances, time and money by identifying weak portions early in the SDLC, since these can be stored in a single place which reduces costs but increases productivity. Futuristic product planning can be done more constructively.
They can now code easily since there exists a knowledge base of sorts that details all the up-to-date third-party resources, components, libraries and containers that can reduce coding time and deliver a secure application. This can lead to a streamlined and efficient codebase. Additionally, developers are more likely to work with a familiar library or framework in their code, which leads to less duplication of effort and faster development time.
Security teams also benefit from this, since visibility into the risks that
exist, their potential impact and issues that need to be prioritized ensure security and resiliency across applications and supply chains. They are also designed to reduce the impact of cyber incidents, identify issues early and resolve them before they cause greater harm. You can leverage this knowledge to research your product, find pitfalls and track the organization's progress.
They can be used as a “Technical Due Diligence” process to aid during compliance audits. The SBOM can elaborate the components and features for enterprises to comply better with various data protection regulations and help verify license compliances. Compliances and Audits become easier since only certified components and authorised dependencies to make it to the final package.
Conclusively, the hash values listed in the SBOM help verify the components for integrity and authenticity via digital signatures.
Though the SBOM cannot directly manage any application’s exposure to attacks and breaches, it definitely is a solution that can be used as leverage to improve capability.
1. Despite the fact that it brings a good deal of Clarity and Transparency, it can only verify if a vulnerable version of Log4j exists in a given codebase, which covers only that single application. Organisations with humongous lines of code and hundreds of applications would need an SBOM for every codebase which could get cumbersome, financially draining, not to mention time-consuming.
2. The lack of a concrete way to determine all the components of an application introduces substantial cybersecurity risks, alongside the cost of development, procurement, and maintenance.
3. SBOMs today are not nearly granular enough, and by simply matching vulnerabilities, it does not pinpoint the actual exposure.
4. The SBOM is often overlooked when updating a dependency.
5. As for an attacker, this Software Supply Chain is more vulnerable because, instead of having to crack individual attacks on multiple applications, they can craft just a single attack to hit thousands or even millions of targets.
6. If a vulnerability is found. The real scenario is you would need to have a dedicated team just checking for vulnerabilities every morning and pushing out the patches.
It ideally needs to be a formally structured list of components, libraries and modules that are used/required to build a piece of software and the supply chain association between them. The elements used can be open-sourced, proprietary, freely accessible or restricted for internal access.
Any powerful SCA tool can generate a complete open-source SBOM with third-party and custom components included. Automated tools have the flexibility/scalability to integrate into any organisation's CI/CD pipeline.
So the most recent up-to-date security vulnerabilities are highlighted before an attack or breach occurs to security, licensing, or operational issues associated with open-source software.
SCA is complementary to SAST. While SAST checks 1st-party code for security flaws, SCA looks at 3rd-party code like open source libraries.
A manual approach, though more time-consuming and prone to human error is best suited for modest projects with only a few moving parts
Challenges.
A. Adaptability for every patch/update.
B. Keeping track of versions for each software component.
C. Crucial to have an up-to-date and accurate SBoM to assess vulnerabilities and risks properly.
In addition to all these parameters, NIST describes the practices and processes that organisations need to follow when supplying SBOMs:
SBOMs must be updated with every change of the software content or version
It must contain all direct and indirect dependencies of the software product.
In case of missing details, the SBOM should carry information of the same.
It must be accessible to the customer in readable formats.
Adequate controls to be set to access the SBOM
As they always say Knowledge is Power, knowing the detailed components that make up any software application or product helps keep track of security vulnerabilities and ensure that the system is resilient and robust to a point.
Maintaining an SBOM for every piece of software is vital and important. This works in tandem with all the teams progressing toward a Disaster Recovery plan, especially during an incident that comes along with the use of any open-source or third-party software.
An SBOM helps shed light on the contents and origins of a program and, when combined with vulnerability management tools, can help detect vulnerabilities and highlight risks for future mitigation. At we45, we undertake a comprehensive study and help detect any security flaws that allow our partners to market a product which is error-free and compliant with international security standards. Through our security architecture review, we unearth common security flaws and the ones you didn’t even know you had. The We45 team undertakes an in-depth data analysis from the design phase through the entire SDLC. We help bolster your security measures without compromising on speed. We45 is the industry leader in implementing Application Security, DevSecOps, Software Supply-chain security and Cloud Native Security. Connect with us today to learn more.
