If you cannot establish whether an affected service is reachable from the internet, record exposure as unknown and assign a time-bound check. Do not quietly treat it as internal, and do not announce confirmed public exposure. Make a provisional priority from the credible harm, attacker prerequisites, available controls and the cost of waiting for the exposure answer. If the potential effect is serious and a public path is plausible, take a reversible protective step while the owner checks the deployment. Once you have evidence, revise the priority and preserve the earlier decision.
That separation matters because “the code has a route” and “anyone on the internet can call it” are different claims. CVSS v4.0 distinguishes the attack vector and attack requirements from impact, and allows environmental information to refine a base assessment. Its score communicates vulnerability characteristics; your deployment-specific work decision needs additional facts.
Define the question before collecting more data
Ask: Which actor can reach which entry point in the deployed version, under which conditions? “The admin API is private” may describe intent while an old public gateway mapping remains. A public DNS record, meanwhile, may lead to a route blocked by an effective identity gate. Reachability is the actor's path to the operation, not a hostname label.
Write down four distinct facts:
- Affected behavior. What does the source-supported flaw permit if reached? Identify the input, missing or bypassed control, and harmful effect. If that chain is unverified, this is still a candidate claim.
- Deployment. Is the affected revision and route present in a live environment? Name the artifact, service, environment and date of the evidence.
- Entry. What network route and identity condition must an actor satisfy? Consider gateway routes, load balancers, firewall rules, VPN, service mesh and delegated service calls.
- Control. Which check would stop the action even if a request arrived? Record evidence of the check actually being enforced on this path.
Do not collapse these into “external: yes/no.” A private network may still expose a flaw to a compromised workstation, partner or customer account.
An illustrative case: the export endpoint
Constructed example; no live exploit or operational action was performed. Northstar's report handler accepts an account ID and returns that account's report after login without an account-bound permission check. For this exercise, the handler, downstream service and storage path have been independently approved as a bounded defect. The affected build is deployed. Only its internet entry remains unresolved: the architecture drawing says internal, while an older public gateway template includes /exports.
The question is therefore which actors can reach this known defect, not whether the downstream check exists. Platform owns the effective ingress map and identity policy, due at 14:00. The export owner identifies the intended workflows: customer downloads are configured to use the disputed route, but whether that mapping is active remains unconfirmed; scheduled finance exports use a separate service path. Both invoke the defective service, so restricting the customer route reduces one exposure without repairing the shared defect.
| Interim option | Operational cost | What it establishes |
|---|---|---|
| Pause all exports | Interrupt customer downloads and scheduled finance work. | Broad containment only if every invocation path is covered; still not a source fix. |
| Restrict the disputed route | Interrupt customer downloads; preserve the separately bounded finance workflow. | Removes the plausible customer entry if the effective restriction is verified. |
| Wait for ingress evidence | No immediate disruption. | Leaves the possible public path available until the answer arrives. |
The decision owner chooses the route restriction because it addresses the credible customer entry with the smaller known interruption. Platform verifies that requests to the exact route are denied through the active gateway and no direct bypass exists within the checked scope. These are stipulated exercise facts, not claimed test results. The restriction has a 14:00 review point, an export-owner rollback procedure and a customer-support notice owned by operations.
Use a four-state exposure rubric
Use this rubric to avoid inventing certainty:
| State | Minimum evidence | Priority consequence |
|---|---|---|
| Confirmed public path | Live route and access policy show an internet actor can reach the affected operation under stated credentials; the affected artifact is deployed | Treat public reach as supported. Investigate controls and harm immediately; do not assume exploit success. |
| Plausible public path | An active public entry exists, but route binding, deployment version or enforcement is not established | Set a short evidence deadline and a provisional priority based on credible harm. Consider reversible containment. |
| Unknown | Inventory or deployment evidence is missing or contradictory | Keep exposure unknown. Name the evidence owner and deadline; do not turn silence into “internal.” |
| Confirmed bounded path | Current deployed route and enforceable network/identity controls restrict the actor, and alternate paths were checked to a stated scope | Re-rank for the actual actor, while keeping the underlying defect open if it remains. Recheck when the deployment changes. |
These states describe exposure evidence, not whether a vulnerability is verified. A false source claim with a public route remains false. A verified flaw behind an internal-only path still deserves a fix decision, especially if an insider or compromised service can trigger it.
Carry the temporary decision through the answer
At 14:00 the evidence can produce two different completed updates:
| Supplied result | Priority update | Service-restoration decision |
|---|---|---|
| Current routing restricts the service to nominated finance identities; the old public mapping is absent. | Retain the approved defect, rank it for the actual internal actor and schedule the account-bound correction. Public exposure claim is rejected for this deployment. | Remove the emergency customer-route restriction only after confirming the normal routing restores no unauthorized entry. Scheduled finance operation remains governed by its existing checked boundary. |
| Public mapping is active and accepts ordinary customer sessions. | Public applicability is confirmed; keep the defect at urgent priority and fund the correction. | Keep the restriction until the corrected artifact and account-bound behavior are verified; reopening because the patch merely merged is insufficient. |
If the mapping remains unavailable, preserve “unknown,” continue the restriction only under a renewed operational decision and assign the next evidence checkpoint. An expiry is a requirement to reconsider, not permission to automatically reopen an unsafe route.
The temporary decision record should state the cost as clearly as the security benefit: “The disputed customer-download route is disabled as a precaution; operations checks whether customers previously used it and provides an alternative if needed. Finance export remains available under the checked service boundary. Export owner restores downloads only after exposure is disproved or the deployed correction is verified.” That is more useful than “mitigated, monitoring.”
CISA's SSVC guidance treats response as contextual. Your local owner must decide how long a temporary service interruption is proportionate. For obtaining conflicting deployment artifacts, use the deployment-context guide; this decision record should concentrate on what the team does while waiting.
Ask for effective exposure evidence in a usable form
A platform response should bind the affected operation to its entry, not merely list firewall rules. For Northstar, ask for the route that reaches the export handler, the artifact behind that route, the required identity and any direct or delegated alternatives. A network policy without its attachment to the running service may be authentic while still irrelevant to the disputed path.
A concise evidence request can say:
For the current export artifact, identify every active entry in the assessed environment that can invoke the account-report operation. For each, state the eligible caller, the effective gateway or service policy, and the destination binding. Include the configuration version and the evidence date; identify anything outside the supplied inventory.
This is bounded enough for the owner to answer and broad enough to expose a second entry. If the scheduled finance path is intentionally retained, describe its authority separately. A checked customer-route block cannot establish the security of that service identity's broader access.
If an authorized controlled check is used, agree on what it can demonstrate. A denial from an unauthenticated request does not settle whether an ordinary customer session can reach the operation. A successful connection to the hostname does not establish that the vulnerable route is active. Use a harmless fixture and the actor described in the claim, then keep the observation tied to its environment and configuration.
Make restoration a deliberate operational step
Removing the precaution needs its own check because restoring the wrong routing state could reintroduce exposure. The export owner should know which normal configuration is being restored and why it is acceptable: either the suspected public entry was absent, or the repaired operation now enforces account permission. “The investigation ended” is not a restoration condition.
The same logic applies to partial restoration. The owner may restore downloads for one deployment while another still lacks evidence. Report the different states separately and communicate the remaining interruption to the people handling customers. A single “service restored” badge can hide an unverified environment or a workaround with different controls.
If the public path was active, preserve the time-bound conclusion and any separate incident inquiry. Closing the exposure question does not establish whether anyone used it historically. If the path was absent, retain the source defect's actual internal actor and repair decision. Neither result should erase the distinction between reachability, vulnerability and observed misuse.
A useful final update names what changed in the work plan: who repairs the account-bound operation, whether the restriction remains, which environment is covered and when the next decision occurs. That gives the uncertain-exposure investigation a concrete end without pretending it answered questions it never examined.
Gather evidence without overstating it
Ask AppSec, the service owner and the platform owner for the live artifact, ingress mapping, network policy, gateway authentication rule and service-to-service routes. Compare these to the vulnerable operation and time window. Scope any authorized controlled test explicitly. A source or configuration review does not prove a production exploit ran.
When evidence conflicts, preserve both records. A source gateway template may say public while the live route is disabled. A live route may be public while the relevant operation requires a separate privilege. Document which source is current and why it controls the decision. If no one can produce the deployed mapping, the answer is still unknown; escalate the missing inventory as its own operational problem.
Close the loop by updating the finding record with the exposure state, affected deployment, evidence date, owner and next review trigger. Reassess after a gateway change, new environment, account policy change or code release. A later “not exposed” decision should cite the specific boundary and version, so another reviewer can test whether it still holds.
Next action: Pick one open finding whose priority depends on “public or internal.” Fill the four-state rubric with deployment evidence and a deadline. For the related score question, use How to handle a critical scanner score with weak evidence. For an auditable one-page result, use the vulnerability priority decision record template.