SBOM: Where’s My Threat Model?

Those writing about supply chain security apparently believe that the supply chain threat model is obvious and implicitly confined to unpatched vulnerabilities. But reducing the threat model to vulnerabilities misses one of the critical aspects of threat models, to wit, how software components’ interactions create exploitation possibilities.

The existing SBOM standards provide a method to wrangle software dependency graphs (software composition - SCA) while lending a format for disclosing vulnerabilities contained in each graph. Focus so far has been about those vulnerabilities that may lie hidden in opaque dependency trees, making these issues visible and thus, addressable.

‍

‍

SBOM in SDLC, NTIA.gov, “Survey of Existing SBOM Formats and Standards - Version 2021”, https://ntia.gov/sites/default/files/publications/sbom_formats_survey-version-2021_0.pdf

To be sure, dependencies can drag in all sorts of vulnerability exposure which must be included in any comprehensive threat model. Luckily, a plethora of tools that scan through dependency chains to identify issues and out-of-date versions exists. Unaddressed is the threat model when two or more pieces of software are combined. The threat model of each component may be significantly changed because of the interaction.

Interaction, exchange of data, input and output opens new attack surfaces, and potentially new exploitation possibilities. In the case where each of the pieces has made different security assumptions, creating interactions can open worlds of attack potential. Importantly, component threat models cannot simply be summed; the new interaction requires a revised, holistic threat model that includes each component’s while also accounting for their interactions, as well.

In other words, putting software together engenders a threat model of the new, total piece of software: a combined software “system”. If we were to add a threat model to each SBOM throughout the SBOM dependency tree it might be represented something like our threat model additions to NTIA’s SBOM in SDLC diagram (reproduced above):

‍

‍

Notice how there are two threat models that must be factored into the system’s model:

The model of the software being produced
The models from the software that’s being included

Each “procured”, i.e., included piece of software will include or depend upon any number of additional software in a chain of dependencies. Likewise, the chain of threat models must also be taken into account in order to arrive at a comprehensive total threat model. Each inclusion, each new interaction, as we have noted, can open new threat and countermeasure possibilities.

There are three competing SBOM standards ^[1]. CycloneDX and Software Package Data Exchange (SPDX®^[2]) describe the software, its components and dependencies, licenses, and can include vulnerability disclosure. SWID tags can be used in any SBOM and are concerned primarily with software provenance: version/patch verification and use authorization^[3].

VeX can be used to include vulnerability risk analysis, say for any unpatched vulnerabilities that don’t, in context, pose significant risk when inherited through use or inclusion.

None of these standards communicate the described piece of software’s threat model. As noted, above, the threat being addressed is vulnerability management, license misuse, and software provenance, not an holistic threat model (which must include, of course, vulnerability management).

Perhaps in the future, SBOM specifications might be expanded to include each component’s threat model, say in Open Threat Model (OTM) format. That would go a long way to providing sufficient information for generating a combined threat model that accounts for threats (and threat exclusions) of each included or called component of the total system. SBOM threat models don’t exist today, unfortunately.

A potential modest refinement to SBOM to address its threat modeling shortcomings might be to at least include each component’s security posture assumptions.

Posture should enumerate the security controls and countermeasures that the software has implemented, if any? Assumptions would be what security the software provides to callers and the security controls it expects from its various forms of interactions. Describing this basic data isn’t a complete threat model. However, describing expectations and controls indicates the security thinking that’s already been completed as a part of building the software, i.e., these items point to the software’s threat model, whether explicit or implicit.

In the meantime, we strongly suggest that users of SBOM do not rely on it alone for their threat model. Always consider the implications of each software interaction, each flow, each point on a system where an attacker might try to attack (ergo, attack surfaces).

Today, there’s no substitute for enumerating assets whose compromise will negatively impact the stakeholders and users of a system and assessing what the potential effects of various compromises will be.

Cataloging potential threats and identifying their countermeasures (threat modeling) remains a fundamental part of securely building software. This is true whether components include an SBOM or not.

[1] Please see https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1

[2] SPDX is a trademark of International Standards Organization (ISO)

[3] Much explanation and commentary has already been published on SBOM specifications, SBOM, use, SBOM importance. We see no need to repeat that well-documented information here.

‍