the agent said "not reachable" but the vulnerable code path was behind a feature flag it never evaluated

TL;DR: "Not reachable" is wrong the moment the code path exists behind a flag the check never read. List every flag and build tag that gates the vulnerable code, look up their actual production values, and default to reachable for any flag you cannot prove is off.

the agent said "not reachable" but the vulnerable code path was behind a feature flag it never evaluated

Steps

1. Find what gates the vulnerable code: search the codebase for the feature flag name, build tags, or config keys around the vulnerable function and its callers.

Expected: a concrete list of flags and tags that control whether the path executes.

1. Look up each flag's production value: the deployed config, the flag service's current rollout state, the build tags used for the production binary.

Expected: a yes or no per flag for "this is on in production."

1. If any gating flag is on (or in gradual rollout) in production, the path is reachable - update the verdict and document which flag enables it.

Expected: the verdict matches reality instead of the default-off assumption.

1. If a flag's production value cannot be determined, mark the finding "unknown" and note the unevaluated flag - never "not reachable."

Expected: uncertainty is explicit and has an owner assigned to resolve it.

1. Add flag enumeration to the reachability checklist: the agent must list gating flags and their values before it is allowed to emit "not reachable."

Expected: the next flag-gated path gets caught at analysis time, not in an incident review.

Use this when

• A "not reachable" verdict covered code behind a feature flag, build tag, or config switch
• The vulnerable path lives in an optional module, plugin, or experimental feature
• Flags are in gradual rollout - the path is reachable for some percentage of traffic
• Your reachability tool analyzes code but never reads configuration

Not for this skill when

• The flag is provably off in every production deployment and cannot be turned on without a deploy - document the value and the verdict stands
• The code path is dead for a structural reason (no caller exists at all) - that is a genuine "not reachable," flag or no flag
• You are analyzing a library, not a deployed service - flag state belongs to the consumer; report the gating flag so they can evaluate it

Variant phrasings

• feature flag bypassed vulnerability reachability check
• vulnerable code behind launch flag marked not reachable
• how to handle feature-flagged code in CVE triage

Why it happens

Reachability tools read code, not configuration. A static call graph sees the flag check, cannot resolve its runtime value, and typically treats the gated branch as not taken - or the agent never notices the flag at all. Meanwhile production runs with the flag on. The analysis answered "is this code reachable in the abstract" while the real question was "is it reachable in the deployed configuration."

Edge cases

• Gradual rollouts mean "reachable for 5 percent of traffic" - that is reachable; note the percentage.
• Kill switches and emergency flags can flip at runtime - a flag that is off today may be on during an incident; note flags with operational toggles.
• Build tags are compile-time flags - verify against the actual production build's tags, not the repo default.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5DrB9jVKAOKBBGjFDGL7xw