We pushed SAST and SCA into GitHub Actions for 38 services last month, and the noisy findings are slowing merges. If you’ve dialed in Semgrep, CodeQL, or Snyk to block only issues with real exploit paths — tied to data classification or internet exposure — what signals reduced risk without killing delivery speed? I need something we can defend in audit while keeping MTTR tight.
One thing that worked for us: add a tiny ‘risk labeler’ step in Actions that reads service.yaml (data class + ‘internet_exposed’ flag) and tags the PR, then set Semgrep/CodeQL to block only on reachable findings introduced-in-diff when label=high and otherwise just comment. That gave us an audit trail because the label + SARIF is archived with the run, and MTTR stayed flat since devs saw only new exploitable issues. Caveat: we ran a two‑week baseline to auto-suppress legacy noise so the first pass didn’t brick merges.