Yes. A work in progress limit caps how many security fixes can be open at once, so engineers finish before they start. Teams usually close more fixes, hit fewer stalls, and see blockers sooner. Start low, review weekly, and keep one lane open for true emergencies.
What a WIP limit is
Kanban treats every item between a started point and a finished point as work in progress. Its two primary practices are to visualize work and to limit that work in progress. Limiting WIP encourages focus, reduces multitasking and makes blockers visible, according to one widely used team guide (see Sources).
For a security queue, the started point might be "assigned and being worked" and the finished point "fix deployed and verified." Everything in between counts.
Security backlogs tend to grow by interruption. A new advisory arrives, an engineer picks it up, then gets pulled away, and the half-done fix sits waiting for review. Ten fixes each at 70 percent do more for the dashboard than for the risk. Nothing has shipped.
A limit changes the question from "what should I start?" to "what is blocking something I already started?" That is usually the more valuable question.
How to set the first limit
- Count how many people work on security fixes in a typical week, including part-timers.
- Set the limit near that headcount, not above it. A common starting point is about one open fix per person.
- Run it for two weeks and note how often the board hits the limit.
- Adjust. If the limit is never reached it is too high. If it blocks work for days at a time, look at why items are stuck instead of raising the number at once.
Do not copy another team's figure. The right limit depends on how long a fix takes to review and ship in your pipeline.
Columns worth limiting
| Column | Why limit it |
|---|---|
| In progress | Prevents multitasking |
| In review | Stops pull requests piling up for a few reviewers |
| Waiting on another team | Makes dependencies visible and forces escalation |
The review column is where many queues choke. If it fills, the rule is simple: reviewers review before anyone starts a new fix.
Handle emergencies without breaking the rule
Create an expedite lane with its own tiny limit, usually one. Define in advance what qualifies, for example a vulnerability on a known exploited list that is reachable on an internet facing service. Anything else waits its turn. Write the criteria down so the lane does not become the default path.
When an expedite item enters, say out loud which in-progress item pauses. Silent context switching is how limits die.
Measure what changes
Track two things: how long a fix takes from start to deployed, and how many items finish each week. If the limit works, the first tends to fall and the second stays flat or rises. Both numbers connect through queueing math, covered in Little's law for vulnerability backlogs.
A WIP limit works on any board. Safeguard's policies and gates can keep new vulnerable code from entering while the queue drains, and its fix pull requests, which are off by default, arrive as reviewable changes that count against the review column like any other.
Quick check
Will a WIP limit slow down security work?
It slows the starting of work, not the finishing. Most teams find that completed fixes per week stay level or rise because less time is lost to switching.
What if every item is urgent?
Then the expedite criteria are too loose. Tighten them to a short written list, and send everything else through the normal limit.
Sources
Last reviewed: 19 October 2026.
