What Is Inside Your AI System? New SBOM Guidance Raises the Bar for Supplier Assurance

Key takeaways

New international cyber-security guidance co-authored by New Zealand’s National Cyber Security Centre treats artificial intelligence systems and software-as-a-service as part of the software supply chain.
Organisations are encouraged to request, generate and analyse updated software bills of materials rather than relying only on vendor assurances.
Professional services firms should strengthen AI procurement, supplier due diligence, vulnerability management and incident-response planning.

An AI tool may appear to be a single product. In reality, it can depend on software libraries, cloud services, model providers, application programming interfaces, plugins and other third-party components.

That chain matters when a vulnerability is discovered. A firm cannot assess its exposure quickly if it does not know which components sit inside systems handling client information or supporting professional work.

On 31 July 2026, New Zealand’s National Cyber Security Centre published updated international guidance on the minimum elements of a software bill of materials, or SBOM. The document was led by the United States Cybersecurity and Infrastructure Security Agency and co-authored by cyber-security organisations from New Zealand, Australia, Canada, Europe and Asia. It expressly covers AI software and SaaS alongside traditional software and firmware.

The guidance is not a new law. It is, however, a useful signal about the evidence organisations may increasingly be expected to obtain from technology suppliers.

An ingredients list for software

An SBOM is an ingredients list for software. It records the components and dependencies that make up an application or system, including their producers, versions and relationships.

When a security advisory identifies a vulnerable component, an organisation with reliable, machine-readable SBOM data can determine where that component is present. Without that visibility, it may need to contact individual suppliers or wait for vendors to confirm whether it is affected.

The guidance applies to organisations that produce, procure or operate software. Firms buying client portals, document-management platforms, AI assistants or workflow automation therefore sit on the demand side of the software supply chain.

AI and SaaS are explicitly within scope

The guidance states that its minimum elements apply to all software, including open-source software, AI software and SaaS.

That matters because most firms experience AI as a cloud service. They do not install the model, inspect its code or control the supplier’s update cycle. A tool can change behind the scenes while presenting the same interface to users.

The guidance acknowledges that SaaS complicates SBOM practice because cloud systems change rapidly and responsibility is shared between producers and operators. It nevertheless says SaaS retains the usual transparency benefits of an SBOM.

AI systems add another layer. Traditional component information may not explain which model is used, where relevant data came from or how the model behaves. The guidance notes that model cards and data cards may provide useful additional information, while stopping short of creating extra AI-specific minimum elements.

An SBOM is therefore a foundation for AI assurance, not the complete answer.

What changed in the 2026 minimum elements

The update adds information intended to make SBOMs more current, trustworthy and useful.

New elements include the SBOM author’s digital signature, the data format and version, the context in which the SBOM was generated, the tool used, the SBOM’s own version, component hash information and component licences.

The guidance also strengthens expectations around coverage. An SBOM should include all components making up the target software, including indirect dependencies. Unknown or withheld information should be identified explicitly, and each software version or update should have an associated SBOM.

These details matter during an incident. A component name without a version may not reveal whether a vulnerable release is present, while an old SBOM may no longer describe the live system.

Why professional services firms should care

Professional services organisations hold confidential and sometimes legally privileged information. Yet a firm may approve an AI product after reviewing its privacy statement and contractual terms while knowing little about its underlying components. That gap can slow decisions when a vulnerability or supplier incident emerges.

SBOM information can help procurement teams assess supplier practices, cyber-security teams map vulnerabilities against dependencies, legal and risk teams test notification obligations, and incident responders identify affected systems faster.

New Zealand’s NCSC already recommends that organisations using commercial AI and cloud services examine supplier security practices, privacy and security documentation, data-sovereignty statements and information about third-party models. For open-source software and dependencies, it recommends using SBOMs or other tools to identify affected components and vulnerabilities.

A proportionate approach remains important. A system processing client files, integrating with email or operating with broad permissions deserves more scrutiny than a tool used only with public information.

What this means for your organisation

Professional services firms should take six practical steps.

Map critical AI and SaaS dependencies. Start with systems handling client information or privileged access. Record the supplier, integrations, model provider where known, data locations and business owner.
Add SBOM questions to supplier due diligence. Ask whether the supplier can provide an SBOM, which format it uses, how often it is updated, how deeply dependencies are covered and how unknown information is recorded.
Request AI-specific assurance as well. An SBOM will not usually answer questions about model behaviour, training data, privacy or human oversight. Request model cards, data cards and information about third-party models where relevant.
Strengthen contracts and procurement standards. For higher-risk systems, consider requirements for vulnerability notification, timely remediation, updated component information, subcontractor transparency and secure exit arrangements.
Connect inventories to vulnerability management. Decide who receives security advisories, who checks affected components, how suppliers are contacted and how urgent decisions are escalated.
Test the process through an incident exercise. Simulate a serious vulnerability in a critical AI or SaaS dependency. Test whether the firm can identify its exposure, obtain reliable information and make a timely continue-or-disable decision.

From product approval to supply-chain assurance

Approving an AI tool by name is no longer enough. Organisations need visibility into the changing technology chain behind it.

The guidance does not make SBOMs mandatory for every New Zealand business. Its multinational backing, including participation by New Zealand’s NCSC, nevertheless makes it a credible benchmark for secure procurement and supplier assurance.

The starting point is asking a better question before sensitive work depends on a system: if something inside this product becomes unsafe tomorrow, will we know whether we are affected?

Source note

This article is based primarily on the New Zealand National Cyber Security Centre’s 2026 Minimum Elements for a Software Bill of Materials, published on 31 July 2026, and the underlying joint guidance dated 29 July 2026.

Supporting New Zealand context was drawn from the NCSC’s guidance on managing vulnerabilities and AI supply-chain risk.

General information disclaimer

This article provides general information and commentary only. It is not legal, cyber-security or other professional advice. Organisations should obtain advice appropriate to their systems, contracts, risk profile and regulatory obligations.

Sources

Frontier AI: Managing the increasing risks from vulnerabilities