Repository security audit for Series A startups: what to fix before your first enterprise deal

Why Series-A Is the Wrong Time to Wing It

The security questionnaire that lands in your founder’s inbox after the first enterprise demo is not a formality. It is an itemized list of controls — often pulled directly from SOC 2, ISO 27001, or a bank-specific template — and the buyer’s security team reads your answers like a lender reads a credit application. “We are working on it” is a scored response, and the score is zero.

At seed stage, this is forgivable. Vendors under 10 employees get leniency, and most enterprise buyers will accept a credible roadmap in lieu of evidence. By Series A — especially after a public funding announcement — the bar changes. Your prospective customer’s procurement team has now seen a press release saying you have runway, a team, and customers, and they expect the controls to match.

A repository security audit is the cheapest, highest-leverage piece of that preparation. It is self-contained, it does not require external auditors, and the artifact it produces — a documented control catalog applied to every repo — is exactly what the questionnaire asks for. This is the 2026 playbook.

What the Audit Actually Covers

A repository security audit in 2026 is not a point-in-time scan. It is a seven-area review that produces both a set of configuration changes and an evidence pack. The seven areas:

1. Secret exposure — current, historical, and write-path prevention
2. Dependency risk — known vulnerabilities, license posture, and supply-chain provenance
3. Static analysis (SAST) — language-specific code-quality and security rules with triage
4. Branch protection and review requirements — who can push, who can merge, what is required
5. CI/CD security — workflow permissions, secret access patterns, and artifact signing
6. Access and identity — org membership, outside collaborators, SCIM, and PAT hygiene
7. Build provenance (SBOM + SLSA) — what the build produced, and how to prove it

Each of these maps directly to a section of SOC 2 CC8.1 (change management) and CC6.8 (vulnerability management), to ISO 27001 A.8 and A.14, and to the specific questions in NIST SSDF PS.3. That mapping is what makes the audit worth doing once and referring back to forever.

Area 1: Secrets — The Five-Minute Part That Takes Two Days

Enable GitHub Advanced Security secret scanning (or GitLab Secret Detection, or the equivalent on your platform) across every repository today. Push protection on by default. This is the five-minute part.

The two-day part is historical cleanup. Secret scanning will find credentials that were committed two years ago, rotated, and forgotten. Every finding needs triage: confirm rotation, mark as resolved, or — if the secret is still valid — rotate it immediately and investigate access logs. A common startup finding: an AWS access key committed during an initial integration spike, revoked later, but the access key ID is still tagged to a deleted user and no one remembers when it was last used.

For secrets you find in active branches, never just delete the file. Delete the secret, rotate it, and use git filter-repo to purge it from history if the repository is private and small. For public repos or large histories, consider the secret compromised forever and rotate, rotate, rotate.

Pair this with trufflehog or gitleaks running in pre-commit. Push protection is the final barrier; pre-commit is the cheap barrier that prevents most incidents from reaching the server in the first place.

Area 2: Dependencies — Dependabot Is the Floor, Not the Ceiling

Dependabot (or Renovate, or GitLab’s Dependency Scanning) enabled with weekly PRs is the baseline. The Series-A-specific upgrade is three additional controls:

First, add version pinning with a lockfile verification step in CI. npm ci, poetry install --sync, go mod verify, cargo --locked — these prevent a transitive dependency from being silently upgraded during a build. The December 2025 ChainJacking campaign that affected 200+ npm packages underlined this; teams with pinning survived, teams without ate a weekend.

Second, add a license posture check. fossa, license-finder, or GitHub’s license detection will flag GPL/AGPL dependencies that get pulled in through a transitive path. Enterprise customers in regulated verticals will ask about your license inventory. Having the answer pre-computed saves a week.

Third, review EPSS scores, not just CVSS. A CVE with CVSS 9.8 and EPSS 0.003 is a library bug that nobody is exploiting. A CVSS 6.4 with EPSS 0.72 is actively weaponized. 2026 tooling — including the GitHub security advisories surface — now ranks by EPSS, and the triage discipline of “fix the exploited ones first” is what separates mature teams from teams that drown in the backlog.

Area 3: SAST — Pick One, Wire It In, Turn Off the Noise

The single most common Series-A mistake is enabling four SAST tools and fixing none of the findings. Pick one.

For most startups the answer is Semgrep (free tier, OSS rules), CodeQL (free for public repos, reasonable for private), or GitLab’s built-in SAST if you’re on GitLab. The 2026 difference — compared to a year earlier — is that these tools now ship with curated rule packs that have meaningfully lower false positive rates. A clean ruleset for a typical Node + Python + Go codebase will surface 20–80 real findings on first run, not thousands.

Triage discipline: create a GitHub issue for every finding, tag with severity, assign to a service owner. Block new criticals from merging via status check. Do not block the merge queue on existing findings — that creates a backlog that nobody fixes. Block new findings only.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

Area 4: Branch Protection — The Single Most-Audited Setting

Every enterprise security questionnaire will ask, “Is direct push to main disabled?” If the answer is no, you lose points on more than one line.

The 2026 baseline for the main branch:

• Require pull request with at least one approving review
• Require status checks to pass (tests, SAST, secret scan)
• Require branches to be up to date before merging
• Require signed commits
• Require linear history
• Block force pushes, block deletions
• Dismiss stale reviews when new commits are pushed
• Require CODEOWNERS review for protected paths (infra, auth, billing)

For repositories that define production infrastructure (Terraform, Helm, Kustomize), add a second required reviewer and require the review to come from a CODEOWNERS group, not an individual. This is cheap and it is the single most effective control for preventing insider-risk incidents.

Use GitHub rulesets (or GitLab push rules) rather than classic branch protection. Rulesets are versionable as JSON, visible to auditors, and they do not drift when someone changes a setting in the UI.

Area 5: CI/CD Security — Token Hygiene First

The 2024–2025 wave of CI compromises (tj-actions, SolarWinds-style supply chain, the May 2025 GitHub Actions backdoor) made two controls non-optional for Series-A startups selling into enterprise:

Pin third-party actions by SHA, not tag. uses: some-org/some-action@v2 trusts the tag owner forever. uses: some-org/some-action@abc1234... trusts a specific commit. Dependabot will still open update PRs; you just review them before adopting.

Minimum-privilege GITHUB_TOKEN. Default permissions: read-all at the workflow level. Override to write only in the specific jobs that need it. Most workflows do not need write permission at all.

Pair this with OIDC federation to your cloud accounts instead of long-lived AWS access keys or GCP service account keys in CI secrets. aws-actions/configure-aws-credentials with an IAM role trust policy on your GitHub org is the modern pattern. Rotate nothing because there is nothing to rotate.

For artifact signing, Sigstore’s cosign is the 2026 default. Sign every container image and every release artifact. The cost is a cosign sign step in your build. The benefit is an unforgeable claim — useful in your own incident response and increasingly asked for in enterprise questionnaires under “artifact integrity.”

Area 6: Access — Offboarding Is Where Startups Fail

The audit finding that reliably shows up in every startup repo review is “former employee still has access.” Not because anyone is careless — because offboarding is distributed across five tools and something slips.

The controls that fix this once:

• SSO/SAML required for org access, with SCIM for deprovisioning
• No outside collaborators on production repos; if contractors need access, use an org seat with an explicit expiration
• Quarterly access review — one person goes through the org member list and the outside collaborator list, confirms every account against the current team roster, and files the review artifact
• Personal access tokens (PATs) with expiration; no fine-grained PATs without scope documentation
• Service accounts are bot accounts with SSO exemption, owned by a team, not by an individual

Document the quarterly access review. The artifact — a short Notion page or markdown file with a date, reviewer name, and list of changes made — is what enterprise auditors want.

Area 7: SBOM and SLSA — Yes, You Need This Now

In 2026, SBOM generation is cheap and expected. Every build should produce a CycloneDX or SPDX SBOM — syft is the OSS default, anchore/sbom-action is the GitHub-native path. Attach the SBOM to the release; attach it to the container image as an OCI artifact.

SLSA is the harder control. SLSA Level 2 — signed provenance that ties build outputs back to source — is achievable with GitHub’s built-in attestations (attest-build-provenance) or with Sigstore plus a hermetic builder. Most Series-A startups target SLSA L2 on production release artifacts and leave L3 (fully hermetic, reproducible builds) as a Series-B goal.

Enterprise buyers in financial services, healthcare, and federal-adjacent verticals are now asking for SBOM + SLSA L2 in the initial questionnaire. Having it before they ask removes a month of back-and-forth from the sales cycle.

The Evidence Pack

When the audit is done, produce a single artifact — the evidence pack — that you will hand to every prospect that asks. Recommended structure:

1. Summary: what repos are in scope, what controls are applied, what is the exception list
2. Per-repo configuration snapshot (branch protection JSON, ruleset JSON, workflow permissions)
3. Latest Dependabot/Renovate status, latest secret scan status, latest SAST summary
4. Access review log (most recent quarterly review)
5. Sample SBOM and SLSA attestation from a recent release
6. Exception list (anything that deviates from the baseline and why)

Keep it in a private Notion page or a repo in your org. Give read access to prospects under NDA. Update it quarterly. The first customer to ask for it will cost you a day. The tenth will cost you the time it takes to forward a link.

How IAN Helps

IAN connects to your GitHub or GitLab organization and runs the seven-area audit continuously. It generates the evidence pack as a byproduct — branch protection state, SAST summaries, dependency posture, and access-review-ready reports — all timestamped and exportable.

When it finds a gap — a repository without branch protection, an action pinned by tag instead of SHA, a workflow with permissions: write-all, a missing CODEOWNERS file on an infrastructure repo — it opens a pull request that fixes the misconfiguration. You get the Series-A-grade security posture without dedicating engineering weeks to the audit, and you get a paper trail that makes the next enterprise questionnaire mechanical.

The One-Week Plan

If you read this on Monday:

• Monday: Enable secret scanning + push protection org-wide. Enable Dependabot or Renovate everywhere.
• Tuesday: Pick one SAST tool. Enable it on the top three repos by LOC.
• Wednesday: Apply the branch protection baseline via ruleset. Commit the ruleset JSON to a security repo.
• Thursday: Pin actions by SHA. Set permissions: read-all workflow default. Wire OIDC to AWS/GCP.
• Friday: Run your first access review. Produce v1 of the evidence pack.

By the following Monday, you are ahead of 80% of Series-A startups on repo security. By the following quarter, you will never again lose a week of the sales cycle to a security questionnaire.

Get a free infrastructure audit → | See pricing →