Software Supply Chain Security in 2026: How SBOM and Third-Party Software Vulnerabilities Are Changing Cybersecurity Compliance
Imagine your organisation has invested months in strengthening its cybersecurity controls. Security policies are documented, access permissions are reviewed, and vulnerability assessments are conducted regularly.
Then, a vulnerability is discovered in a third-party software library used by one of your business-critical applications.
Your organisation did not develop the library, and your security team may not even know that the component exists. Yet your application depends on it.
Suddenly, a software component maintained outside your organisation becomes a potential entry point into your systems, customer data, and business operations.
Click the link below: Cloud Security, What Companies need to Get Right
This is the fundamental challenge of software supply chain security: an organisation’s security depends not only on its internal controls but also on the software components, suppliers, and development processes it trusts.
Modern applications rely on open-source packages, commercial libraries, APIs, cloud platforms, development tools, and automated deployment pipelines. Each dependency introduces potential risks that must be identified, assessed, and managed.
The OWASP Foundation identifies software supply chain failures as a significant application security risk in its 2025 Top 10, highlighting concerns involving vulnerable components, compromised development processes, and software integrity.
The challenge is no longer simply identifying vulnerabilities. Organisations must also understand which applications use affected components, how quickly exposure can be identified, and whether appropriate remediation can be demonstrated.
This is where Software Bills of Materials (SBOMs) become increasingly important.
A software product is only as transparent as the dependencies your organisation can identify, assess, and monitor.
An SBOM provides an inventory of software components. When combined with vulnerability intelligence, supplier assurance, and incident response procedures, it can help organisations manage software-related risks more effectively.
However, an SBOM alone does not guarantee security. Its real value comes from how an organisation uses the information to make decisions.
Understanding Software Supply Chain Security
Software supply chain security refers to the practices used to protect software throughout its lifecycle, from the development and acquisition of individual components to application builds, distribution, deployment, and maintenance.
Unlike traditional security approaches that focus primarily on internal infrastructure, supply chain security examines the broader ecosystem responsible for creating and delivering software.
This ecosystem includes several components, each introducing different security concerns.
| Component | Potential Security Risk |
|---|---|
| Open-source libraries | Known vulnerabilities, malicious packages, or abandoned maintenance |
| Commercial software | Limited visibility into internal components or patching practices |
| APIs and integrations | Exposed credentials, excessive permissions, or insecure data exchanges |
| Source code repositories | Unauthorised modifications or compromised developer accounts |
| Build pipelines | Tampered build instructions or compromised credentials |
| Container images | Outdated packages or vulnerable operating-system components |
| Software updates | Compromised distribution channels or unverified updates |
| Third-party developers | Inadequate security practices or insufficient incident transparency |
The National Institute of Standards and Technology (NIST) addresses software supply chain security through guidance covering secure software development, supplier risk management, software verification, and vulnerability management.
Why Traditional Security Controls May Not Be Enough
An organisation can maintain strong perimeter security and still face software supply chain exposure.
Consider a company using a commercially developed customer relationship management platform. Although the platform may be legitimate and widely used, it can depend on multiple third-party libraries and services.
If one dependency becomes vulnerable, the organisation must determine whether the affected component is present in its deployed software, whether the vulnerability affects its configuration, and whether remediation is necessary.
A vendor’s reputation does not eliminate these questions.
Similarly, a supplier’s security certification does not automatically demonstrate that every software dependency is free from vulnerabilities.
Supplier assurance and software component assurance are related, but they are not interchangeable.
A mature cybersecurity programme evaluates both.
How Software Supply Chain Attacks Occur
Software supply chain attacks can target different stages of the software lifecycle.
1. Vulnerable dependencies
Developers frequently incorporate existing libraries to avoid rebuilding common functionality. A dependency may contain a vulnerability that remains undetected until a security advisory is published.
Organisations must determine whether their applications use the affected version and whether the vulnerable functionality is accessible.
2. Malicious or impersonated packages
Attackers may publish packages designed to resemble legitimate software components. If a developer or automated build process downloads a malicious package, the application may incorporate unauthorised code.
Package names, publisher identities, source repositories, signatures, and provenance therefore matter.
3. Compromised development environments
Attackers may target developer accounts, code repositories, build servers, or automated deployment credentials.
Even when the original source code is legitimate, compromising the build process can result in altered software.
4. Compromised software updates
Organisations often trust updates from established vendors. However, if an update mechanism or supplier distribution environment is compromised, a trusted channel may distribute malicious software.
5. Unmaintained software
A component may no longer receive security updates or may be maintained by a project with insufficient resources. Relying on unsupported dependencies can create long-term operational and security risks.
The OWASP Software Supply Chain Security guidance discusses threats affecting dependencies, source code, build environments, and deployment processes.
Quick Knowledge Check
Which of the following can create software supply chain risk?
- A vulnerable open-source dependency.
- A compromised software build pipeline.
- An outdated third-party library.
- A malicious package impersonating a legitimate dependency.
- An organisation’s failure to inventory the software it uses.
Answer: All five.
Supply chain risk is not limited to vulnerabilities already listed in security databases. It also includes software integrity, provenance, maintenance, and visibility concerns.
What Is a Software Bill of Materials?
A Software Bill of Materials (SBOM) is a structured record identifying the components included in a software product.
Think of it as an ingredients list for software.
Just as a food product lists its ingredients, an SBOM helps software producers, customers, and security teams understand the components that make up an application.
An SBOM can contain information such as:
- Component names and versions.
- Software suppliers and component identifiers.
- Relationships between components.
- Component hashes, where available.
- Licensing information.
- Information about the tools and processes used to generate the SBOM.
The precise contents depend on the SBOM format, the software being described, and the applicable requirements or guidance.
The Cybersecurity and Infrastructure Security Agency (CISA) provides guidance on SBOM elements, including component identification, dependency relationships, automation, coverage, distribution, and validation.
Generating an SBOM is not enough if the inventory is incomplete, outdated, or disconnected from operational security processes.
What Information Should an SBOM Contain?
| Data Element | Purpose | Security Value |
|---|---|---|
| Component name | Identifies the software component | Supports inventory completeness |
| Component version | Identifies the specific release | Helps match components to vulnerabilities |
| Supplier or producer | Establishes component origin | Supports supplier traceability |
| Unique identifiers | Improves component identification | Reduces ambiguity during assessment |
| Dependency relationships | Shows how components relate | Helps trace exposure across applications |
| Component hashes | Can support integrity verification | Helps identify unexpected changes |
| Licence information | Records applicable software licences | Supports licensing governance |
| Generation timestamp | Indicates when the SBOM was produced | Helps assess freshness |
| Generation tool | Identifies the tooling used | Supports validation and troubleshooting |
Not every field is equally applicable in every implementation. Organisations should select SBOM requirements based on their software, risk profile, customer commitments, and relevant guidance.
An Illustrative Example
Imagine that a SaaS application contains the following dependencies.
| Component | Version | Illustrative Finding |
|---|---|---|
| Web framework | 4.2.1 | No relevant vulnerability identified |
| Logging library | 2.8.0 | Security advisory requires investigation |
| Authentication package | 1.6.3 | Version is no longer maintained |
| Image-processing library | 3.1.0 | No relevant vulnerability identified |
These components and findings are fictional and are provided only to demonstrate the assessment process.
Without an inventory, the security team may need to search repositories, review developer documentation, and contact application owners to determine whether the affected library is present.
With a sufficiently complete SBOM, the team can begin with a structured list of components and investigate the affected version more efficiently.
However, a component appearing in an SBOM does not automatically mean the application is exploitable.
The security team must also consider the vulnerability’s technical conditions, the affected functionality, the deployed environment, available mitigations, and potential business impact.
An SBOM Is Not a Security Certificate
An SBOM describes software composition. It does not independently prove that:
- Every component is secure.
- The application has no exploitable vulnerabilities.
- The software was built in a trusted environment.
- The supplier follows effective security practices.
- All components are fully inventoried.
- The organisation meets every applicable compliance obligation.
An SBOM should therefore be treated as an input to a broader security programme, rather than a substitute for testing, risk assessment, or independent assurance.
An inventory tells you what is present. Risk assessment tells you what matters. Remediation determines what happens next.
This is the difference between collecting compliance documentation and using it to make security decisions.
How Exposed Is Your Software Supply Chain?
Before designing an SBOM programme, organisations should assess their current visibility into third-party software.
Use the following self-assessment to evaluate your organisation’s software supply chain security maturity.
Question 1: Do you maintain an inventory of software components across business-critical applications?
- A. Yes, with automated discovery and regular updates. 2 points
- B. Partially; inventories exist for selected applications. 1 point
- C. No consistent inventory exists. 0 points
Question 2: Can your team identify which applications use a newly reported vulnerable dependency?
- A. Yes, through an established inventory and vulnerability-matching process. 2 points
- B. We can investigate, but it requires substantial manual work. 1 point
- C. We depend on developers or vendors to investigate. 0 points
Question 3: Do you evaluate software suppliers beyond reviewing their general security statements?
- A. Yes, using risk-based due diligence and documented reviews. 2 points
- B. Only for selected suppliers or major renewals. 1 point
- C. No formal process exists. 0 points
Question 4: Are software dependencies monitored for new vulnerabilities after deployment?
- A. Yes, with defined ownership, alerting, and remediation workflows. 2 points
- B. We conduct periodic scans, but coverage is inconsistent. 1 point
- C. We primarily respond when a vendor or researcher alerts us. 0 points
Question 5: Can you demonstrate how a critical software vulnerability is assessed, escalated, and resolved?
- A. Yes, with documented decisions, evidence, and closure tracking. 2 points
- B. The process exists but is not consistently documented. 1 point
- C. The response depends on individual teams. 0 points
Interpret Your Score
| Score | Indicative Maturity | Recommended Action |
|---|---|---|
| 8–10 | More established | Validate inventory completeness, automation, and response effectiveness |
| 5–7 | Developing | Address gaps in component visibility, supplier oversight, and remediation |
| 0–4 | Early stage | Establish ownership, software inventory, and a formal risk assessment process |
This is an illustrative maturity assessment, not a validated audit instrument or formal compliance rating.
A low score does not necessarily mean an organisation has experienced a security incident. It indicates that the organisation may have difficulty demonstrating what software it uses, where exposure exists, and how effectively it responds to new risks.
A higher score also does not guarantee security. The next step is to validate the process using actual inventories, vulnerability records, supplier assessments, and incident-response evidence.
What Should Happen After the Assessment?
Organisations should translate the results into a prioritised action plan.
- Limited inventory visibility: Establish an authoritative software and dependency inventory.
- Weak vulnerability identification: Connect component information to relevant vulnerability intelligence.
- Inconsistent supplier reviews: Introduce risk-based supplier assessment criteria.
- Delayed remediation: Define severity-based response targets and escalation procedures.
- Insufficient evidence: Retain assessment records, approvals, remediation decisions, and closure evidence.
The objective is not to achieve a perfect questionnaire score. It is to establish whether the organisation can identify, evaluate, and respond to software supply chain risks in a repeatable and demonstrable way.
From SBOM to Action: The Software Security Workflow
An effective SBOM programme requires more than selecting a tool and generating a file. It should connect software inventory, vulnerability management, supplier oversight, and risk-based decision-making.
Software Supply Chain Security Flowchart
┌──────────────────────────────────┐
│ Identify Critical Applications │
│ and Software Suppliers │
└────────────────┬─────────────────┘
↓
┌──────────────────────────────────┐
│ Generate or Obtain SBOMs │
│ for Relevant Software │
└────────────────┬─────────────────┘
↓
┌──────────────────────────────────┐
│ Validate SBOM Quality, Coverage │
│ and Freshness │
└────────────────┬─────────────────┘
↓
┌──────────────────────────────────┐
│ Match Components Against │
│ Relevant Vulnerability Data │
└────────────────┬─────────────────┘
↓
┌──────────────────────────────────┐
│ Assess Exploitability and │
│ Business Impact │
└────────────────┬─────────────────┘
↓
┌─────────────────────┐
│ Is the Risk │
│ Acceptable? │
└─────────┬───────────┘
↓
┌────────┴────────┐
↓ ↓
YES NO
↓ ↓
┌────────────────┐ ┌───────────────────┐
│ Document the │ │ Patch, Upgrade, │
│ Decision and │ │ Mitigate, Isolate │
│ Monitor Risk │ │ or Replace │
└───────┬────────┘ └─────────┬─────────┘
└──────────┬─────────┘
↓
┌──────────────────────────────────┐
│ Verify Remediation and Update │
│ Evidence and Risk Assessments │
└────────────────┬─────────────────┘
↓
┌──────────────────────────────────┐
│ Continuous Monitoring and │
│ Periodic Supplier Review │
└──────────────────────────────────┘This flowchart illustrates a recommended operational workflow, not a mandatory sequence prescribed identically by every standard or regulation.
Step 1: Identify Critical Applications
Begin by identifying applications that support essential business processes or handle sensitive information.
Examples include customer-facing SaaS platforms, payment systems, identity and access management systems, healthcare applications, and business-critical internal software.
Prioritisation should consider business criticality, data sensitivity, external exposure, supplier dependence, and the consequences of disruption.
Step 2: Generate or Obtain SBOMs
For internally developed software, teams can integrate SBOM generation into the software development lifecycle.
For commercial software, organisations can request SBOMs or equivalent component information from suppliers where appropriate.
The approach will vary depending on whether the software is internally developed, purchased, delivered as SaaS, or distributed as a packaged product.
For SaaS environments, visibility may depend on supplier disclosures, contractual arrangements, technical integrations, and the information the provider can reasonably supply.
Step 3: Validate the Information
An SBOM is useful only to the extent that it accurately represents the relevant software.
Teams should evaluate:
- Whether important components are missing.
- Whether versions and identifiers are sufficiently precise.
- Whether dependency relationships are represented.
- When the SBOM was generated.
- Whether it corresponds to the software release being assessed.
- Whether subsequent application updates are reflected in new SBOMs.
An outdated SBOM may not represent the current production environment.
Step 4: Correlate Components With Vulnerability Intelligence
The organisation should establish a process for identifying relevant security advisories and matching them against its component inventory.
The presence of a vulnerability should trigger investigation, not automatic assumptions about exploitability.
Security teams should assess the affected version, configuration, exposure, available mitigations, and potential consequences.
Step 5: Make Risk-Based Remediation Decisions
Depending on the findings, the organisation may need to:
- Upgrade the affected component.
- Apply a vendor-provided patch.
- Disable vulnerable functionality.
- Restrict network or application access.
- Replace an unsupported dependency.
- Introduce temporary compensating controls.
- Document and approve a time-bound exception where remediation is not immediately feasible.
Decisions should reflect both technical evidence and business risk.
Step 6: Verify and Retain Evidence
After remediation, the organisation should verify that the corrective action was effective.
Relevant evidence may include updated SBOMs, vulnerability scan results, change records, test results, risk acceptance approvals, and closure records.
NIST’s Secure Software Development Framework provides a useful reference for integrating secure development, software integrity, vulnerability response, and related practices into software lifecycles.
How Software Supply Chain Security Connects to Compliance
Software supply chain security is not a single certification requirement that applies identically to every organisation.
Instead, it intersects with broader security governance, risk management, supplier oversight, vulnerability management, and secure development practices.
The precise obligations depend on the organisation’s industry, jurisdiction, contracts, technology environment, and applicable framework.
NIST Secure Software Development Framework
NIST SP 800-218, the Secure Software Development Framework (SSDF), describes practices intended to reduce software vulnerabilities and mitigate the impact of vulnerabilities that remain undetected or unresolved.
Its recommendations cover secure development practices and provide a common vocabulary that software producers and purchasers can use when discussing software security.
For organisations developing software, the framework can help structure discussions around:
- Protecting source code from unauthorised access and modification.
- Verifying software release integrity.
- Managing software components and their provenance.
- Identifying and remediating vulnerabilities.
- Improving the security of development processes.
Practical takeaway: Software security should be embedded into the development lifecycle rather than addressed only after deployment.
Cybersecurity Supply Chain Risk Management
NIST’s supply chain guidance addresses cybersecurity risks associated with acquired products, services, suppliers, and related technology dependencies.
For compliance teams, this highlights the importance of understanding not only what a supplier promises but also how supplier-related risks are assessed and monitored.
Relevant evidence may include supplier security assessments, software inventories, contractual security requirements, vulnerability management procedures, supplier incident notification arrangements, documented risk treatment decisions, and periodic supplier reviews.
OWASP Software Supply Chain Security
OWASP provides practical guidance for understanding threats affecting software dependencies, source code, build environments, and deployment processes.
Organisations can use this guidance to inform technical reviews and strengthen controls across the software lifecycle.
For example, a supplier review should not focus exclusively on whether the supplier has a security policy. It may also examine how software packages are obtained, how release integrity is protected, and how security issues are communicated to customers.
SBOM Guidance
CISA’s SBOM guidance addresses the information and processes that help organisations understand software composition.
Organisations should evaluate this guidance against their operational requirements rather than assuming every recommendation constitutes a universal legal obligation.
What Should Auditors and Compliance Teams Look For?
A software supply chain review should examine both documented processes and evidence of their operation.
| Assessment Area | Questions to Ask | Example Evidence |
|---|---|---|
| Software inventory | Is critical software identified and accounted for? | Asset inventories and application registers |
| Component visibility | Can the organisation identify important dependencies? | SBOMs and dependency inventories |
| Vulnerability management | Are affected components investigated and prioritised? | Scan reports, advisories, and triage records |
| Remediation | Are identified risks resolved or formally treated? | Patch records, tickets, and risk exceptions |
| Supplier oversight | Are suppliers assessed according to risk? | Supplier assessments and review records |
| Change management | Are software changes reviewed and authorised? | Change requests and release approvals |
| Software integrity | Are software artefacts and updates verified appropriately? | Signing and verification records |
| Incident response | Can affected applications and suppliers be identified during an incident? | Response procedures and exercise records |
| Governance | Are responsibilities and escalation routes defined? | Policies, roles, and management approvals |
These are suggested assessment areas, not a universal mandatory audit checklist. Applicable requirements should be mapped to the organisation’s chosen framework and scope.
Policy Versus Evidence
A policy might state that critical vulnerabilities must be addressed promptly.
An auditor or customer may reasonably ask how that requirement operates in practice.
Can the organisation demonstrate when a vulnerability was detected, who assessed it, how severity was determined, what action was taken, and how closure was verified?
The ability to answer these questions provides a clearer picture of control effectiveness than the existence of a policy alone.
Compliance becomes more meaningful when an organisation can demonstrate not only what its procedures require, but also how those procedures work in practice.
Real-World Scenarios: When Software Dependencies Become a Business Risk
Scenario 1: A Vulnerable Dependency Is Discovered
Consider a fictional SaaS provider that offers an online document-processing platform.
The company maintains a formal security programme and regularly scans its application.
A new security advisory identifies a vulnerability affecting a particular version of a third-party library.
The security team must determine whether the affected version appears in the production application, whether the vulnerable functionality is enabled, and whether an attacker could reach the affected component.
It must also establish which customers or environments may be exposed and what corrective action is appropriate.
Without effective component visibility
The organisation may need to contact several developers, inspect repositories, review historical releases, and reconstruct which versions are deployed.
This can delay assessment and increase uncertainty during a time-sensitive investigation.
With an effective SBOM process
The team can begin by identifying applications that contain the affected component and version.
It can then investigate the vulnerability’s technical conditions, determine which environments are affected, prioritise remediation, and document the outcome.
An SBOM does not resolve the vulnerability by itself. It can, however, improve the starting point for investigation and help the organisation make a more informed response.
Scenario 2: A Supplier Cannot Provide an SBOM
Imagine that an enterprise purchases a business-critical application from a software vendor.
During a supplier review, the customer requests an SBOM. The vendor responds that it does not provide one.
Should the customer immediately reject the supplier?
Not necessarily.
The appropriate response depends on the software’s criticality, the customer’s requirements, the vendor’s capabilities, and the availability of alternative assurance measures.
The customer could:
- Determine whether the application handles sensitive or regulated information.
- Assess the business impact of a software supply chain incident.
- Request alternative component or vulnerability information.
- Review the vendor’s vulnerability management and incident notification processes.
- Establish contractual expectations where appropriate.
- Document residual risk and identify compensating measures.
- Reassess the supplier periodically.
For certain high-risk systems, limited software transparency may be unacceptable. In other situations, a documented, risk-based approach may be more appropriate than a blanket prohibition.
The objective is to make an informed decision rather than treat the presence or absence of a single document as a complete measure of security.
Five Common SBOM Implementation Mistakes
1. Generating an SBOM once and never updating it
Software changes over time. New releases, dependency upgrades, and configuration changes can make older inventories incomplete or inaccurate.
Better approach: Establish a process for regenerating or updating SBOMs as appropriate to the software lifecycle.
2. Treating every vulnerability as equally urgent
The presence of a known vulnerability does not automatically establish that every affected application is equally exposed.
Better approach: Consider technical severity, exploitability, exposure, business criticality, and available mitigations.
3. Ignoring transitive dependencies
A direct dependency may rely on other components that the development team did not select individually. These indirect dependencies can also introduce security and maintenance risks.
Better approach: Evaluate direct and transitive dependencies to the extent supported by the available tooling and inventory.
4. Relying entirely on supplier assurances
A supplier’s statement that its software is secure does not eliminate the customer’s responsibility to evaluate its own risk.
Better approach: Combine supplier assurance with appropriate technical assessment, contractual controls, and ongoing monitoring.
5. Collecting SBOMs without assigning ownership
An inventory that no one reviews or acts upon may provide little operational value.
Better approach: Define who maintains the inventory, who investigates findings, who approves exceptions, and who verifies remediation.
Interactive Decision Tree: What Should Your Organisation Do Next?
Use this decision tree to identify the most appropriate starting point.
Question 1: Can you identify the components in your critical applications?
- No: Begin with software inventory and component discovery.
- Partially: Prioritise gaps in business-critical applications and third-party dependencies.
- Yes: Continue to Question 2.
Question 2: Can you identify which applications are affected by a newly disclosed vulnerability?
- No: Improve SBOM quality and connect component inventories to vulnerability intelligence.
- Partially: Review automation, inventory coverage, and version accuracy.
- Yes: Continue to Question 3.
Question 3: Do you have a documented process for prioritising and remediating findings?
- No: Define ownership, escalation routes, remediation targets, and risk acceptance procedures.
- Partially: Standardise the process across relevant teams.
- Yes: Continue to Question 4.
Question 4: Can you demonstrate that remediation was effective?
- No: Introduce verification and evidence-retention procedures.
- Yes: Focus on continuous improvement, supplier risk, and resilience testing.
Your next step should address the weakest part of the process.
An organisation with no inventory should not begin by purchasing an advanced vulnerability analytics platform. An organisation with mature inventories but weak remediation should focus on response ownership and operational execution.
The most effective investment is the one that closes a demonstrable risk-management gap.
The 30-Day Software Supply Chain Security Action Plan
Organisations do not need to transform every part of their software lifecycle simultaneously. A phased approach can help teams establish visibility, prioritise risk, and build a foundation for continuous improvement.
The following is an illustrative 30-day starting plan. The actual timeline will depend on the size and complexity of the environment.
Week 1: Establish Visibility
- Identify business-critical applications.
- Document software owners and responsible teams.
- Identify major software suppliers and hosting arrangements.
- Review existing software inventories and dependency information.
- Determine which applications have the greatest potential business impact.
Expected outcome: An initial list of priority applications and their owners.
Week 2: Assess Component Transparency
- Determine which internally developed applications can produce SBOMs.
- Request relevant software composition information from critical suppliers.
- Evaluate the quality and freshness of existing SBOMs.
- Identify unsupported or poorly maintained dependencies.
- Document important inventory gaps.
Expected outcome: An initial assessment of software component visibility.
Week 3: Connect Inventory to Risk Management
- Establish a process for reviewing relevant vulnerability advisories.
- Identify how affected applications will be located.
- Define risk-based prioritisation criteria.
- Assign responsibility for remediation.
- Establish a process for documenting and approving exceptions.
Expected outcome: A documented workflow for identifying, assessing, and treating software component risks.
Week 4: Test the Process
- Select a sample application and test the workflow.
- Simulate the discovery of a vulnerable dependency.
- Measure how quickly the team can identify affected systems.
- Check whether decisions and remediation activities are documented.
- Record gaps and assign corrective actions.
Expected outcome: A tested initial process and a prioritised improvement plan.
Software Supply Chain Security Checklist
Use this checklist during internal reviews or supplier discussions.
| Control Activity | Status |
|---|---|
| Critical applications identified | ☐ Not started ☐ In progress ☐ Complete |
| Software ownership documented | ☐ Not started ☐ In progress ☐ Complete |
| SBOM generation or collection process established | ☐ Not started ☐ In progress ☐ Complete |
| Component inventory quality reviewed | ☐ Not started ☐ In progress ☐ Complete |
| Vulnerability matching process established | ☐ Not started ☐ In progress ☐ Complete |
| Supplier software security risks assessed | ☐ Not started ☐ In progress ☐ Complete |
| Remediation responsibilities assigned | ☐ Not started ☐ In progress ☐ Complete |
| Risk acceptance and exception procedures documented | ☐ Not started ☐ In progress ☐ Complete |
| Remediation verification process established | ☐ Not started ☐ In progress ☐ Complete |
| Process effectiveness tested | ☐ Not started ☐ In progress ☐ Complete |
This checklist is a practical planning aid, not a formal certification checklist.
What Comes Next for Software Supply Chain Security?
Software supply chain security is evolving alongside changes in application architecture, cloud adoption, development automation, and artificial intelligence.
Three developments deserve particular attention.
Greater Emphasis on Software Transparency
Organisations increasingly need usable information about the components included in the software they acquire, develop, and deploy.
An SBOM can support this visibility, provided that it is sufficiently complete, accurate, and current.
The next challenge is integrating that information into everyday vulnerability management and supplier risk decisions.
Security Throughout the Development Lifecycle
Security cannot depend entirely on reviews conducted before deployment.
Development teams need repeatable processes for protecting source code, verifying software releases, managing dependencies, and responding to newly discovered vulnerabilities.
NIST’s Secure Software Development Framework offers a structured reference for incorporating security practices into software development and maintenance.
Visibility Into AI Software Components
AI-enabled applications introduce additional questions about the software and components on which they depend.
These may include conventional software libraries, model-serving frameworks, supporting packages, and other elements of the AI application stack.
CISA and G7 partners have also published guidance on minimum elements for an SBOM for AI, intended to complement general SBOM guidance and improve transparency in AI systems and their supply chains.
Organisations should evaluate how these developments affect their software inventories, supplier assessments, and security processes.
The specific controls required will depend on the system, its use, and the organisation’s risk profile.
Frequently Asked Questions
1. Is an SBOM mandatory for every organisation?
No single universal requirement makes SBOMs mandatory for every organisation in every jurisdiction. Requirements may arise from particular regulations, procurement rules, contractual commitments, or sector-specific obligations. Organisations should determine which requirements apply to their circumstances.
2. Does an SBOM prove that software is secure?
No. An SBOM describes software components and their relationships. It does not independently prove that software is free from vulnerabilities, that its build process is trustworthy, or that the organisation meets every applicable security requirement.
3. What is the difference between an SBOM and a vulnerability scan?
An SBOM records information about software composition. A vulnerability scan or related analysis evaluates software or systems for known weaknesses. The two can complement each other when component information is correlated with relevant vulnerability intelligence.
4. Can an organisation create an SBOM for third-party software?
Depending on the software, available tooling, and applicable restrictions, an organisation may be able to generate component information from software artefacts. It can also request an SBOM from the supplier. The organisation should assess the resulting inventory’s completeness and reliability.
5. How often should an SBOM be updated?
The appropriate frequency depends on the software’s release cycle, risk profile, and applicable requirements. Organisations should establish a process that keeps component information sufficiently current for its intended security and risk-management purposes.
6. How does SBOM management support cybersecurity compliance?
SBOMs can support software inventory, vulnerability management, supplier risk assessment, incident response, and audit evidence. Their value depends on how effectively the organisation integrates them into its broader security governance processes.
Conclusion: Software Transparency Is the Beginning, Not the Finish Line
Modern software depends on an interconnected ecosystem of components, suppliers, development environments, and distribution channels.
That ecosystem creates opportunities for innovation, but it also introduces risks that individual organisations cannot manage through perimeter security alone.
Software Bills of Materials can help improve visibility into application dependencies. When combined with supplier oversight, vulnerability intelligence, secure development practices, and documented remediation processes, they provide a stronger foundation for managing software supply chain risks.
The real objective is not simply to produce an inventory.
It is to ensure that when a software component becomes vulnerable or untrustworthy, the organisation can determine where it is used, evaluate the consequences, take appropriate action, and demonstrate that the risk has been addressed.
Software transparency makes risk visible. Effective governance turns that visibility into action.
As software ecosystems continue to evolve, organisations that establish these capabilities will be better positioned to make informed technology decisions, respond to emerging threats, and demonstrate the effectiveness of their cybersecurity practices.
References and Further Reading
- CISA: Minimum Elements for a Software Bill of Materials (SBOM).
- NIST: Secure Software Development Framework (SP 800-218).
- NIST: Software Supply Chain Security Guidance.
- OWASP: Software Supply Chain Security Cheat Sheet.
- OWASP: Top 10:2025 — Software Supply Chain Failures.
- CISA and G7 Partners: Software Bill of Materials for AI.
This article is intended for general cybersecurity education and risk-management awareness. It does not constitute legal advice, a formal audit opinion, or a guarantee of compliance with any specific framework.
