Building secure software using the Software Bill of Materials
In May 2021, the President released the Executive Order on Improving the Nation’s Cybersecurity (Executive Order). The Software Bill of Materials (SBOM) directly impacts all developers. The SBOM requires third-party software companies to provide customers with the code equivalent of a “nutrition chart.” Looking toward the future, organizations should consider the impact that the Software Bill of Materials will have on software development practices.
What is the Software Bill of Materials?
Although the Executive Order mentions SBOM in the body of the text, the definition is buried at the end. The SBOM consists of the following:
- A formal list of supply chain dependencies
- Details about open source and commercial software used to develop software
- Machine-readable format to enable automation and tool integration
Additionally, the Executive Order notes that these “gain greater value” when stored in a collective repository. This repository could end up looking a lot like the National Checklist Registry, which provides technical configuration baselines for software and firmware.
Who needs an SBOM?
Any end-user who works with software should be using the SBOM to detect known vulnerabilities and mitigate risk. However, the Executive Order’s definition also includes the “personas” that should find the SBOM useful.
Software Developers
Software developers often incorporate open source and third-party software components into their builds. Recognizing this, the Executive Order suggests that developers can use the SBOM to:
- Keep components updated
- Respond to new vulnerabilities
In this context, the Executive Order assigns software developers the responsibility for maintaining source code security.
Software Buyers and Operators
On the other hand, the Executive Order also assigns responsibility to software buyers and operators. In this use case, the SBOM acts as a way to:
- Perform vulnerability or license analysis
- Evaluate a product’s risk
- Review potential risks arising from newly discovered vulnerabilities
The Executive Order suggests that organizations should be using the SBOM as part of their third-party risk management program and continuous monitoring strategies.
3 Reasons Tracking Open Source Vulnerabilities is Challenging
The SBOM’s “heart is in the right place.” In other words, securing the software development lifecycle (SDLC) is fundamental to security. However, tracking and mitigating open source code vulnerabilities is more challenging than the Executive Order implies.
Locating the vulnerabilities
Detecting vulnerabilities in open source code proves challenging because developers are responsible for monitoring updates. Unlike proprietary software that pushes security update notifications to users, open-source code developers often drop updates into a repository. In the end, people using this code need to monitor the repository and pull the updates themselves.
Lack of visibility into reachability
Not every new vulnerability is exploitable. In other words, new open source vulnerabilities might be found, but threat actors may not be able to “reach” them. To determine reachability, developers need to know whether attacker input can reach the vulnerable code.
To gain this level of visibility, developers should use both static and dynamic vulnerability assessments. Dynamic assessments provide insight into whether a threat actor can actually exploit the vulnerability. Static assessments enable visibility into whether a threat actor can potentially exploit it.
Dynamic assessments review whether a threat actor can actually exploit a vulnerability during:
- Unit testing
- Integration testing
- Live operation
Static testing determines whether a threat actor can potentially execute an exploit in the following locations:
- All libraries an application uses
- Archives across different contexts
Understanding risk posture
These challenges lead to the most significant issue facing organizations: to rate open-source code vulnerability risk adequately. Developers need a way to detect and prioritize vulnerabilities based on whether threat actors can actually exploit them.
Remediating an unreachable vulnerability wastes time that could be spent on securing a reachable vulnerability or updating an application’s features. The Executive Order hints at the need to take risk into account. However, software developers, buyers, and operators need to go beyond simply cataloging components. They need to understand how those open source and third-party components impact their overarching risk posture.
Taking a risk-based approach to open-source software component security
As software developers start building out their SBOM strategies, they need to understand how open source component risk impacts their compliance posture.
Continuously monitor and analyze code
Monitoring application and code security continuously is key to mitigating risks. Despite this, ShiftLeft research indicates that only 48.8% of organizations require developers to check application security while writing new code. Additionally, 37.8% of developers noted that they lose the most productivity when reviewing code while writing it.
To comply with SBOM’s goals, developers need tools that rapidly analyze code for vulnerabilities. Ultimately, developers need a solution that enables them to track data flow for visibility to determine a vulnerability’s reachability.
Statically identify vulnerabilities at compile time
Leveraging both static and dynamic assessments would provide the needed visibility into whether threat actors can actually or potentially exploit a vulnerability. However, individually, these assessment types come with different burdens. Static analyses often generate too many false positives, leaving developers unable to prioritize activities appropriately. Meanwhile, dynamic assessments come with a high runtime cost.
Leveraging a static analysis tool that is able to identify the exploitability of a vulnerability like dynamic analysis will allow developers to prioritize bug fixes. This reduces the cost and the number of false positives.
Build security into your development lifecycle
Finally, development teams need to incorporate security across the entire software development lifecycle. Software Composition Analysis (SCA) solutions scan code for known vulnerabilities in open-source components within an application. This process enables developers to gain visibility into the dependencies within the application’s code.
SCA and Static Analysis Security Testing (SAST) solutions enhance security prior to pushing an application to production. These solutions reduce the risk that software will lead to a data breach while saving time for the developer team.
Secure code development for SBOM compliance
Compliance with these new mandates also means documenting processes. By connecting security and development workflows, organizations can increase productivity while decreasing security risk.
By bringing these two teams together, organizations can also establish the documentation both need. Security, development, and compliance teams should all agree on processes, practices, and documentation to enable SBOM compliance. With tools like ShiftLeft CORE, organizations can establish a secure software development lifecycle. In doing this, they can enhance application security and meet compliance requirements.
Top comments (0)