How to run a repository security audit

Your Repositories Are Leaking More Than You Think

A repository security audit is not a compliance checkbox. It is the single fastest way to understand your actual attack surface — because your repos contain far more than application code. They hold CI/CD pipeline configurations, infrastructure-as-code templates, dependency manifests, environment variable patterns, and sometimes raw secrets that should never have been committed.

GitHub’s 2025 State of Secret Sprawl report found that secret leaks grew 28% year-over-year, with over 19 million new secrets detected across public repositories alone. Private repos are worse — teams assume they are safe and skip basic hygiene. The result is a compounding exposure problem that grows with every commit.

This guide walks through a practical, five-layer repository security audit. You can run it manually or automate it. Either way, the goal is the same: know exactly what is in your repos and fix what should not be there.

Layer 1: Secret Detection

The most critical and most common finding. Leaked secrets — API keys, database credentials, OAuth tokens, private keys — are the fastest path to a breach.

What to scan for:

• API keys and tokens (AWS, GCP, Azure, Stripe, Twilio, SendGrid, etc.)
• Database connection strings with embedded credentials
• Private keys (SSH, PGP, TLS certificates)
• OAuth client secrets
• Internal service tokens and webhook URLs

Tools:

• truffleHog — scans git history for high-entropy strings and known secret patterns. Catches secrets that were committed and later deleted (they are still in history).
• gitleaks — fast, regex-based scanner with a large ruleset for known provider formats.
• GitHub Advanced Security — native secret scanning with push protection (blocks commits containing known secret formats).

# Scan the full repository history with truffleHog
trufflehog git file://. --since-commit HEAD~500 --only-verified

# Scan with gitleaks (faster, broader patterns)
gitleaks detect --source . --verbose --report-format json --report-path audit-secrets.json

Critical: scanning only the current branch tip is insufficient. Secrets committed in previous commits, deleted files, or merged feature branches persist in git history. Always scan the full history.

Layer 2: Dependency Vulnerability Analysis

Every third-party dependency is a trust decision. Your repo may contain hundreds of transitive dependencies that your team never explicitly chose, and any of them could carry known vulnerabilities.

What to check:

• Direct and transitive dependencies against CVE databases
• Outdated packages (especially those with known exploits)
• Packages with known malicious versions (supply chain attacks)
• License compliance (some licenses are incompatible with commercial use)

# Node.js
npm audit --production

# Python
pip-audit --strict

# Ruby
bundle audit check --update

# Go
govulncheck ./...

# Multi-language (using OSV-Scanner)
osv-scanner --recursive .

The supply chain threat is accelerating. In early 2026, the TeamPCP campaign compromised widely trusted open-source security tools by injecting malicious payloads into GitHub Actions and PyPI packages. Dependency auditing is no longer optional — it is a continuous process.

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 →

Layer 3: CI/CD Pipeline Security

Your CI/CD configuration files are infrastructure. A misconfigured GitHub Actions workflow or GitLab CI pipeline can leak secrets, allow code injection, or grant attackers the ability to deploy arbitrary code.

Common CI/CD security issues:

• Workflows triggered by pull_request_target that check out untrusted code and run it with write permissions
• Secrets exposed to forked pull request builds
• Overpermissioned GITHUB_TOKEN (write-all when only read is needed)
• Unpinned actions using @main or @latest instead of commit SHA
• Script injection via user-controlled inputs (PR titles, branch names) interpolated into run: steps

# UNSAFE: unpinned action + overpermissioned token
jobs:
  build:
    permissions: write-all
    steps:
      - uses: actions/checkout@main
      - run: echo "PR title: ${{ github.event.pull_request.title }}"

# SAFE: pinned to SHA + minimal permissions
jobs:
  build:
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11
      - name: Log PR title safely
        env:
          PR_TITLE: ${{ github.event.pull_request.title }}
        run: echo "PR title: $PR_TITLE"

Tool: actionlint validates GitHub Actions workflow syntax and catches common security misconfigurations. Run it in CI to prevent new issues from merging.

Layer 4: Infrastructure-as-Code Review

If your repo contains Terraform, CloudFormation, Helm charts, or Kubernetes manifests, those files define your production infrastructure. Misconfigurations here create real-world exposure.

What to check:

• Public S3 buckets, security groups open to 0.0.0.0/0, unencrypted databases
• Missing logging and monitoring configuration
• Hardcoded credentials in IaC files
• Overpermissioned IAM roles and service accounts
• Missing network isolation (databases in public subnets)

# Terraform scanning with tfsec
tfsec . --format json --out audit-iac.json

# Kubernetes manifest scanning with kubesec
kubesec scan deployment.yaml

# Multi-framework scanning with Checkov
checkov --directory . --output json > audit-iac-checkov.json

Layer 5: Code Quality and Unsafe Patterns

Beyond known vulnerabilities, repositories accumulate unsafe coding patterns: SQL injection vectors, hardcoded credentials, insecure cryptographic usage, and debug code left in production paths.

What to check:

• SAST (Static Application Security Testing) for language-specific vulnerabilities
• Hardcoded IP addresses, URLs, or credentials in application code
• Debug/test code in production branches (verbose logging, disabled auth checks)
• Deprecated or insecure function usage (e.g., MD5 for password hashing)

# Semgrep: multi-language SAST with community rules
semgrep scan --config auto --json --output audit-sast.json

# CodeQL (GitHub): deep semantic analysis
codeql database create codeql-db --language=javascript
codeql database analyze codeql-db --format=sarif-latest --output=audit-codeql.sarif

Building an Audit Cadence

A one-time audit finds the backlog. A recurring audit prevents the backlog from returning. The practical cadence:

• Every commit — secret detection (pre-commit hook or CI check). This is non-negotiable.
• Every PR — dependency audit, SAST scan, IaC scan. Block merges on critical/high findings.
• Weekly — full repository history scan for secrets (catches commits to non-default branches).
• Monthly — comprehensive audit across all five layers with a written summary for the team.
• Quarterly — review and update scanning tool configurations, rulesets, and exceptions.

How IAN Automates Repository Security Audits

IAN connects to your GitHub or GitLab organization and runs all five audit layers continuously:

1. Full-history secret scanning — IAN scans every repository’s complete git history, not just the tip, and alerts on verified secrets with the provider and scope identified
2. Dependency monitoring — continuous CVE matching against your dependency graph, with alerts prioritized by exploitability and reachability
3. CI/CD configuration review — every workflow file is analyzed for the misconfigurations described above, with specific fix suggestions
4. IaC scanning — Terraform, CloudFormation, Kubernetes, and Helm charts scanned against security and cost benchmarks
5. Automated fix PRs — critical findings generate pull requests with the remediation applied, so your team reviews a fix instead of investigating a problem

The median time from finding to fix PR is under 4 hours. Compare that to the industry average of 65 days for vulnerability remediation.

Run Your First Audit Today

Start with secret detection. Install gitleaks, run it against your most critical repository, and review what it finds. Most teams are surprised. Then expand to the other layers as you build the muscle.

Get a free infrastructure audit → | See pricing →