One of the hottest topics in cybersecurity is software supply chain security. From targeting popular vendors of proprietary software to exploiting widely used open-source software components and libraries, software supply chain threats consistently rank among the top concerns for CISOs and practitioners alike.
To combat this threat, organizations continue to try to bolster their cybersecurity supply chain security risk management (C-SCRM) programs and practices. These efforts include making use of software bills of materials (SBOMs) to get visibility into their software consumption. That visibility will tell them what components they’re consuming that might be vulnerable and have known exploitations, as well as what might exceed their organizational risk tolerance.
That said, the concept of SBOMs is fairly immature and is still evolving in the industry. Luckily, organizations such as the National Security Agency (NSA) continue to create guidance for how to make use of these artifacts to mitigate software supply chain risk. Let’s dive into some of the key recommendations from the NSA’s “Recommendations for SBOM Management” guidance.
NSA SBOM Recommendations
The NSA’s recommendations are broken down into three primary areas: risk management, vulnerability management, and incident management. This includes activities such as determining software authenticity along with the associated vulnerabilities and overall risk exposure. I’ll walk through some of the key recommendations below.
For suppliers, the NSA recommends activities such as maturing the exchange of SBOMs with customers and consumers to provide further transparency. There’s also the call for suppliers to take “ownership of customers’ security outcomes” aligned with efforts seen from other government agencies such as the Cybersecurity and Infrastructure Security Agency (CISA), with its push for secure-by-design/default software, as well as in the National Cybersecurity Strategy (NCS), which calls on software vendors to take more responsibility for the safety and security of the products they ship to consumers.
Taking ownership is advocated on the grounds that vendors, as producers of products, are better equipped to handle the risk. Externalizing this cost onto downstream customers, often lacking internal cybersecurity expertise and resources, is seen as detrimental.
Ask Cloud Wars AI Agent about this analysis
Recommended SBOM Tool Functionality
The NSA guidance makes several specific recommendations around SBOM tooling. These include ensuring the SBOM tooling that organizations use supports the two leading SBOM formats of SPDX and CycloneDX, as well as support for JavaScript Object Notation (JSON), Extensible Markup Language (XML), and Continuous Security Validation (CSV) both for input and output purposes.
Additionally, the guidance recommends that SBOM generation occur at various phases of the SDLC, such as building and analyzing binaries. The guidance recommends adopted SBOM tools have the ability to display the minimum elements of SBOM as defined by the National Telecommunications and Information Administration (NTIA) and can graphically represent components as well as provenance information, providing insight into the origins of software from upstream dependencies.
SBOM tools should have an intuitive user interface (UI), making them accessible to non-experts and broader organizational stakeholders while also providing graphical representations of assets in the organization and the associated vulnerabilities to help assess risks.
AI Implications
While not explicitly called out, it is clear that an arms race is underway between attackers and defenders as both look to exploit artificial intelligence (AI) for their respective intentions. Malicious actors will increasingly look to use AI and AI-powered tools to accelerate their software supply chain attacks, including identifying and compromising widely used open-source software packages and components and finding vulnerable organizations to impact with these activities.
On the defensive side, many startups are now integrating AI capabilities into their platforms and products in attempts to help offset the attempts of malicious actors and address longstanding workforce challenges with cyber expertise. They are also offering co-pilot-based tooling to enhance secure software development activities, including producing more secure code and making better open-source software component selections to mitigate supply chain risks.
How successful each party will be with the use of AI for their intended purposes remains to be seen but one thing is for sure: much will be revealed as 2024 plays out and attackers and defenders increasingly look to explore the value of AI and AI-powered tooling.