ci-security-gate — block insecure code at the door

When to use

The user wants automated, enforced security in their pipeline so problems are caught before merge — not after an incident. The goal is a gate that fails the build on real issues without drowning the team in noise.

Process

1. Choose the layers (cheap → deeper) and run them on every PR:
   • Secrets / dangerous code: secscan (secscan . --min-severity high) and/or gitleaks.
   • Dependencies: the ecosystem auditor + osv-scanner / grype.
   • SAST: Semgrep (semgrep --config auto) or CodeQL for deeper analysis.
   • IaC/containers (if relevant): trivy / checkov.
2. Set thresholds that fail the build (start strict only on the worst):
   • Fail on: any committed secret, any reachable high/critical vuln, high-severity SAST.
   • Warn (don't fail) on: low/medium, to avoid alert fatigue early on.
3. Make it required: mark the security job as a required status check in branch protection so PRs can't merge red.
4. Keep signal high: allow scoped, reviewed suppressions (e.g. # secscan:ignore, semgrep nosemgrep) with a comment explaining why; review suppressions periodically.
5. Cache tool installs and run jobs in parallel so the gate stays fast (< a few min).

Example (GitHub Actions, blocking on high severity)

security:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: Hayatelin/secscan-skill@v1
      with: { path: ".", min-severity: "high" }
    - run: pipx run osv-scanner scan .

Pitfalls

• Failing on everything from day one → the team disables the gate. Ramp severity up.
• A gate that isn't a required check → it gets ignored.
• Slow gates (>5 min) get skipped; parallelize and cache.

Report back

Summarize which layers run, what fails vs warns, whether it's a required check, and the current pass/fail state.