SOC 2 for developer tools, built for builders.
Your customers trust you with source code, CI pipelines, and production secrets. Skadi scopes SOC 2 Type II around the controls that actually matter for dev-tools companies: tenant isolation on runners, secret handling, and provable protection of customer repositories — audited by senior CPAs who read your architecture before they read your policy.
Audit challenges we solve for you.
Enterprise engineering leaders won't onboard a tool that cannot prove strong controls over customer repos, branches, and build artifacts.
If you run customer code, you must describe isolation boundaries, monitoring, and containment — vague answers here kill deals with security-mature buyers.
Deploy keys, cloud credentials, and third-party tokens flow through your platform. Any exposure is a security incident by definition, and buyers assume you will be attacked.
A compromise of your platform is a supply-chain event for every customer. That reality changes what an acceptable exception looks like and raises the bar on evidence quality.
Controls that matter most for your business.
Sandbox model, kernel/namespace/VM boundaries as applicable, evidence customer workloads cannot access each other's data or the control plane. Tested with described attack scenarios, not assertion.
Vault-based storage, per-tenant encryption, no-standing-access enforcement for engineers, immutable audit logs on every read, and rotation cadence evidenced.
Who inside your company can access customer repositories, under what break-glass procedure, with what logging and customer notification. The single most-scrutinized control.
Provenance for build outputs, signed artifacts where applicable, and controls preventing tampering between build and deploy.
PR review enforcement, mandatory CI checks, deploy approvals — you must demonstrate this even more rigorously than your customers do.
Dependency scanning, container base image tracking, SLA-based remediation — covering both your platform and any customer-facing runtime you ship.
Just-in-time elevation, per-session approval, session recording where feasible, and customer notification where contractual. Frequently under-controlled.
SBOM generation, signed releases, and provenance metadata (SLSA-aligned where feasible) — increasingly asked for by enterprise buyers post-SolarWinds.
What actually fails in this vertical.
Real deviations we see in SOC 2 Type II fieldwork — and what your platform and security teams should fix before the observation window starts.
GitHub App requests repo:write when read + specific webhooks would do. Least privilege is a Trust Services principle; over-scoped tokens fail CC6.1 on inspection.
- OAuth/GitHub App manifest with declared scopes
- Least-privilege review doc with justification per scope
- Screenshot of consent screen shown to customers
- Ticket approving any scope increase
One debug print pushed to prod, secrets in CloudWatch for weeks. Requires secret scanning on logs and a scrubbing pipeline — not just careful engineers.
- Log-scrubbing config (regex / DLP rules) in the ingest pipeline
- Secret-scanning CI job on every PR with sample run
- Incident ticket for any historical leak with remediation
- Policy prohibiting secrets in logs with training completion record
Repo mirror or CI cache holds code after the customer offboarded. Deletion must cascade to build caches, artifact stores, and derived indexes.
- Deletion runbook covering repo mirrors, CI caches, artifact registry
- Offboarding ticket with per-system deletion timestamps
- Retention config for build caches / artifact stores
- Sample deletion-verification report for a departed customer
Job runners reuse a global service account with cross-tenant access. Ephemeral, per-job credentials scoped to the workspace are the modern control.
- Runner architecture doc showing per-job credential minting
- OIDC / STS config for CI ↔ cloud
- IAM policy showing tenant-scoped role
- CI job log demonstrating ephemeral token issuance
Release signing key exported for developer convenience. Move to HSM/KMS with quorum controls and audit logs — signed by artifact, not by person.
- KMS/HSM configuration for signing key with access policy
- Signed artifact + signature verification log
- Quorum / MofN approval config for key use
- Policy prohibiting local key material with attestation record
Dependabot/Renovate PRs auto-merged. Add a review gate for high-severity CVEs and license changes and evidence approvals — auditors sample from the merge history.
- Branch-protection rule requiring reviewer on dependency PRs
- SCA/SBOM tool report (Snyk, GitHub Advanced Security)
- Sample PR with reviewer comment on CVE/license
- Policy defining severity thresholds requiring escalation
Why dev-tools SOC 2 is a higher bar
When your product is engineering infrastructure, a control gap is not hypothetical — it is a supply-chain risk to every customer downstream. Enterprise buyers of CI, IDEs, feature flags, observability, and dev platforms apply extra scrutiny in security reviews. A Type II report scoped generically will not clear procurement; it must specifically address the crown-jewel assets you hold.
The runner isolation question
If your product executes customer code — CI runners, preview environments, sandbox notebooks — the single biggest question in enterprise procurement is: 'How do you prevent one customer's workload from touching another's?' Your SOC 2 must describe the isolation architecture, the monitoring that would detect escape attempts, and the response plan if isolation ever failed. We test those three things by name in every dev-tools engagement.
Secret handling as a first-class control
In a dev-tools SOC 2, secret management is not folded into 'access control' — it is a discrete control area with its own testing procedure. Vault-based storage, per-tenant encryption, no-standing-access from engineers, and immutable audit logs on every read are all tested individually. Weak controls here are the fastest way to a qualified opinion in this segment.
Supply chain expectations rising
Post-SolarWinds and post-XZ, enterprise buyers of dev tools increasingly ask about SLSA levels, SBOM generation, signed releases, and provenance. SOC 2 does not formally require them, but including these controls in your Type II report proactively short-circuits an entire class of vendor questionnaire that would otherwise slow deals down.
Questions we hear from teams like yours.
Ready to scope your SOC 2 Type II?
Book a call and we'll walk you through timeline, scope, and pricing for your company.