IaC Security Dilemma: Checkov/Trivy in CI/CD vs. AWS Config in Runtime
Static IaC scanning catches misconfigurations early, while AWS Config detects manual console drift in runtime. Where should engineering teams draw the line to prevent alert fatigue without risking production?
Hey builders! 👋
Lately, I’ve been reflecting on how we approach DevSecOps across our deployment pipelines and cloud accounts. Every team wants secure infrastructure by default, but in practice, finding the sweet spot between developer velocity and security controls can be tricky.
From my perspective, this friction usually surfaces in two places: blocking builds in CI/CD versus monitoring live resources directly in AWS.
Here is my take on both sides:
Shift Left: Scanning code in CI/CD (Checkov, Trivy)
In my opinion, catching things early before
terraform apply is ideal because you prevent vulnerable resources from ever being created.However, being completely honest: alert fatigue is very real. I’ve seen teams get frustrated when a build fails over a default S3 bucket rule because it didn't use a custom KMS key, even when standard encryption was completely fine for that environment. When developers start adding bypass comments just to push urgent releases, we have a cultural problem.
Runtime Governance: Auditing in AWS (AWS Config, Security Hub)
On the other hand, relying on AWS Config and Security Hub gives you the actual source of truth. It catches that emergency manual fix made directly in the AWS Console that bypassed Git entirely (drift).
The catch? At scale, AWS Config rule evaluations can drive up AWS bills quickly. Plus, automated remediation scripts can feel risky if you aren't 100% confident they won't disrupt live production traffic.
Where I stand
I personally believe neither approach works well in isolation:
- Pure static scanning without runtime context can lead to developer fatigue and missed console changes.
- Pure runtime detection means you are constantly reacting after something insecure is already live.
What do you think?
I’d love to hear how your teams handle this balance:
- Do you hard-fail pipelines on High/Critical findings, or do you treat them as non-blocking warnings to keep releases moving?
- Which scanner gave you the least noise and easiest setup: Checkov, Trivy, or custom rules?
- Do you trust auto-remediation in runtime, or do you prefer routing drift alerts to tickets/PRs?
Looking forward to your thoughts and real-world setups in the comments!
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article