Manage the rising risks in your software supply chain

What’s at stake?

Software supply chain attacks can lead to financial and reputational losses — or even prosecution from the Securities and Exchange Commission (SEC).

In continued fallout from the 2020 SolarWinds attack, the SEC recently “informed current and former SolarWinds executives that it intends to recommend ‘civil enforcement action’ alleging the company broke federal securities laws in its public statements and ‘internal controls.’”

Our software and services are integrating an increasingly complex supply chain of components, partners and other dependencies. As we increase the dependencies that our applications have on open-source software, software development kits and other third-party elements, we also increase our potential new risks.

We need new approaches that identify and manage this new dimension of third-party risk.

The software bill of materials (SBOM)

The first step in mitigating your organization’s software supply chain risks is to identify and understand them. A software bill of materials (SBOM) is an inventory of all of the constituent components and software dependencies involved in designing, building and operating an application. An SBOM is becoming an essential instrument for systematically managing software supply chain risks, and it is now required for some government contracts. 

In many ways, managing today’s software risks is third-party risk management — but traditional approaches to third-party risk management do not provide enough visibility into the security state of the software being procured. Evidence-based artifacts like an SBOM and VEX can actually attest to the security posture of software your organization procures, working together to help address the combined third-party and software-security risks.

How to use an SBOM

An SBOM is not just a document to keep for future reference. It is a tool that software buyers can use to understand and manage potential risks during and after procurement of the software. To effectively use a third-party SBOM, establish and use a programmatic approach with consistency in the design, build and operate phases.

Design phase

In the design phase, establish and use consistent:

• Perspectives: Application security and third-party risk management are unique professional disciplines. Third-party risk, procurement and application security professionals should invest time to establish a common language for communicating requirements, risks, and resolution paths.
• Standards: Develop standards for what “good” looks like in an SBOM, with risk tolerance thresholds. Put another way: Gain consensus on the type of software “bill of health” the organization can tolerate, and what would cause it to walk away from a business relationship with a software vendor.
• Terms: Work with the legal team to revise contract terms, both on SBOM requirements and remediation service level agreements, then communicate those expectations to key software suppliers.
• Updates: Change is constant — so, determine the frequency of consuming new SBOMs for existing applications, including minor or major versions.

Build phase

In the build phase, establish and use consistent:

• Intake: Define processes that identify and implement preferred methods of acquiring SBOM files: uploads, downloads or via APIs.
• Tools: Select an SBOM/VEX management tool, and build a process for analyzing and communicating issues.
• Templates: Revise third-party risk reporting templates to include SBOM analysis results.
• Workflows: Build vendor and internal communication and risk escalation workflows.
• Policies: Define a policy workflow for triggering, analyzing and communicating new findings in existing SBOMs.

Operate phase

In the operate phase, establish and use consistent:

• Diligence: Establish SBOM/VEX intake during the due diligence process.
• Reporting: Ensure that initial SBOM/VEX analysis results are included in risk assessment reports.
• Remediation: Define remediation action steps, negotiate timelines with the vendor, and file any time-bound risk exceptions.
• Registration: Update a risk register as your team closes and validates findings with new SBOMs.
• Tracking: Triage, communicate and track to closure any emerging findings for existing SBOMs.

This programmatic approach to using an SBOM in each phase might seem straightforward, but there are some common mistakes that can create unnecessary confusion for all involved parties and negate any risk reduction benefits.

How not to use an SBOM

Here are some of common pitfalls to avoid, as procurement, third-party risk and application security teams begin to ingesting SBOM files provided by their software vendors:

Insufficient analysis: Simply collecting Software Package Data Exchange (SPDX) or CycloneDX (CDX) files in a static internal repository is not an effective use of this powerful new instrument. SBOMs can help reduce the risks associated with third-party applications, but only if your organization has a way to continuously analyze the files against emerging vulnerabilities. Ingestion and analysis must be dynamic and automated to be effective.

Insufficient updates: If your organization only asks the software vendors for the SBOM at the point of procurement, the information will quickly be outdated. Today’s software release velocity assures that the next version of your team’s software will have a different composition from what your organization originally purchased. At a minimum, SBOMs must accompany all major versions.