Beyond the Green Checkmark: Security IN and OF Your CI Pipeline

The talk starts from a familiar problem: security scanners wired into CI pipelines with default settings produce a flood of low-value findings, and developers learn to ignore them. Checks that report problems without failing a build add little real enforcement, so the security gates end up as theater.

On the code side, the speaker recommends differential scanning on pull requests so only new issues are reported, with tuned high-confidence rules for blocking gates and broader scheduled scans for the full backlog. Code quality findings are kept apart from security findings, generated code and minified files are excluded, and triage decisions are codified in configuration. Runtime validation with DAST and IAST, EPSS alongside CVSS, and policy as code using OPA with Rego, Checkov or Trivy catch misconfigurations before deployment, while manual code review covers logic flaws and intentional backdoors that tools miss.

For the pipeline itself, the talk covers poisoned pipeline execution in direct, indirect and public pull request forms, along with dependency confusion, typosquatting and mutable tags. Suggested defenses include centralized reusable workflows, two-person approval for CI changes, ephemeral runners, network segmentation, short-lived OIDC credentials, commit-hash pinning, SLSA provenance, and full-history secret scanning with rotation. The closing point is that tooling alone does not change culture, so developers need ownership of security findings.