Does SOC 2 cover software supply chain security?

Partly. The change management, vulnerability management and logical access criteria cover reviewed changes, timely fixes and access to source code and pipelines. SOC 2 does not ask for specific practices such as build provenance or signed artifacts. If customers ask for those, frameworks like SLSA and the NIST SSDF describe them.

We are an open source company. What does SOC 2 examine?

SOC 2 examines a system you operate, such as a hosted version of your product, and the company controls around it. The open source project as such is not examined, but the code you ship into the hosted service goes through your change management and secure development controls.

How should we handle customer API keys?

With API selected as the application type, the policies state that customer API keys are random, shown once at creation, stored only as a salted hash, scoped to minimum permissions and revocable at any time. Check that your product does this before you adopt the wording.

Do we need Availability if we sell an API?

Not necessarily. Add it if customers depend on your uptime and your contracts or status page make commitments about it. If you add it, the business continuity, logging and monitoring, and network policies gain availability wording and your auditor tests evidence for those controls.

SOC 2 for developer tools and API companies

Updated 23 October 2026

Developer tools sit close to their customers' code, credentials and pipelines, so security reviewers ask about your software supply chain and how you handle secrets as well as the standard SOC 2 topics. This page covers where those questions meet SOC 2, which categories are commonly added, the policies reviewers read most closely and what to select in the free generator.

Why platform and security teams ask for SOC 2

Customers connect developer tools to source code, CI/CD pipelines, cloud accounts and production data, so a compromise of your tool could reach their systems.
API keys, tokens and webhook secrets you issue are credentials into customer systems, and reviewers ask how they are issued, stored, scoped and revoked.
Platform and security teams ask how you build and release software: dependency management, protected branches, build integrity and signed releases.
Developer tools are often adopted by engineers first, and SOC 2 comes up when the purchase reaches procurement and security review.

Trust Services Categories commonly requested

Security is in every SOC 2 report. The other categories are optional and are added when customers ask for them or your contracts make commitments they cover. What follows is what platform and security teams commonly request, not a rule; agree on the scope with your auditor before the examination period starts.

Category	Why it comes up	In the generator
Security	Included in every SOC 2 examination. The common criteria cover governance, risk assessment, access, change management, monitoring, incident response and vendor risk.	Always
Availability A1.1, A1.2, A1.3	Commonly requested when customers call your API from their own production systems or depend on it in their release pipeline.	Yes
Confidentiality C1.1, C1.2	Commonly requested when the product handles customer source code, secrets or other information customers treat as confidential.	Yes
Processing Integrity	Sometimes requested for APIs whose results customers rely on without checking, such as data transformation, metering or billing calculations.	No

The generator’s scope question offers Security, Availability and Confidentiality. If your auditor scopes Processing Integrity, the 22 policies are still a starting point, but those criteria need controls and evidence beyond what the policies describe.

Other frameworks that come up, and how they relate to SOC 2

Each framework below is published by its own standards body or regulator; the links go to them. This is a general description, not legal advice: whether a law or contract applies to you is a question for counsel.

Software supply chain: NIST SSDF and SLSA

The NIST Secure Software Development Framework (SP 800-218) describes secure development practices, and SLSA is a framework for build integrity and provenance. Buyers ask about practices from both: dependency scanning, protected branches, reviewed changes, isolated builds, signed artifacts and provenance. SOC 2's change management, vulnerability management and logical access criteria test some of the same controls.

Keep in mind: Neither framework is part of SOC 2. A SOC 2 report does not show that you meet a SLSA level or follow the SSDF; if customers ask for those, answer them separately.

Sources: NIST SP 800-218: Secure Software Development Framework · SLSA: Supply-chain Levels for Software Artifacts

Secrets management

Secrets have two sides for a developer tool: your own (cloud keys, signing keys, CI tokens) and the ones you issue to customers (API keys, OAuth tokens, webhook signing secrets). The Acceptable Use and Encryption and Key Management policies require a secrets manager and secret scanning, and with API selected as the application type they add rules for customer API keys. The OWASP Secrets Management Cheat Sheet is a practical reference for the implementation.

Keep in mind: The policies state what is required. Check that secret scanning, rotation and key storage actually work that way before management adopts them.

Sources: OWASP Secrets Management Cheat Sheet

Open source security posture

If you publish open source components, OpenSSF Scorecard checks a repository for practices such as branch protection, pinned dependencies, code review and signed releases. Some buyers look at it when they evaluate open source parts of a product.

Keep in mind: Scorecard results are automated checks of a public repository, not an assessment of your company.

Sources: OpenSSF Scorecard

The 6 policies that matter most

All 22 policies apply to every company that uses them. These are the ones platform and security teams read most closely, so review them first and make sure every statement matches how you actually operate. The template index lists the full set.

P10 Secure Software Development Policy: Where code review, threat modeling, dependency management, secrets in code and API security requirements are written down.
P09 Change Management Policy: Reviewers ask how a change gets from a pull request to production and who, if anyone, can bypass review.
P11 Vulnerability and Patch Management Policy: Covers dependency, container and infrastructure vulnerabilities and the time frames for fixing them by severity.
P08 Encryption and Key Management Policy: Covers secrets and signing keys and, with API selected, how customer API keys are generated, stored and revoked.
P03 Access Control Policy: Covers who can reach production, source code and the release pipeline, and how that access is approved and reviewed.
P12 Logging and Monitoring Policy: Customers ask whether API and administrative actions are logged and how security events are detected and reviewed.

What to select in the generator

These answers change the policy text for developer tool and API companies. The other questions (company, product, tools, owners, review cadence) are the same for everyone.

Question	Answer	What it changes
Application type	API (or Multiple, if you also have a web app or CLI)	Adds rules for customer API keys (random, shown once, stored hashed, scoped and revocable), per-client rate limits, and API versioning and documentation.
CI/CD pipeline	The CI/CD system you build and release with, such as GitHub Actions	The change management, secure development and vulnerability policies name it as the place where checks run and releases are built.
Trust services categories in scope	Availability	Add it if your auditor has scoped it, typically because customers depend on your API in production. The business continuity, logging and monitoring, and network policies, among others, then gain uptime, capacity and recovery wording.
Trust services categories in scope	Confidentiality	Add it if your auditor has scoped it, for example because you handle customer source code or secrets.

Questions an auditor may ask

Walkthrough questions in a SOC 2 examination follow the criteria, but the examples an auditor picks depend on what your product does. These are the kind that come up for developer tool and API companies; the auditor interview prep sheet lists the questions per criterion with the sentences in your policies that answer them.

Who can merge to the main branch and release to production, and can anyone bypass review?
How are dependencies scanned, and how quickly were the most recent critical findings fixed?
Where are production secrets and signing keys stored, who can read them and how are they rotated?
How are customer API keys generated, stored and revoked?
How do you detect and respond to a secret committed to a repository?
How do you keep one customer's data and workloads separate from another's?

Free tools for this

SOC 2 policies for GitHub teams: What the policies say about change management, code review and secret scanning in GitHub.
Auditor interview prep: Walkthrough questions per criterion and the sentences in your policies that answer them.
Access review template: A quarterly review sheet and a service account inventory for CI tokens and deploy keys.
SOC 2 evidence checklist: The evidence auditors sample, including pull request reviews and vulnerability tickets.
SOC 2 readiness self-assessment: A quick score and a prioritized list of gaps.
Trust page generator: Publish your security practices where engineering buyers look first.

Other industries

Frequently asked questions

Does SOC 2 cover software supply chain security?: Partly. The change management, vulnerability management and logical access criteria cover reviewed changes, timely fixes and access to source code and pipelines. SOC 2 does not ask for specific practices such as build provenance or signed artifacts. If customers ask for those, frameworks like SLSA and the NIST SSDF describe them.
We are an open source company. What does SOC 2 examine?: SOC 2 examines a system you operate, such as a hosted version of your product, and the company controls around it. The open source project as such is not examined, but the code you ship into the hosted service goes through your change management and secure development controls.
How should we handle customer API keys?: With API selected as the application type, the policies state that customer API keys are random, shown once at creation, stored only as a salted hash, scoped to minimum permissions and revocable at any time. Check that your product does this before you adopt the wording.
Do we need Availability if we sell an API?: Not necessarily. Add it if customers depend on your uptime and your contracts or status page make commitments about it. If you add it, the business continuity, logging and monitoring, and network policies gain availability wording and your auditor tests evidence for those controls.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.