A security control that systematically blocks the pipeline breeds systematic workarounds, not better security. This lesson explains why the punitive gate fails, how alert fatigue ends up hiding the real threats, and how to replace it with a guardrail that only blocks what is exploitable and gets the rest fixed. It is for anyone who designs or endures the security controls of a CI/CD, on the security side as well as on the development side.
What you will learn
- Explain why systematic blocking breeds workarounds
- Recognise the workaround spiral and alert fatigue
- Tell a gate from a guardrail, and know when blocking is still justified
- Make an alert useful through context, priority and deadline
- Choose metrics that measure outcomes, not activity
A scenario many teams will recognise
Take a security team that, after months of effort, adds a blocking vulnerability scanner to every pipeline. The result is immediate: most builds fail, developers can no longer ship, tickets pile up and the pressure rises.
Two weeks later, a "temporary exception" is granted to the priority project, then another. Six months on, half the projects live under exception, and the teams have learned to mark findings as ignored to get the build through. The scanner still runs, but nobody reads its results any more. Displayed security went up, real security went down.
Why does the security gate fail?
The idea looks watertight: if the pipeline fails whenever there is a security issue, no issue reaches production. In practice, four forces make it fail, and they act together. Volume first: a modern scanner reports dozens, sometimes hundreds of findings per project, far more than the team can triage.
Noise next. In the Black Duck Global State of DevSecOps 2024 report, which surveyed more than 1,000 professionals, 60% of respondents estimate that between 21% and 60% of their security test results are noise: false positives, duplicates or conflicts. Blocking a build over a false positive is perceived, rightly, as an unfair punishment.
Context is missing too: a scanner does not know whether the vulnerable function is called, or whether the component is exposed to the network. Finally, delivery pressure does not vanish because the pipeline is red: it shifts onto the workaround. The same report measures the perceived effect: 86% of respondents feel that security testing slows development down, 18% of them severely.
The workaround spiral
When a control blocks without support, teams develop workaround strategies, visible at first, then more and more discreet. Explicit workarounds show up in the tools and tickets; the table gives the common forms, with the justification that almost always comes with them.
| Technique | Apparent justification |
|---|---|
| Ask for a "temporary" exception | "We'll fix it after the release" |
| Disable the scan on a project | "It's an internal project, not critical" |
| Mark alerts as ignored | "It's a false positive, we'll check" |
| Merge before the scan ends | "The scan is too slow" |
Implicit workarounds
More insidious, implicit workarounds change behaviour without touching the controls. A team for which every dependency update triggers new alerts stops updating: the debt piles up silently. Another stacks its changes into massive commits to go through the scan less often, and those commits become harder to review and to debug.
The vicious circle closes like this: the control blocks too often, teams bypass it, it becomes ineffective, the security team adds controls, and the workarounds grow more sophisticated. It is an arms race between security and development, from which both sides come out exhausted without real security making progress.
What is alert fatigue?
Alert fatigue sets in when the volume of alerts durably exceeds the processing capacity: every alert ends up ignored, critical ones included. At first, each alert is examined; then the flow never dries up, old ones pile up, and the team adopts mental shortcuts: "this library always produces false positives", "medium ones can wait", "it's the usual kind of alert".
One day, a critical alert slips by because it looked like the hundreds of others. That is the paradox of the sensitive scanner: the more findings a scanner reports, the less seriously each one is taken. A very sensitive setting can therefore reduce effective security, by drowning the real problems in the noise.
Gate or guardrail: what is the difference?
A gate blocks as long as the rule is not met, without nuance; a guardrail flags the danger, suggests the fix, and only blocks the critical cases. The gate reassures through its clarity, but it hands responsibility over to an automated system and pushes towards workarounds. The guardrail leaves the decision to the team, informed of the real risk.
The table compares the two postures on five aspects. Read the last two rows above all: the effect on behaviour and the long-term result are what separates the two models, far more than the default response.
| Aspect | Gate | Guardrail |
|---|---|---|
| Default response | Block | Inform |
| Posture | Punitive | Enabling |
| Responsibility | System | Team |
| Effect on behaviour | Workarounds | Learning |
| Long-term result | Arms race | Lasting improvement |
How do you make a control enabling?
An enabling approach does not drop the controls: it designs them to help teams do better, rather than to punish them when they do badly. Four levers lead there, and the first one is prioritisation.
Block only what is exploitable
Not all issues are equal: a critical vulnerability in a function exposed to the network does not have the impact of a medium vulnerability in a test dependency. A graduated policy blocks only what is critical and exploitable, alerts on what is important with a fix deadline, and informs on what is minor without blocking. Blocking thus keeps its credibility.
Give each alert its context
An alert "CVE in libfoo" helps nobody. A useful alert says why it is a problem, whether the vulnerable function is actually used here, how to fix it (fixed version, workaround) and within which deadline. Exploitability data such as VEX exists precisely to rule out what does not apply.
Detect early, when fixing is cheap
Finding 200 vulnerabilities at deployment time is paralysing; finding 2 during development is manageable. Shift-left moves detection to the IDE, the commit and the opening of the pull request, where fixing is fastest. It still needs support: detecting early without helping to fix only moves the problem.
Support rather than punish
When a team has a recurring security problem, the right answer is not one more blocking control, but the cause: does the team have the skills, do the tools make fixing easy, do its priorities leave it the time, is the existing debt too heavy to handle without help? The reasons why security fails are often organisational before being technical.
Which metrics should you track?
A bad metric encourages bad behaviour, often the very one it meant to avoid. Counting detected vulnerabilities pushes towards using fewer libraries or scanning less; counting exceptions pushes people to stop asking for help. The table matches each activity metric with the useful behaviour it discourages.
| Activity metric | Useful behaviour it discourages |
|---|---|
| Number of vulnerabilities detected | Scanning more, adding sources |
| Pipeline blocking time | Taking the time to fix properly |
| Number of exceptions granted | Asking for help when needed |
Good metrics measure outcomes: the mean time to fix critical vulnerabilities, the share of projects with up-to-date dependencies, incidents detected early. The lesson DORA metrics shows how to measure delivery performance without sacrificing security.
What does a healthy security culture look like?
Organisations where security works are not those with the strictest controls, but those where it is part of the culture. Developers there ask for security reviews instead of enduring them, the security team is seen as an ally, and an incident is a chance to learn rather than to blame someone.
You get there through concrete steps: involving developers in choosing and tuning the tools, celebrating a fix as much as a feature, making visible what security prevented, and reducing the friction of each step. A fast feedback loop is what makes these steps effective.
Key points
- A gate that blocks systematically breeds systematic workarounds: displayed security hides a declining real security.
- Noise is massive: 60% of respondents to the Black Duck 2024 report estimate that between 21% and 60% of their results are not real problems.
- Alert fatigue makes people ignore every alert, critical ones included.
- The guardrail informs, gives context, and only blocks what is exploitable.
- Detecting early only helps if you also help to fix.
- Good metrics measure outcomes, time to fix and incidents avoided, not alerts generated or builds blocked.
Knowledge check
Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Source code governance: rulesets, tags and CODEOWNERS
Continue the course: From SLSA provenance to decision: blocking non-compliant artifacts
A new full quiz with random questions
Work again only on the questions you missed