When code looks vulnerable but you do not know how it is deployed, split the judgment into two parts: what the source supports and whether the suspected path exists in the selected environment. Record the missing deployment fact as an owned investigation with a specific artifact to obtain. Do not turn uncertainty into “not exploitable,” and do not report a production vulnerability from a route that might never be exposed. If plausible harm is high, a service owner can take a temporary precaution while the evidence is gathered; the finding's verification status remains honest.
Deployment context can change the actor, entry point, controls and practical difficulty. A gateway policy, private network boundary, feature flag, different artifact or scheduled-only caller may change a source-level claim. OWASP's Web Security Testing Guide on mapping application architecture explains that understanding the infrastructure and its interacting components is necessary for meaningful assessment.
Separate two axes before scoring
Draw a small matrix for the precise path:
| Source path | Deployment path | Defensible conclusion |
|---|---|---|
| Supported | Confirmed in the selected environment | Continue independent control/effect verification; the route is applicable. |
| Supported | Unknown | Keep an investigation and request deployment evidence. Describe possible impact conditionally. |
| Supported | Confirmed absent from the selected environment | Do not claim current exposure there. Preserve the code concern for a future deployment or another environment if relevant. |
| Defeated by a checked control | Control confirmed in the selected deployment | Reject or narrow the original claim for that revision and environment; a different build or policy needs its own check. |
| Defeated by a checked control | Whether the control runs is unknown | Confirm the effective build and policy before rejecting a production claim. |
| Unknown because source is incomplete | Any | Request the missing source or policy and state what was actually reviewed. |
“Private” is not a synonym for safe: internal users, compromised workloads and service credentials may still reach a route, depending on its actual policy. Conversely, a public-looking handler in a repository is not automatically a production endpoint. Decide with the deployed artifact and routing evidence, not a filename such as “internal” or a developer's recollection.
Illustrative case: a diagnostics export of customer reports
All organizations, paths and evidence records here are fictional. Cedar Metrics has a handler named “report snapshot” that reads customer usage reports and writes an export. At revision MNO345, the handler does not appear to check a user role. A scanner calls it “unauthenticated data export.” The source reviewer can follow the handler to a sensitive read and export operation. They cannot find a route mapping or the effective gateway policy for the environment under review.
The initial report should not say “any internet user can download all customer reports.” That requires evidence that the route is reachable from the internet, that no upstream or downstream check applies, and that the output returns to such a user. The useful interim statement is:
At MNO345, the report-snapshot handler performs a sensitive export without an authorization check visible in the inspected handler or export service. Its production entry point and upstream access policy are unverified. If an untrusted caller can invoke this handler through the deployed route, customer report data may be exposed.
Now ask for the smallest decisive set of artifacts. Do not send an unbounded request for “the whole infrastructure”:
| Question | Artifact and owner | What it settles |
|---|---|---|
| Is this exact code deployed? | Immutable build/artifact digest and deployment record from the release owner | Whether MNO345 describes the running function |
| What invokes it? | Effective gateway/route map and scheduled trigger configuration from the platform owner | Whether a human request, internal job or both can enter |
| Who can invoke each entry? | Gateway authorizer policy, service-to-service grant and runtime configuration from the policy owner | The actor and required privileges |
| Is there a later check? | Export service policy and delivery configuration from the application owner | Whether the data read or download is independently denied |
| Where does output go? | Export destination and retrieval policy from the data owner | Whether the alleged actor can actually obtain the report |
Resolve conflicting deployment evidence
Continue Cedar's constructed case with three supplied artifacts. Their timestamps are illustrative and describe an exercise, not inspected infrastructure:
| Artifact | What it says | What it can support |
|---|---|---|
| Architecture drawing, 2 October | “Snapshot export is scheduler-only.” | The intended design at that date; not the current route inventory. |
| Source manifest at MNO345 | Defines an optional /diagnostics/snapshot route. |
The build can include a human entry; not that this option is enabled. |
| Effective release record, 18 October | Artifact MNO345; diagnostics flag off; scheduler trigger on; invocation grant names only the scheduler identity; export destination restricted to the operations service. | Applicability and recipient for this specified release, provided the record is authoritative and complete for direct invocation too. |
The old drawing and optional route do not need to be reconciled by choosing whichever supports the preferred conclusion. The effective release record supplies the missing distinction between available code and enabled entry. On these stated facts, close the anonymous internet export claim for the assessed release: neither the actor's invocation nor receipt of the output is supported. Preserve the scheduler's scope for a separate review. A compromised scheduler identity is a different actor, and a broad export under that identity needs its own authorization analysis.
The final note can be brief:
MNO345 contains the export operation, but release R18 does not enable its HTTP entry. The active invocation grant and restricted output destination defeat the alleged anonymous request-to-download path. This decision covers R18 only. Reopen before enabling the diagnostics flag, changing an invocation grant or adding a report retrieval route.
Now change just one artifact: suppose the release record names MNO344 while the source review covers MNO345. The matrix returns to deployment unknown. A recent timestamp does not repair a revision mismatch. Request the running artifact's source or a trustworthy build-to-source mapping; do not copy R18's conclusion onto another build.
The practical result is an evidence request small enough to answer: “Supply the effective route, invocation and output policies tied to the actual export artifact.” It replaces both the speculative production finding and the equally speculative assurance that an internal filename makes the code unreachable.
Time-box the unknown without manufacturing a verdict
Use an evidence request with four fields:
- Missing fact: Is report snapshot callable by an ordinary customer in the production environment using the selected artifact?
- Requested proof: artifact digest, effective route map and authorization policy, with configuration version or timestamp.
- Owner and check date: platform lead, next business day.
- Interim action: review whether the route can be restricted or disabled without disrupting the scheduled export; notify the data owner of the conditional exposure.
The date is a case-specific example, not a universal service-level target. A team may choose a shorter interval for more consequential possibilities or an incident response process for credible active harm. Keep the interim action separate from a verified vulnerability count. An emergency restriction can be prudent even if later evidence defeats the suspected path.
If the platform team cannot provide a route map, record that as a visibility gap rather than marking the issue false. If the environment changed during review, bind each statement to the artifact and configuration that were current when checked. If several regions or tenants use different routes, assess them separately. Avoid inferring that a successful request in staging proves the same production mapping.
Revisit severity only after the path is defined
Severity and priority should reflect the facts of the selected environment, not substitute for them. FIRST's CVSS v4.0 specification distinguishes Base, Threat and Environmental metrics; Environmental metrics can account for deployment-specific conditions and controls. They are useful when the environment is known. Filling an unknown gateway policy with a favorable Environmental assumption makes the score look precise while the core fact is missing.
Keep a separate note for likely impact and practical exploitation difficulty. In Cedar, the report data may be sensitive, but attacker access is still unknown. “High potential impact; access prerequisite unresolved” is clearer than either “critical internet exposure” or “low because internal.” A score, if required by local policy, should identify the assumptions and be revisited when the route evidence arrives.
The close-or-continue decision
At the next check, choose one branch:
- Applicable path confirmed: trace actor → entry → gateway/service controls → export → recipient at the exact deployed versions. Seek independent verification before publishing a vulnerability.
- Path absent or blocked: reject the original production claim with the artifact and control that defeat it. Record any separate hardening issue without inheriting the original severity.
- Still unknown: keep the investigation open with the unanswered artifact, owner and next review point. Do not describe the code as “safe” because time ran out.
- Credible urgent risk: use the organization's incident or containment channel, clearly labeled as a suspected exposure while the factual review proceeds.
The OWASP reporting chapter recommends documenting assessment scope and limitations. Do that in the finding itself, where a ticket reader will see it, not only in an appendix. A missed route, unknown feature flag or absent deployment record changes the conclusion.
Preserve context when the environment changes during review
Deployment evidence has a useful lifetime. Cedar's platform owner may supply a correct release record on Monday and deploy a replacement on Tuesday while the analyst is still reviewing the old packet. The answer is not to erase Monday's work. Keep the conclusion tied to R18 and identify which facts the new release could invalidate: the code artifact, diagnostics flag, invocation grant, trigger and output destination.
Ask for a change comparison across those facts. If R19 changes only an unrelated display setting and the owner can establish that the export's effective configuration is identical, the earlier evidence may remain useful with that continuity recorded. If R19 changes the invocation grant, recheck that boundary even when the source revision is unchanged. An immutable source reference is essential but cannot freeze permissions outside the source repository.
A practical release handoff for Cedar could read:
R18's anonymous export allegation was rejected because its HTTP entry was disabled and its scheduler output was restricted. R19 keeps the same export code but changes the trigger configuration. Platform must identify the effective callers and recipient policy for R19. The R18 decision remains historical evidence; R19 applicability is pending.
This wording prevents two common mistakes. The reviewer does not reopen every unrelated source question automatically, and the release owner does not inherit an old exposure conclusion merely because the handler file is unchanged. The work follows changed assumptions.
For several environments, use one row per materially different configuration. A customer-dedicated deployment with a different diagnostics setting should not disappear inside a single “production” label. Conversely, avoid inventing separate investigations for deployments that are demonstrably equivalent for the relevant path. The useful unit is the combination of artifact and effective controls that determines who can invoke the export and receive its result.
When records are incomplete, state the bounded gap: “Invocation policy known for R18 in environment A; environment B not supplied.” This tells the business owner exactly where precaution or further investigation is needed. It also preserves the value of the review already completed instead of presenting partial knowledge as either total assurance or total ignorance.
For the next ambiguous alert, fill the source/deployment matrix and request one decisive artifact before setting a final verdict. documenting uncertainty offers a reusable note format. If the disputed control is middleware, use accounting for middleware in an authorization alert.