It depends on exposure and timing. A low risk fix can ride the next scheduled train if that train departs soon. A fix for a vulnerability that is reachable in your shipped frontend should use a fast lane, with the same tests but outside the calendar. Decide by risk, then document the choice.
Why release trains exist
A release train ships on a fixed schedule, for example every two weeks, and whatever is ready goes. The benefit is predictability: design, QA, support and consuming teams know when changes land. For a large frontend with a shared component library, that rhythm keeps dozens of teams in step.
The cost shows up when a security update arrives mid cycle. Waiting costs days of exposure. Skipping the train costs coordination. The answer is to plan for both.
A decision table
| Situation | Suggested path |
|---|---|
| Vulnerable code is not loaded in any shipped bundle | Next train, record why |
| Vulnerable code is shipped but not reachable from user input | Next train if it departs within your fix window |
| Reachable, or listed as exploited by a credible source | Fast lane, ship out of cycle |
| No fix exists yet | Mitigate and watch, see emergency mitigation when no patch exists |
| Fix is a major version that touches many components | Fast lane for a minimal patch if possible, train for the full upgrade |
Your fix window should come from your own written policy, with a target per severity. Do not invent a number in the middle of an incident.
What a fast lane needs
- A named approver who can declare an out of cycle release.
- The same checks, run faster. Unit tests, visual tests, and a dependency scan still run. The lane skips scheduling, not testing.
- A narrow change. Only the dependency bump and any required adjustments, no feature work.
- A rollback plan written before the release, as in rollback plan for an emergency patch.
- A note to consuming teams saying what changed and which version to take.
How this works for a design system
A shared library is released to apps, and each app then deploys on its own train. That means two clocks run: yours and theirs. Publish the library patch quickly, then give app teams a deadline to adopt. The pattern for splitting ownership is in who fixes a vulnerable internal shared library.
Be honest in the ticket about which clock you are waiting on. "Library patched on Tuesday, three apps still on the old version" is a more useful status than "fixed".
Record the decision
Whichever path you choose, write one line: which vulnerability, what exposure, which lane, who decided. Auditors and later you will both want it. Whether scans pause during a freeze is a separate question, answered in do vulnerability scans pause during a release freeze.
Safeguard's reachability analysis helps with the first two rows of the table by showing whether vulnerable code is actually called, and policies can set different handling by severity. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how filtering to reachable findings changes which fixes need a fast lane.
Quick check
Is a fast lane the same as skipping QA?
No. It skips the wait for the scheduled date, not the tests or the review.
Who decides a fix is urgent?
Name one role in advance, such as the engineering manager on call, so the decision is not debated during the incident.
Last reviewed: 19 October 2026.
