What a recent customer conversation taught us about turning software supply-chain transparency into operational security controls
In a recent conversation with a multinational industrial manufacturing company, we were demonstrating what we normally think of as software supply-chain operations.
We showed how an organization can collect SBOMs from its own development teams and external suppliers, continuously analyze third-party components for vulnerabilities, assess package health and provenance, enforce quality policies, communicate findings back to suppliers, document risk acceptance, and maintain an audit trail of what happened.
Then the company’s security leader made an observation that changed the direction of the discussion.
From his perspective, this was not simply SBOM management.
He was looking at parts of his CIS Critical Security Controls implementation.
That is an important distinction.
For years, SBOMs have primarily been discussed as artifacts: something software producers generate because a customer, regulator, procurement team, or internal security organization asks for one.
But the security value of an SBOM does not come from possessing the JSON file.
It comes from what an organization can continuously do with the information inside it.
Look at CIS Control 16
CIS Control 16 focuses on Application Software Security and the security lifecycle of internally developed, hosted, and acquired software.
One safeguard is particularly relevant to the software supply chain: CIS Safeguard 16.4, “Establish and Manage an Inventory of Third-Party Software Components.”
The wording is strikingly close to the operational purpose of an SBOM program.
Organizations need an up-to-date inventory of third-party components used in development, need to understand the risks associated with those components, and need to evaluate whether those components change, require updates, or remain supported.
That is not a request to generate an SBOM once.
It describes a lifecycle.
Imagine an organization with hundreds of applications, dozens of development teams, external software suppliers, embedded products, and thousands—or millions—of third-party component relationships.
A folder full of SBOM files does not solve that problem.
A continuously maintained component inventory might.
From “What Do We Have?” to “Should We Be Using It?”
The next CIS safeguard makes the difference even clearer.
CIS Safeguard 16.5 focuses on using up-to-date and trusted third-party software components.
Once an organization has reliable component inventory data, several operational questions become possible.
Is the component still maintained?
Does it contain known vulnerabilities?
Has it been associated with known exploitation?
Is the package coming from the expected ecosystem and source?
Has the underlying project effectively been abandoned?
Did the supplier introduce a new dependency in the latest release?
Does organizational policy allow the component?
Is there a better-supported alternative?
These questions move SBOMs beyond transparency.
They turn software composition data into a decision system.
The distinction is important: knowing that a package exists is useful. Knowing that a package exists, represents elevated risk, violates policy, appears across 37 products, and should be replaced is actionable.
Vulnerability Management Becomes a Workflow
CIS Safeguard 16.6 addresses systematic severity ratings and prioritization of application vulnerabilities.
This connects naturally with CIS Control 7, Continuous Vulnerability Management.
Again, an SBOM alone does not implement vulnerability management.
But an actively managed SBOM repository can provide critical context.
A newly disclosed vulnerability can be matched against known products and releases. Security teams can identify affected components and their dependency paths. Exploitability information such as VEX can add context. Known exploitation can change priority. A risk can be accepted with documented justification, or remediation can be assigned and tracked.
For externally supplied software, the workflow becomes even more interesting.
Instead of discovering a potential vulnerability and starting an unstructured chain of emails, the customer can raise the finding directly with the software supplier, request an exploitability assessment or remediation, track the supplier’s response, and preserve the full interaction as evidence.
The control is no longer represented by a policy document saying, “We manage vulnerabilities.”
There is evidence that the process actually happened.
Supplier Security Is Where This Gets Really Interesting
The same customer conversation highlighted another connection: CIS Control 15, Service Provider Management.
Traditional third-party security programs are often heavily questionnaire-driven.
An organization asks a supplier how it manages vulnerabilities, whether it follows secure development practices, whether it tracks its dependencies, and how quickly it responds to security issues.
Those questions remain useful.
But software supply-chain data creates another category of evidence.
What if you could also measure what the supplier actually delivers?
How consistently does the supplier provide an SBOM?
How complete are those SBOMs?
How quickly does the supplier respond when quality issues are identified?
How many known vulnerabilities are introduced?
How quickly does the supplier provide VEX information?
How long does remediation take?
Are unsupported or poorly maintained components repeatedly appearing?
Is SBOM quality improving or deteriorating over time?
Suddenly, supplier security assessment is no longer only an annual statement about process maturity.
It can also include continuously observed technical evidence.
This aligns particularly well with the intent behind CIS Safeguards 15.5 and 15.6: assessing and monitoring service providers.
It does not eliminate SOC 2 reports, contractual reviews, questionnaires, or broader third-party risk management.
It complements them with something they historically lacked: evidence from the actual software supply chain.
The Next Step Is Executable Governance
This leads to what we believe is the more important evolution of SBOM management.
Framework requirements should be connected to executable policies.
Consider CIS 16.4.
Instead of simply marking the safeguard “implemented,” an organization could define what implementation means for its software environment.
For example, all in-scope product releases may require a current SBOM. Third-party components may require strong identifiers. Transitive dependencies may be required. Unsupported components may generate a finding. SBOMs older than a defined threshold may be considered stale.
The resulting evidence can then be evaluated continuously.
The organization can answer not only:
“Do we have a policy?”
but also:
“Which products currently satisfy it?”
“Where is evidence missing?”
“Which suppliers are failing the requirement?”
“What changed since the previous audit?”
“Which accepted exceptions are about to expire?”
This is a very different compliance model.
It moves from periodic attestation to continuous technical evidence.
Be Careful With the Word “Compliance”
There is an important caveat.
No SBOM platform makes an organization “CIS compliant.”
The CIS Controls span enterprise assets, identity, data protection, network security, malware defenses, awareness training, incident response, penetration testing, and many other areas far beyond software supply-chain management.
Good governance software should make that distinction explicit.
A safeguard might be directly operationalized by a platform.
Another might merely receive useful technical evidence from it.
A third might require integration with another system.
Many will simply be outside the platform’s scope.
That transparency matters.
The goal is not to turn cybersecurity frameworks into another marketing checkbox.
The goal is to make the parts that can be measured and enforced genuinely measurable and enforceable.
SBOMs as Security Evidence
At Exodos Labs, this conversation reinforced a direction we have increasingly been pursuing.
We do not view the SBOM as the end product.
We view it as one of the richest sources of structured evidence about a software supply chain.
When SBOMs are continuously collected, versioned, validated, enriched, analyzed, connected to suppliers and products, and combined with governed workflows, they become far more useful than static compliance artifacts.
They become evidence.
And evidence can feed policy.
Policy can create findings.
Findings can trigger action.
Actions can be audited.
That is where software supply-chain transparency begins turning into governance.
And sometimes a customer conversation makes that connection clearer than any product strategy workshop could.
