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.
Editorial analysis by NHI Mgmt Group, based on content published by Pixee: “The Guardrail Manifesto: Security for High-Velocity Engineering”.
By the numbers:
- 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%.
Key questions
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: Why do generic vulnerability scanners create security friction in delivery pipelines?
A: Generic scanners create friction because they treat every finding as equally urgent, even when the code is unreachable or isolated from real data paths.
Q: How can organisations tell whether guardrails are actually working?
A: Measure more than block counts.
Practitioner guidance
- Adopt redirect-first security controls in CI/CD Replace default blocking checkpoints with automated substitutions, pull-request based remediation, and logged exception paths so the pipeline keeps moving while security remains enforceable.
- Move policy enforcement into the internal developer platform Embed secure defaults, policy as code, and remediation logic into the platform developers already use for service creation, deployment, and monitoring.
- Tune controls to reachability and environment context Prioritise alerts that are actually reachable in the running application and suppress findings that are isolated from sensitive data or execution paths.
Bottom line: Security gates no longer scale well in modern CI/CD because they add delay, amplify false positives, and push teams toward workarounds.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:24 pm
Security guardrails are becoming a governance problem, not just a tooling choice. Once CI/CD pipelines become the main operating layer for delivery, the question is no longer whether a team can scan code. The real question is whether security controls can operate at the same speed as automated build and deploy systems without being bypassed. Practitioners should treat guardrails as a control-plane design issue, not a point product decision.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between a CI/CD security gate and a guardrail?
A: A gate blocks progress until a condition is met, while a guardrail redirects the workflow toward a safer default and only escalates exceptions. Gates are useful for regulatory or high-risk approvals, but guardrails scale better for routine security decisions in automated delivery environments where speed and consistency matter.
👉 Read our full editorial: Security guardrails in CI/CD: why gates no longer scale