Software supply chain controls support SOC 2 mostly through the criteria on vendor and business partner risk, change management, detecting new vulnerabilities and preventing malicious software. A dependency inventory, build records and vulnerability scans become evidence. SOC 2 does not name supply chain controls, so you map them.
What is SOC 2, as AICPA describes it?
AICPA describes System and Organization Controls (SOC) as a suite of service offerings CPAs may provide for system level controls at a service organization. Its stated purpose is to give users information to assess and address the risks of outsourcing services. SOC 2 reporting is described as relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy.
The criteria themselves sit in the AICPA Trust Services Criteria document, which requires a free account to download. We could not read it, so the criterion names below come from secondary summaries and need checking against the AICPA text before you cite them to an auditor.
Where do supply chain controls fit?
Vendor and business partner risk (CC9.2). The AICPA Trust Services Criteria state it as "The entity assesses and manages risks associated with vendors and business partners." Your open source packages and software suppliers are such parties in practice. Evidence includes a supplier inventory, risk tiering and review of each key supplier's assurance reports.
Change management. Build and release steps that are reviewed, logged and reproducible show that changes are controlled. Pull request approvals, signed builds and pipeline logs all count.
Vulnerability detection. Regular scanning of dependencies and containers, with a record of findings and how fast they were fixed, shows you detect and respond to new weaknesses.
Malicious software prevention. Package checks, lockfiles and allow lists for registries are controls against unauthorized code arriving through a dependency. Summaries tie this to the Common Criteria on protection of systems, but we could not confirm the exact wording.
Your auditor decides which criteria are in scope and what evidence satisfies them. Two auditors can ask for different things.
How do you build the evidence?
Keep records that show the control ran, not only that it exists. An SBOM generated at each release, scan results with dates, and tickets that show findings closed are all stronger than a policy document.
A tool such as the Safeguard CLI can build an SBOM and match components against vulnerability data, using commands like safeguard scan --dir .. That produces evidence. It does not make you SOC 2 compliant, and Safeguard does not issue or guarantee a SOC 2 report for you.
What to do
- Get the current Trust Services Criteria from AICPA and read the vendor, change and monitoring criteria.
- List every software supplier and package source you depend on.
- Tier them by how much damage a compromise would cause.
- Generate an SBOM at each release and store it with the build record.
- Scan on a schedule and on every pull request, and keep the results.
- Set a target time to fix by severity and track whether you meet it.
- Keep exceptions in a register with an owner and an expiry date.
- Walk your auditor through the mapping before the audit window opens.
What are the limits?
This is an explanation of how controls can map, not advice for a specific audit. Criteria wording, points of focus and auditor expectations change, so check current sources. We also have not seen your system description.
Quick check
Does SOC 2 require an SBOM?
Not that we could confirm. The AICPA material we could read does not mention SBOMs. An SBOM is useful evidence for vendor and vulnerability controls, but it is your choice.
Can a scanner make my company SOC 2 compliant?
No. Tools produce evidence for controls. A CPA firm performs the examination and issues the report.
Sources
- AICPA and CIMA, SOC suite of services
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022) (download requires an account, not read)
- Safeguard CLI documentation
Last reviewed: 18 October 2026.
