Notifications
Clear all
Topic starter
20/08/2026 5:40 pm
TL;DR: Traditional security gates are creating 40-60% longer lead times, while false positive rates in vulnerability pipelines can reach 97.5% and 81% of teams still ship vulnerable code knowingly, showing why developer friction has become a security problem, according to Pixee. The operational shift is away from blocking workflows and toward embedded guardrails that redirect developers to safer paths without turning security into a delivery bottleneck.
NHIMG editorial — based on content published by Pixee: The Guardrail Manifesto, Security for High-Velocity Engineering
By the numbers:
- Elite teams now deploy 973 times more frequently than low performers according to DORA's State of DevOps research.
- Traditional security gates can create 40-60% longer lead times from commit to production.
- False positive rates in vulnerability management pipelines can reach 97.5%.
Questions worth separating out
Q: What breaks when security gates are used in high-velocity CI/CD pipelines?
A: Security gates break down when release speed is higher than human review capacity.
Q: When should teams keep a gate instead of replacing it with a guardrail?
A: Keep a gate when regulation, auditability, or high-impact change requires explicit approval before deployment.
Q: How do you know whether a security automation control is actually working?
A: Look at whether the control reduces exploitability and improves merge rates, not just whether it increases alert volume.
Practitioner guidance
- Map every security checkpoint in your delivery pipeline Classify each control as either a gate that blocks progress or a guardrail that redirects the workflow toward a safer default.
- Introduce context-aware remediation for code and dependencies Prioritise controls that evaluate reachability, environment, and authentication boundaries before raising or fixing findings.
- Measure security by merge rate and remediation speed Track whether automated security pull requests are actually being merged, because a low merge rate usually means the automation is acting like a gate.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- Concrete CI/CD examples showing how guardrails redirect developer workflows instead of blocking them
- Implementation patterns for policy as code, automated triage, and pull request based remediation
- Metrics for comparing merge rate, false positives, and remediation speed across pipeline controls
- Exception handling patterns for the cases where a manual gate still has to remain
👉 Read Pixee's analysis of security guardrails for high-velocity engineering →
Security guardrails in CI/CD , are your controls keeping up?
Explore further
20/08/2026 6:24 pm
Security guardrails are becoming the only scalable control model for high-velocity engineering. Blocking workflows does not map well to modern software delivery, where code changes, dependency updates, and deployment decisions happen continuously. The article correctly identifies that the real problem is not insufficient security intent but the wrong control shape. For identity and NHI governance, this is the same lesson that appears in access lifecycle management: controls that depend on slow human review will lose to systems that change faster than review cycles. The practical conclusion is that security must be encoded into the platform, not appended to it.
A question worth separating out:
Q: How should security teams govern guardrails in developer platforms?
A: They should treat guardrails as shared platform controls, with security and platform engineering jointly owning policy, exceptions, and observability. The aim is to make secure behaviour the default in golden paths, while reserving manual approval for the few cases where automation cannot judge risk well enough.
👉 Read our full editorial: Security guardrails in CI/CD: why gates no longer scale
