AppSec Shift-Left: SAST, SCA and Secrets Scanning Without Slowing the Team

Every time a CISO announces 'shift-left' on a Thursday, some platform team spends the weekend ripping gates out of the pipeline. The promise of catching vulnerabilities before merge is real, but execution usually collapses into a SAST tool with 4,000 findings, an SCA flagging a 2017 CVE in a test library, and a secrets scanner failing because someone committed an .env.example. The outcome is predictable: ignored PRs, broken builds, frustrated devs, and security turned into bureaucracy. At Basilisk OffSec we run AppSec as an internal product, with SLAs, friction metrics, and a staged rollout path that begins as warning-only and ends with surgical blocking.

Before installing any tool, define what you call 'critical'. Without that definition, Semgrep, Snyk and CodeQL will compete to see who alarms more. Use the service threat model as the baseline: if you do not have one yet, start with STRIDE Threat Modeling in Sprints: A Full Microservice Walkthrough and tier your assets into three buckets. For a tier-1 microservice handling PII, any CWE-89 or CWE-78 caught by SAST should break the build. For an internal batch job, a weekly report may be enough. This severity-by-context mapping cuts relevant false positives by 60 to 80 percent, according to measurements from our 12-squad pilot in 2025.

SAST alone does not fix things. Pair Semgrep (custom YAML rules, cheap to maintain) with CodeQL for deeper dataflow in Java and C#. Start in comment-only mode on GitHub: the bot posts findings on the PR without failing the check. Track two things for 30 days: median time from comment to fix, and 'wont-fix' rate. If 'wont-fix' exceeds 40 percent, your rule baseline is wrong, not the team. After that window, promote only rules with precision above 85 percent to a blocking gate. For deeper context on web injection classes, pair the rollout with hands-on study in SQL Injection in Practice: Exploiting, Detecting and Mitigating in a Controlled Lab and Modern XSS: DOM, Stored and Reflected With Real Examples in a Test Lab so devs understand what the linter is actually shouting about.

SCA is where most teams trip. Trivy, Grype and osv-scanner are solid, but every one of them will surface hundreds of transitive CVEs in dependencies you never call. The only metric that matters is reachability. Use Endor Labs, Socket, or osv-scanner with the --experimental-call-analysis flag to filter CVEs in uninvoked functions. Combine that with a signed SBOM and a quarantine policy, as covered in Supply Chain Security: Sigstore Signing and Real SBOMs in CI/CD. And do not forget typosquatting and namespace hijacking: an internal proxy (Artifactory, Nexus) with an allowlist solves 90 percent of the problem, while Dependency Confusion and Typosquatting: Practical Defense for Dev Teams details the traps that still slip through.

Secrets scanning is the quick win most teams botch. Gitleaks and Trufflehog on pre-commit catch the leak before the push, but you need a second server-side scanner (GitHub Advanced Security or Gitleaks via Action) to cover local-hook bypass. The critical point: once a secret is detected in a pushed commit, treat it as public. Force rotation, do not rewrite history. In 2025 we saw three incidents where teams burned hours on git filter-repo while the AWS key was already being abused. Keep an automated runbook that revokes the credential in under 5 minutes and opens a post-mortem ticket.

Friction metrics are what separate functional AppSec from security theater. Track four KPIs per squad: median security pipeline time (target under 4 minutes), rerun rate caused by flaky scanners (target under 5 percent), critical-finding MTTR (target under 7 days), and internal NPS from product teams on the tooling. If NPS drops below zero, pause expansion and investigate. Layer in monthly purple-team sessions focused on real flows, aligned with Purple Team in Practice: Building a Red vs Blue Feedback Loop, to verify that what SAST finds matches what the red team actually exploits.

The practical takeaway is simple: do not flip everything to blocking on day one. Start with warnings, define criticality by context, measure friction, and only promote rules with proven precision. Six months in, you will have a pipeline devs respect because it rarely cries wolf, and when it does alarm, it is worth looking at. That is real shift-left, not shift-blame.