Sometimes. A feature flag makes a vulnerable dependency safer to ship only when turning the flag off stops the vulnerable code from loading or running, and when an attacker cannot reach that code another way. If the library is still imported and its function is still callable, the flag is a delay, not a fix.
What a flag actually changes
A flag controls which product path a user takes. A vulnerability lives in a library function. The two only line up if the flagged feature is the sole caller of that function.
Three situations come up again and again:
| Situation | Does the flag help? |
|---|---|
| The library is only imported inside the flagged module | Often yes, if the module never loads when the flag is off |
| The library is imported at startup for other features | No, the vulnerable code is present and may be reachable |
| The flag hides a UI button but the API endpoint still exists | No, attackers call the API directly |
The third row is the common trap. Hiding a button is a design choice. Removing the route is a security control.
How to test the claim in an hour
Ask engineering to answer four questions in writing before you accept the flag as a mitigation.
- Which function in the library is vulnerable, according to the advisory?
- Which of our code paths call that function, and does every one sit behind the flag?
- With the flag off, is the library still loaded into the running process?
- Can any request reach those code paths with the flag off, including internal services and background jobs?
Reachability analysis answers question 2 faster than reading code by hand, because it traces call paths from your code to the vulnerable function. OpenVEX, a machine readable format for exploitability statements, has a matching justification: vulnerable_code_not_in_execute_path, meaning the vulnerable code is included but cannot be executed by the product. That is a better description of a successful flag than "mitigated".
Write down what the flag is
Record the decision so it does not rot. A short entry is enough:
- the advisory or CVE identifier
- the flag name and its default state in production
- who verified the call paths, and on what date
- the date the real fix ships
- who removes the flag afterwards
Flags that nobody removes become permanent, undocumented behavior. Put the removal in the same ticket as the upgrade.
When not to rely on a flag
Do not lean on a flag when the advisory lists the vulnerability as exploited in the wild. CISA's Known Exploited Vulnerabilities catalog is described by CISA as an input to vulnerability management prioritization. A listing there is a strong reason to patch rather than to hide a feature. Do not rely on a flag either when the vulnerable library parses untrusted input at the edge of your system, because that path is usually shared by many features.
Try it yourself
Click through it at your own pace, or open it full screen.
Walk through a finding and look for how the demo separates "the component is present" from "the vulnerable code can be reached". That is the same split you need before calling a flag a mitigation.
Quick check
Is a flag defaulted to off enough?
Only if the vulnerable library is not loaded and its functions cannot be called with the flag off. Check the running process and the API surface, not the UI.
Who should approve a flag as a mitigation?
The engineer who owns the code path and a security reviewer, with the decision recorded and a fix date attached.
How long can a flag stand in for a fix?
Set an expiry when you record it. Treat it as a short bridge to the upgrade, not a resolution.
Safeguard's reachability analysis and free scan at gold.safeguard.sh/scan can show whether a vulnerable function is on a call path in your code.
Sources
Last reviewed: 19 October 2026.
