What it means
Exposure describes the opportunities an attacker has to reach or use a system, service, weakness, or sensitive capability. Internet reachability is one important example, but internal networks, stolen identities, partner connections, and application permissions can also create access paths. Exposure is therefore relative to a starting point and a set of assumptions. A service may be reachable without being vulnerable, and a vulnerability may exist without being reachable from a particular location. Keeping these distinctions separate makes remediation decisions more accurate.
The idea at a glance / Vulnerabilities
A blocked route leaves the weakness in place.
The same vulnerable test service is unreachable through one network path and usable through another. Reachability and permission remain separate checks.
Fictional PlantPlan V0 with network rule N6, 25 September 2026. Public-route traffic is blocked; the partner client has an allowed route and a valid S17 session. P29 belongs to S29.
READ THE PICTURE
Read the distinction and scope
N6 blocks the public probe before application checks run. The partner route reaches the same V0; with S17’s valid session, its P29 read returns another supplier’s test data. Restricting one route changes exposure, not the missing owner check.
Keep in mindThis compares two entry paths under one configuration. A blocked public path does not repair V0 or prove every other route safe. Internet reachability alone would not prove data access.
Read the complete example
- Read the distinction and scope. N6 blocks the public probe before application checks run. The partner route reaches the same V0; with S17’s valid session, its P29 read returns another supplier’s test data. Restricting one route changes exposure, not the missing owner check. This exposure comparison uses the deliberately vulnerable PlantPlan V0 teaching variant, not the corrected V1 service in the trust-boundary figure. V0 validates a session and identifier syntax but lacks the own-supplier permission check for record reads. Under the chosen N6 network configuration, an authorized probe from the public starting point cannot establish the HTTPS connection to the service. No PlantPlan session or application permission result is established on that blocked path. An independent probe from the partner client establishes a connection through N6’s permitted route. A subsequent application test using a valid S17 session requests P29, a synthetic record owned by S29. V0 returns its content because the owner check is missing. These are two independent tests, not a request that passes a block and continues elsewhere. The service implementation remains V0 on both paths. The network rule restricts which path can reach it; it has not supplied a replacement object-level check or removed the weakness. A service can also be reachable while refusing unauthorized operations, as V1 does; reachability alone is not proof of sensitive access. Other locations, protocols, sessions, permissions, proxy routes, and rule failures would need their own evidence. No scan of a public or live service is performed by the figure.
This compares two entry paths under one configuration. A blocked public path does not repair V0 or prove every other route safe. Internet reachability alone would not prove data access.
Diagram references: NIST SP 800-30 Rev. 1 - susceptibility, dependencies, and controls · OWASP - object-level access checks
AN ILLUSTRATIVE SCENARIO
An internal reporting service gains a public route
A finance team moves a reporting application during a cloud migration. The software version stays the same, but a new network rule makes its administration interface reachable from the internet. That configuration change increases exposure without creating a new software vulnerability. The security team checks the actual route and access requirements, works with the owner to restrict administration, and confirms that ordinary staff can still use the reporting workflow.
Put it to work
- Identify the asset and the attacker starting point you are assessing. Map relevant network routes, identity requirements, application permissions, and connected services.
- Compare intended access with observed access using configuration review and authorized tests. Include internal and partner paths, not only a scan from the public internet.
- Reduce unnecessary paths and privileges, then retest. Record the owner, remaining access requirements, and changes that should trigger another review of the exposure.
How to check your work
Test from the specific locations and identities in your assessment. Confirm that prohibited access fails and required access still works. Document any assumptions, such as an upstream control or identity policy, on which that result depends.
Connect the ideas
- Vulnerability
A weakness in a system, process, or person that makes a loss easier to cause.
- Likelihood
How plausible it is that a threat will cause a loss in this environment, given exposure and evidence.
- Trust boundary
A place where identity, network, or data assumptions change and a fresh check is required.
- ASM
The ongoing discovery, assessment, and reduction of ways an attacker could reach or affect an organization’s assets. Its scope may include external, internal, and cloud environments.