A software bill of materials gives businesses visibility into the components and dependencies within the software they rely on. But simply having an SBOM doesn’t necessarily make software more secure. Its value depends on its accuracy, completeness and usefulness in identifying and addressing potential supply chain risks.
When reviewing a vendor’s SBOM, business leaders need to look beyond the document itself to assess whether it supports meaningful security practices. Below, members of Forbes Technology Council share key questions businesses should ask vendors to determine whether an SBOM is a useful risk management tool or simply a compliance exercise.
How is open-source software integrated into your technology?
What portions of the SBOM are open-source software, and how is it integrated into the technology? For instance, you should be able to inquire whether the vendor is sourcing OSS from global community servers or if they have a certified version they keep secure and pull from to build. Also, examining the OSS community—number of commits, as an example—is a way to see how mature the OSS is and whether that specific OSS component is a risk the vendor has properly addressed. – John Cho, EdgeConneX
Does the SBOM support automated remediation decisions?
An actionable SBOM connects components directly to provenance, validated exploitability and continuous Vulnerability Exploitability eXchange (VEX) data. If your security team still has to manually reconstruct that context to determine risk, the vendor gave you compliance documentation, not supply chain security. – Javed Hasan, Lineaje
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
Is the SBOM automatically updated with every release?
Ask, “Does this SBOM get updated automatically with every release, or is it a static snapshot from months ago?” A vendor who can’t show continuous, version-linked updates is handing you documentation, not risk management. Real risk reduction means you can trace a newly disclosed vulnerability straight to affected components within hours, not weeks. – Agung Dwi Sandi, rankpillar Group
Who is responsible for fixing vulnerabilities in production components?
Ask which items on this SBOM are running in your production build today and who owns the fix the day a known exploited vulnerability hits one of them. A PDF generated at contract signing is documentation. A living inventory that maps each component to a running version, an owner and a reachable path is a control. If they can’t name the owner and the refresh cadence, you’re auditing paper, not risk. – Srinivas Mukkamala, Securin Inc.
Does the SBOM accurately reflect the software currently deployed?
An SBOM can be perfectly formatted yet operationally useless if it is stale, incomplete or blind to transitive dependencies. Require build-linked generation, version traceability, dependency coverage and declared unknowns. Supply-chain visibility has a half-life; if the software changes and the SBOM does not, trust becomes an illusion. – Rajjie Sarmey, FutureProof CXO™
How quickly do you patch exploitable vulnerabilities in sub-dependencies?
You need to know how often the SBOM is updated and what the verified SLA is to patch an exploitable flaw deep in a sub-dependency. A static PDF listing third-party packages is just compliance theater. Real risk reduction requires knowing whether the vendor continuously generates fresh SBOMs with every build and takes active operational ownership when an open-source dependency breaks. – Mahendran Chinnaiah
Is the SBOM continuously monitored for newly disclosed vulnerabilities?
Businesses should ask whether the SBOM is actively monitored and updated against new vulnerability disclosures, not just delivered once as a static snapshot. An SBOM only reduces risk if it feeds into a process that alerts the organization when a listed component is affected by a newly discovered flaw, enabling timely remediation rather than sitting unused. – Dennis-Kenji Kipker, cyberintelligence.institute
What decision will we make differently when this SBOM changes?
An SBOM creates value when new exposure triggers action. Ask one question: “What decision will we make differently when this SBOM changes?” If the answer is “none,” you have documentation, not risk management. Knowing what is inside the software is not the same as controlling the risk inside it. – Kelvin Cheema
When a new vulnerability appears in a listed component, how quickly can you determine our exposure, notify us and remediate it?
An SBOM only reduces risk when tied to continuous monitoring, ownership and action. A satellite operator cannot rely on a static inventory while vulnerable ground-system software remains deployed. Request evidence from a past vulnerability: detection time, impact decision, customer notice and fix. Documentation must drive response. – Shelli Brunswick, SB Global LLC
What checks catch a component missing from this inventory?
A clean vulnerability scan can mean the software is safe or that the vulnerable part was never listed. Have the vendor select a component from the shipped product and trace it back to the SBOM. An inventory reduces risk only if you can trust its omissions as well as its entries. – Mani Padisetti, Almost Magic Tech Lab
Does the SBOM cover indirect dependencies and known vulnerabilities?
Ask whether the SBOM includes transitive dependencies and known vulnerabilities for each component. Many SBOMs list only direct dependencies, missing the deeper supply-chain risks. A meaningful SBOM shows the full dependency tree and maps each component to current CVE data, enabling you to assess exposure, not just inventory parts. – Harsh Jangid, Coozmoo Digital Solutions
Does this SBOM trace third-party AI model dependencies and token routing, or just static code libraries?
In enterprise SaaS, static code is only half the risk. If the vendor’s SBOM doesn’t map the lineage of their LLM integrations, training data pipelines and agentic workflows, you aren’t managing supply chain risk; you’re just inventorying legacy code while ignoring the AI attack surface. – Eshaan Jain
Can you identify the exact software build covered by the SBOM?
Ask which build the SBOM describes and whether you get a new one with every release. Most of the ones I am handed were generated once, for a version the client no longer runs. Then ask who picks up the phone when something on that list turns critical, and how quickly. The lack of an answer to the second question means you were given paperwork. – Dimitar Dimitrov, Accedia
Which components depend on third parties for security patches?
Everyone asks how fast the vendor patches. Ask instead which of these components you cannot patch yourself. For the ones you own, an SLA means something. For the rest, a critical bug leaves you waiting on an upstream maintainer who owes you nothing, and no SBOM changes that. The real risk is not the list of parts. It is how many of them depend on someone you cannot compel. – Ganesh Ariyur, Transform Smarter
Can you cryptographically prove this SBOM was generated from the exact artifact we received?
A useful SBOM should be signed, reproducible and bound to a specific build, not assembled later from a spreadsheet or package list. If the vendor cannot prove provenance and integrity, every downstream vulnerability decision rests on an inventory you cannot trust. – Pawan Anand, LTM
Which components in this SBOM would trigger an identity‑verified escalation if they changed?
If the vendor can point to monitored, high‑risk dependencies, with owners, update paths and alert thresholds, then the SBOM reduces real supply‑chain risk. If they can’t, it’s just documentation. – Henry Patishman, Regula
What would make your ‘not affected’ verdict stop being true?
A vulnerable component may be unreachable only while a feature is switched off. Ask the vendor to show how enabling it triggers reassessment and an alert. Otherwise, the SBOM can remain perfectly accurate while the reassurance attached to it becomes dangerously wrong. – Abdullah Rashid, ClearTraced
What risk does this SBOM actually help us reduce?
SBOMs can quickly become static check-the-box documents: outdated, incomplete or disconnected from what’s deployed. If a critical CVE hits tomorrow, can the vendor quickly tell us what’s affected and what they’re doing about it? If not, it’s paperwork, not protection. – Vasanth Mudavatu, Dell Technologies
