---
key: "supplier-assurance"
title: "Supplier software assurance: check SOC 2 reports, SBOMs and signed updates against your use"
url: "https://softwaresecurity.com/frameworks/supplier-software-assurance/"
api: "https://softwaresecurity.com/api/v1/articles/supplier-assurance.json"
domain: "governance"
topic: "Governance \u0026 frameworks"
type: "Guide"
identifiers: ["A03:2025"]
tags: ["SBOM","Compliance and assurance evidence","Supplier and open source risk"]
stages: ["release","govern"]
roles: ["appsec-engineer","platform-sre","security-leader"]
license: "CC-BY-4.0"
license_url: "https://creativecommons.org/licenses/by/4.0/"
code_license: "MIT"
---

# Supplier software assurance: check SOC 2 reports, SBOMs and signed updates against your use

Connect supplier claims to product scope, supported versions, release integrity and vulnerability handling before making a procurement decision.

Canonical URL: https://softwaresecurity.com/frameworks/supplier-software-assurance/

## In short

Start from the access you will grant: data, privileges, network reach and update channel. Then ask what each document actually covers. A SOC 2 report covers its named system and period; an SBOM lists components but does not authenticate updates; a signature helps only when you verify the signer and the digest you deploy. Turn every gap into a purchasing condition you can test, limit the deployment until it passes, and reassess when the supplier, product or access changes.

- A SOC 2 Type 2 report covers a named system, criteria and period, with exceptions and customer responsibilities. Read all four before relying on it.
- An SBOM inventories components; it says nothing about whether the update channel is authenticated.
- A signature helps only if you check the expected signer and compare the signed digest with what you install.
- Since OMB M-26-05 (January 2026), US agencies set their own software assurance terms; the CISA attestation form and SBOM requests are optional tools.
- CISA’s 2026 Minimum Elements for an SBOM (July 2026) replace the 2021 NTIA list and give a concrete baseline to request.

## Verify it

1. Read the SOC report’s system description and confirm the purchased product is in scope for the period you rely on.
2. Verify a downloaded update’s signature against the expected identity and compare its digest with the approved one.
3. Install a deliberately tampered update in a test environment and confirm it is rejected.
4. Check the SBOM for the delivered version against CISA’s 2026 minimum elements, for example with /tools/sbom-checker/.
5. Confirm each purchasing condition has an owner and a test, and the contract covers exit, token revocation and deletion.

## What you will learn

- Match assurance evidence to the actual purchased service and privileges.
- Distinguish SOC report scope from artifact and updater verification.
- Convert evidence gaps into owned purchasing conditions.

Audience: Platform engineers, procurement and security reviewers assessing software from suppliers

Before you start:

- Identify the acquired service or artifact, intended use, data access and release identity.

Time: About 29 minutes: 6 to read and 23 for the exercise

## What access will the supplier's software get?

Supplier assurance starts with the proposed use, not the supplier's badge collection. A hosted analytics tool receiving anonymized totals poses different questions from an agent running as administrator on production hosts. Describe data, privileges, network access, deployment model, dependency on the supplier, update channel, retention and exit needs. Identify which legal entity and product are being assessed. A strong assessment of a different service does not automatically cover the one being purchased.

The fictional buyer is considering Northstar Support Cloud plus its optional endpoint agent. The hosted service receives support records, while the agent requests administrator privileges and auto-updates from a supplier channel. Those are two linked but distinct scopes. Procurement owner Asha coordinates the decision, platform engineer Bo assesses the agent, privacy reviewer Cleo assesses data use, and business owner Dax accepts bounded residual risk. None of these fictional assignments implies a real approval. The aim is to turn evidence gaps into conditions that the buyer can actually test.

## What does each supplier document establish, and what doesn't it?

AICPA's SOC services provide assurance reports about defined systems and controls. Read the actual system description, report period, opinion, exceptions, subservice treatment and customer responsibilities. A Type 1 report addresses design at a point in time; Type 2 also examines operating effectiveness over a period. Neither is a guarantee that every product release is safe. A management bridge letter may discuss subsequent changes, but it is not a fresh independent examination of the entire gap period.

NIST's supply-chain guidance supports assessing evidence throughout acquisition and operation. In the fixture, the supplier report explicitly excludes the endpoint agent. Its SBOM inventories agent components but says nothing by itself about authentication of updates. Its installer carries a valid signature, but a valid signature only matters if the signing identity is the supplier's release process; a signature from the wrong identity proves nothing about the update channel. These documents can support different pieces of the argument; none fills the others' gaps through association. Asking for a second badge would be less useful than obtaining the specific missing update verification evidence.

## What should you ask a supplier for?

Ask for evidence that answers the questions your use raises, and treat questionnaire answers, such as a Shared Assessments SIG or a Cloud Security Alliance CAIQ, as claims to check against it. US federal buyers have more latitude since OMB M-26-05 rescinded the mandatory self-attestation in January 2026: agencies may still use the CISA attestation form and contract for an SBOM on request, but the assurance terms are now theirs to set. Customers subject to NIS2 or DORA have their own lists, covered in /frameworks/nis2-dora-for-software-suppliers/.

- Scope: the legal entity, product, versions and deployment model the evidence covers, and anything excluded.
- Assurance report: the latest SOC 2 Type 2 report or ISO/IEC 27001 certificate with its scope, period, exceptions and complementary user-entity controls.
- SBOM: one per delivered version, in CycloneDX or SPDX, meeting CISA’s 2026 minimum elements, including component hashes.
- Vulnerability status: VEX statements, in CSAF, OpenVEX or CycloneDX form, saying which known vulnerabilities affect the product, and a contact for reporting new ones.
- Update integrity: the signing identity, how customers verify updates, and a demonstration that a tampered update is rejected.
- Secure development: SSDF-aligned evidence, or the CISA attestation form where the buyer chooses to use it.

## How do you make a purchasing condition testable?

A useful condition states what must be true before access is granted and what evidence demonstrates it. For a privileged agent, require an authorized update identity, immutable release binding, restricted deployment scope, rollback/recovery behavior and a demonstrated test of rejected tampering. For the hosted service, connect retention, access and data export promises to the actual contract and configuration. Avoid promises such as enterprise-grade security that have no objective acceptance event.

The exercise's policy allows a hosted pilot with synthetic records but forbids production administrator deployment until update authentication is verified. That is a scope reduction with operational consequences: support automation remains manual on production hosts. The buyer can accept that cost while the supplier supplies evidence, or choose a different product. An exception should name the privilege and data it accepts, a time limit and an accountable owner; it must not be hidden inside an overall approved-supplier status. Evaluate the combined system because the hosted console may control the agent's commands.

## How do you verify a supplier's update before it installs?

Turn the update condition into a gate in your deployment tooling. The script accepts a file only if its SHA-256 digest equals the one in your approved purchasing record and its Sigstore bundle verifies with cosign against the supplier's published release identity and OIDC issuer. Get the expected identity from the supplier's documentation or contract, not from the certificate you are checking, and test the gate with a tampered file before you rely on it. /domains/supply-chain/provenance/artifact-signature-policy/ covers signer policies in more depth.

```bash
#!/usr/bin/env bash
# Accept a supplier update only if it is the approved file and was signed by the expected identity.
# Usage: verify-supplier-update.sh agent-4.1.0.pkg
set -euo pipefail

file="$1"
# From the approved purchasing record, not from the supplier's download page.
approved_sha256="5d0a3c8f6b1e4f2a9c7d8e0b3a6f1c4d7e9b2a5c8f0d3e6a9b1c4f7e0a2d5b8c"
expected_identity="https://github.com/northstar-example/agent/.github/workflows/release.yml@refs/tags/v4.1.0"
expected_issuer="https://token.actions.githubusercontent.com"

actual_sha256="$(sha256sum "$file" | cut -d' ' -f1)"
if [ "$actual_sha256" != "$approved_sha256" ]; then
  echo "REJECT: $file is $actual_sha256, approved digest is $approved_sha256" >&2
  exit 1
fi

# A valid signature is not enough: it must come from the supplier's release workflow.
cosign verify-blob "$file" \
  --bundle "$file.sigstore.json" \
  --certificate-identity "$expected_identity" \
  --certificate-oidc-issuer "$expected_issuer"

echo "ACCEPT: $file matches the approved digest and the supplier's release identity"
```

## How do you keep supplier access conditional after the contract?

Supplier risk changes after purchase. New subprocessors, acquisitions, modified update keys, report exceptions, incident history and product architecture can invalidate earlier evidence. Connect reassessment to those events and to the period covered by assurance documents. A supplier who passes intake but never receives another review may accumulate access beyond the original decision. Maintain owners for updates, access reviews, incident contacts and termination.

Exit tests matter because an unusable export or unrevoked integration can extend dependence and exposure. The buyer should know how to remove the agent, revoke tokens, export required records and confirm deletion according to applicable commitments. These are specific technical/contractual questions, not proof of legal compliance. The complete fixture below lets you assess document scope, reject an unsupported privileged deployment and draft precise evidence requests without contacting the supplier or pretending an assessor has approved the product.

## Guided practice

Assess Northstar's hosted service and optional privileged agent for a fictional buyer.

### Supplied material

```text
Use H: hosted support pilot, synthetic tickets only, 10 users, no production integration.
Use A: endpoint agent 4.1 requests administrator rights, installs on production hosts and auto-updates nightly from a supplier URL.
E1 SOC 2 Type 2 report: hosted Support Cloud only, 1 January to 30 June 2026; endpoint agent explicitly excluded;
   one exception in quarterly access reviews; complementary user entity control: customers enforce SSO and MFA.
E2 Bridge letter: management reports no material changes to the hosted system through 30 September 2026.
E3 Agent SBOM (CycloneDX) for 4.1: component names and versions; no component hashes and no suppliers.
E4 Installer agent-4.1.0.pkg with a Sigstore bundle: the signature verifies and the digest matches the SBOM's root component,
   but the certificate identity is a nightly test workflow:
   https://github.com/northstar-example/agent-ci-tests/.github/workflows/nightly.yml@refs/heads/main
Northstar's security page names its release workflow: .github/workflows/release.yml in northstar-example/agent, on version tags.
Local rule: synthetic hosted pilot allowed after access setup; the production admin agent requires a verified release identity,
   an approved digest and a tampered-update rejection test.
Roles: Asha procurement; Bo platform; Cleo privacy; Dax business acceptance. No approvals supplied.
```

### 1. Separate the scopes

Create distinct use decisions and identify their main consequence.

Worked answer: H concerns hosted access with synthetic data. A concerns administrator execution and supplier-controlled updates on production hosts. E1 covers H's system and explicitly excludes A, so A needs its own evidence.

### 2. Read the report properly

Say what E1 and E2 establish for H and what the buyer must do.

Worked answer: E1 is independent assurance about the hosted system for January to June 2026; E2 is management's statement about the months since, not a new examination. Read the access-review exception and Northstar's response. The complementary user entity control means the buyer must enforce SSO and MFA for its own users, or the report's conclusions don't carry over to this use.

### 3. Check the SBOM

Judge E3 against CISA's 2026 minimum elements.

Worked answer: The 2026 minimum elements expect, for each component, its producer and a hash, among other fields; without them the SBOM can't be matched reliably to advisories or to the delivered files. Ask for a corrected SBOM. Even a complete SBOM only inventories components; it doesn't authenticate the updater.

### 4. Verify the signer, not just the signature

Decide whether E4 meets the update condition.

Worked answer: No. The signature is valid and the digest matches, but the identity is a nightly test workflow on a branch, not the release workflow on a version tag that Northstar publishes. A valid signature from the wrong identity is a rejection: pin the expected identity and issuer, as the verification script does, and ask Northstar why a test workflow signs installers.

### 5. Write conditions and owners

Decide what is permitted now and who follows up.

Worked answer: Allow the H pilot once SSO and MFA are enforced; hold A. Bo requires release-identity verification, an approved digest and a tampered-update test rejected before install; Asha obtains a corrected SBOM and the next SOC 2 report; Cleo reviews any move from synthetic to personal data; Dax decides on any time-limited exception. Reopen on new agent privileges, a changed signing identity or report exceptions that affect the use.

Deliverable: Two scoped supplier decisions, a list of evidence requests and an update verification rule for the agent.

Scope: The supplier, report and signing identities are fictional.

Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security.

## Sources

- [NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final). May 2022, with updates as of 1 November 2024.
- [AICPA: System and Organization Controls (SOC) suite of services](https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services)
- [OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security (23 January 2026)](https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf)
- [CISA: 2026 Minimum Elements for a Software Bill of Materials (July 2026)](https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom)
- [SLSA 1.2 specification](https://slsa.dev/spec/v1.2/). Version 1.2.
- [CycloneDX specification overview, version 1.7](https://cyclonedx.org/specification/overview/). Version 1.7.
- [Sigstore: verifying signatures with cosign (verify-blob with a bundle)](https://docs.sigstore.dev/cosign/verifying/verify/)