SDLC Security Gates Audit

Read-only access to your SCM organisation and repositories - a GitHub App, GitHub fine-grained PAT, GitLab project token, or Azure DevOps PAT scoped to the minimum required read permissions and time-limited to the audit window. We optionally also read CI configuration files. We never clone your source code, never export secrets or environment variables, and never call write APIs. The audit works against organisation, repository, and pipeline configuration plus metadata only.

All four SCM platforms are supported, plus the major CI / CD platforms layered on top of them: GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, CircleCI, and Buildkite. If you use a less common combination, mention it in the form and we'll confirm coverage during scoping.

Yes. Every finding in the report is mapped to a specific SLSA level requirement, NIST SSDF practice, and OWASP SAMM activity, plus the relevant SDLC controls in SOC 2 CC8.1 and ISO 27001. The output is designed to drop directly into auditor evidence packs and to give you a defensible roadmap to the next SLSA level.

If you use GitHub Copilot, Cursor, Claude Code, or in-house agents, we add a dedicated review covering MCP server permissions and trust, autonomous PR creation, code-execution sandboxing, secrets and environment exposure, prompt-injection and tool-call abuse vectors, and human-in-the-loop policy. The aim is to keep developer velocity while putting hard guardrails around what an agent can read, write, and execute.

A SAST or DAST tool finds vulnerabilities in your code or running app. This audit reviews the gates around them - whether scanners are configured correctly, whether they actually block bad changes, who can bypass them, how artefacts are signed and provenance-tracked, and how the build environment itself is hardened. Most real supply-chain incidents (compromised actions, leaked PATs, malicious dependencies, tampered artefacts) live in those gates, not in the application code.

No. The audit is fully read-only and runs against configuration metadata, not your pipelines themselves. Nothing we do can trigger a build, modify a workflow, or block a deploy. You can run the audit during normal business hours with zero risk to delivery.

Typical turnaround is 1-2 business days from the moment read-only access is granted, plus a 45-minute live findings walkthrough at a time that suits your team. Larger estates spanning many organisations or hundreds of repositories can take a little longer; we confirm the timeline as soon as we see the scope.

Yes - the framework mapping is explicitly designed for that. The report calls out exactly which findings affect SOC 2 CC8.1, ISO 27001 A.14 / A.8, PCI-DSS 6, and HIPAA technical safeguards, and the remediation roadmap orders work so you reach audit readiness with the fewest changes. Many teams use this as the input for their next audit cycle.