SOC 2 by industry

SOC 2 for developer tools: when the customer data is code and keys.

Q: Will auditors read our code?

No; they test controls around it. Auditors look at change management, review records, access and pipeline configuration. A code review of your product is the job of a penetration test or a secure code review, not the SOC 2.

Developer tools hold the most sensitive thing a software company owns: its source code, and often the secrets that unlock its production systems. A CI service, a code host, an observability agent or a package registry can become a path into every customer at once. Buyers know this, and they read a devtools SOC 2 for one thing above all: could someone use you to reach them?

Back to SOC 2 services

01 · Who asks

Who asks developer tools companies for a SOC 2 report

The buyer decides the scope and the weight of the report, so start with who is asking.

Asked by	What they want to see
Customer's platform or security engineering lead	How their tokens and secrets are stored, who on your side can see them, and how build runners are isolated.
Customer's application security team	How you secure your own release pipeline, since your code runs inside theirs.
Enterprise procurement	A current Type 2 report, a pen test summary and your vulnerability disclosure process.
Public-sector or regulated buyer	A secure development attestation and evidence of a software bill of materials for what you ship.

02 · What is in scope

What sits inside the system boundary

The report covers one system. In this sector the boundary usually takes in:

Customer repositories and artifacts: Source code, build outputs and packages you host or process, at rest and in transit.
Secrets store: Customer tokens, keys and environment variables, and the service that decrypts them at runtime.
Build and job runners: Hosted machines that execute customer code, and how one job is kept from seeing another's.
Agents and CLIs you distribute: Software customers install in their environments, and the pipeline that signs and publishes it.
Public API and integrations: OAuth apps and webhooks that act inside customers' code hosts and clouds.

03 · Categories

Which Trust Services Categories matter here

Security is always in. The rest depend on what you promise customers.

Category	Weight in this sector	Why
Security	Always	Required, and here it carries supply-chain weight: your compromise is your customers' compromise.
Confidentiality	Strong	Source code and secrets are confidential by any definition, with disposal duties when accounts close.
Availability	Often	A CI or registry outage stops customers shipping; many commit to uptime.
Processing Integrity	Sometimes	Relevant when you promise that builds, artifacts or scans are complete and unaltered.
Privacy	Rarely	Personal data is usually limited to account holders and commit metadata.

04 · Vendors in the report

The vendors that appear in your report

Each one is a subservice organization or a carve-out, and the report has to say which.

Cloud host and compute provider: Usually carved out; runner isolation built on top of it is yours to describe and test.
Key management service: Carved out, with your key policies, rotation and access to keys kept in scope.
Code host you integrate with: Not usually a subservice organization: customers bring it. Describe the permissions your integration requests.
Package and container registries you publish to: Name them where your released agents and images are hosted, and the controls on publishing rights.

05 · Sector controls

Controls that this sector makes necessary

Examples only. Your own wording is what the auditor tests.

S.1
Ephemeral, single-tenant runnersEach job runs on a fresh environment destroyed afterwards; no state carries between customers.
S.2
Secret redaction and scopingSecrets are masked in logs and exposed only to jobs and branches the customer allows.
S.3
Staff access to customer codeEngineers can't browse customer repositories; access for support needs customer consent and is logged.
S.4
Signed releasesAgents, CLIs and images you ship are built in a controlled pipeline and signed; signing keys are restricted.
S.5
Dependency and SBOM reviewThird-party dependencies in shipped software are tracked, scanned and updated under a defined process.
S.6
Least-privilege integration scopesOAuth apps request the narrowest permissions; scope changes go through security review.
S.7
Leaked credential responseA defined procedure revokes and notifies when a customer secret or your own key may have been exposed.

06 · Traps

Where companies in this sector slip

Predictable, and cheaper to fix before fieldwork.

Scoping the SaaS but not the agent. The software customers install is often the larger risk. Leaving its build and release out weakens the report.
Calling runners isolated without testing it. Isolation should be evidenced, for example by configuration, tests and pen-test findings, not asserted.
Your own CI holding production keys. If your pipeline can deploy to production and publish releases, its access is in scope and needs tight control.
Engineers with broad debug access. Debug tools that can read job environments are a staff path to customer secrets.
Forgetting forked and public-repo builds. Untrusted pull requests that receive secrets are a classic leak path; describe how you prevent it.

07 · Code and secrets

Treating source code, secrets and pipelines as customer data

Map each customer asset to where it lives, who can reach it, and what proves that.

Customer asset	Where it lives (illustrative)	Who could reach it	What evidences control
Source code	Repository storage, runner workspaces, caches	Runner jobs; staff with storage access	Storage access lists, workspace teardown logs
Secrets and tokens	Encrypted store, job memory, logs	Jobs on permitted branches; decrypt service	Key policies, redaction tests, decrypt audit log
Build artifacts	Artifact storage, registries	Customer users; publishing service	Retention settings, publish permissions
Pipeline definitions	Repository files, your config store	Anyone who can open a pull request	Branch protection guidance, fork rules

Some of these protections depend on customer settings, such as branch protection or which branches may read secrets. List those as complementary user entity controls so a reader knows where your responsibility ends.

08 · Evidence

Evidence to have ready

What an auditor will ask for, in the order they usually ask.

Architecture of runner isolation and teardown
Key management policies and the access log for decryption keys
Staff access requests to customer repositories with consent records
Release pipeline configuration and signing key custody
Dependency scan results and remediation tickets for shipped software
Most recent penetration test covering runners and the API
Leaked-secret response records, if any occurred in the period

Federal buyers may ask for a secure development attestation

Under earlier US federal guidance, agencies asked software producers to attest to secure development practices drawn from NIST SP 800-218, the Secure Software Development Framework, on a common attestation form. The status of that requirement has been changing, so check current federal guidance before you answer a buyer. Either way it is a separate document from a SOC 2. Your report can support it, but it does not amount to that attestation or to compliance with any federal requirement.

Sources: AICPA Trust Services Criteria (TSP section 100, 2017, revised points of focus 2022), including CC6, CC7 and CC8; AICPA description criteria (DC section 200); AICPA SOC 2 guide; NIST SP 800-218, Secure Software Development Framework.

More about SOC 2 for developer tools

Our customers self-host the tool. Is a SOC 2 still useful?

Yes, for your build and release.

With a self-hosted product, customers care less about your hosting and more about the integrity of what you ship: source control, build, signing and update channels. Scope the report around that pipeline.

Do open-source contributors count as personnel?

Not as staff, but their changes are in scope.

Outside contributors aren't your employees, but code they submit flows into your product. Describe the review and merge controls that apply to external contributions.

Will auditors read our code?

No; they test controls around it.

Auditors look at change management, review records, access and pipeline configuration. A code review of your product is the job of a penetration test or a secure code review, not the SOC 2.

Should runner isolation be covered by a pen test?

Commonly, yes.

Your own control wording decides what is tested, but buyers of build services routinely ask whether a test tried escaping a job or reading another tenant's data. Including runners in the test scope answers that question directly.

Scope your developer tools SOC 2 around what buyers ask.

A readiness assessment turns this into your boundary, your categories and your gaps.

Get a SOC 2 readiness assessment Book a free consultation Back to SOC 2 services