Governance
Configure fix approvals, protected paths, and account settings in one place.
Security commentary
Reachable Doesn’t Mean Exploitable
Use a chain of explicit conditions to distinguish a code path from a demonstrated security impact.
A path is evidence, not the complete verdict
A function can be reachable without every prerequisite for an exploit being satisfied. A vulnerable parser may receive only a fixed internal format. A dangerous operation may be behind an effective permission check. Conversely, an unfamiliar execution path can create exposure even when a familiar web request cannot reach the code directly. Reachability narrows an investigation, but it does not by itself prove either practical exploitability or safety.
Describe the finding as a chain of conditions: a relevant component is deployed, an attacker can influence an input, the input reaches the vulnerable behaviour and the behaviour produces a security consequence. Each condition should have evidence or an explicit unknown state.
Separate facts from assumptions
A source location can show that a function is called. It may not show whether a production feature flag is enabled or which identity supplies the data. A repository configuration file can be stale or overridden at deployment. Record where each fact came from and how it maps to the environment being assessed. Do not silently convert a missing configuration value into the most convenient assumption.
Use a small evidence table during review. For each prerequisite, name the observation, its source and its freshness. If an external control such as a gateway rule is relevant, capture the actual configured rule and the traffic path it protects. The mere presence of a security product does not establish that it blocks the specific behaviour under discussion.
Validate the security property safely
When authorised testing can resolve an important uncertainty, choose the least disruptive test that answers the question. For an access-control issue, create separate test identities with known permissions and synthetic records. Compare an allowed operation with an operation that should be rejected. For a parsing issue, use a bounded fixture in an isolated process. Preserve the request, response and environment details without collecting unrelated customer data.
A failed test needs interpretation. It may reflect a fixed build, a missing prerequisite, an ineffective test or a tool failure. Report the actual observation and the remaining hypotheses. “Not reproduced” is useful evidence when its conditions are clear; it is misleading when presented as an unconditional statement that no issue exists.
Turn the conclusion into a maintained decision
A useful remediation decision combines likely impact, exposure, confidence and the cost of repair. Sometimes updating a dependency is simpler than proving that every vulnerable path is unreachable. In other cases, a carefully scoped investigation can prevent a disruptive change made for the wrong reason. Document the tradeoff and assign an owner who can reconsider it when the deployment changes.
Retest after the fix and retain a regression check for the specific boundary. Also identify what would invalidate an accepted-risk decision: a new input source, a permission change, a feature rollout or a different package build. Exploitability is a conclusion about a system under stated conditions. Keeping those conditions visible makes the conclusion useful to future engineers instead of turning it into a stale label.
