Exposed Swagger Files, APIs and Staging Sites: What Attackers Find First

By ScruteXPublished 06-10-2026

Ask most organisations to describe their internet-facing footprint and you will hear a short list: the main website, the customer portal, the mobile app backend, perhaps a marketing site. That list is usually accurate for the assets the security team approved.

An outside observer often sees something different:

api.company.com
dev.company.com
staging.company.com
qa.company.com
swagger.company.com
api.company.com/docs
api.company.com/swagger
an application subdomain from a product retired three years ago
a test deployment someone spun up for a client demo
an admin interface that was meant to sit behind the VPN

None of these is a breach. Most are not even vulnerabilities. But each one tells an outsider something about how your organisation builds and runs software. Together they form a map that you may not have drawn yourself.

The first problem is often not exploitation. It is discovery. Attackers frequently do not need to start with an exploit. They start by finding what an organisation has exposed to the internet without meaning to, and then decide where to spend their effort.

This article explains what exposed Swagger files, exposed APIs and staging sites can reveal, why they matter, how to tell exposure apart from real vulnerability, and how security teams can find, prioritise and reduce their own external exposure.

Quick Answer: What Do Attackers Find First?

Attackers commonly begin with assets and information that anyone can observe from outside the organisation:

subdomains and the applications behind them
exposed services and open ports
API endpoints
API documentation, including Swagger UI pages and OpenAPI files
staging, QA, test and development environments
login pages and other authentication interfaces
technology fingerprints such as frameworks, servers and versions
administrative interfaces
forgotten application deployments
cloud-hosted assets
old versions of applications and APIs

Discovery does not equal compromise. But every unnecessary internet-facing asset adds to the amount of information defenders must understand, own and secure. The organisations that handle this well are the ones that know what they expose before anyone else tells them.

What Is an External Attack Surface?

An external attack surface is everything your organisation exposes to the internet that someone could reach, observe or interact with. That includes domains, subdomains, IP addresses, web applications, APIs, cloud services, certificates, remote-access services and the information those assets disclose about themselves.

It is useful to split that surface into five groups, because each one fails in a different way.

Known Assets

These are assets the security team knows about and exposes on purpose: the public website, the customer login, a published partner API. They are usually in the asset register, have an owner, and sit inside normal patching and monitoring.

Unknown Assets

These exist and are reachable, but nobody tracks them properly. A product team might have launched a microsite through a separate cloud account. The asset works and may be perfectly secure. The security team simply cannot vouch for it, because it does not know it exists.

Forgotten Assets

These were known once. The project ended, the engineer moved teams, or the product was retired, but the DNS record, the server or the API stayed online. Forgotten assets are dangerous because they stop receiving updates while staying reachable.

Shadow Assets

These were deployed outside the normal security process altogether. A developer testing a new service, a business unit trialling a SaaS integration, or a vendor hosting something on your behalf can all create shadow assets.

Exposed Development Assets

These are staging, QA, test and development systems that became internet-accessible, often by accident and often temporarily. "Temporary" has a habit of lasting years.

Why Inventory Comes First

Every other security control depends on knowing what you have. You cannot patch, monitor, pen test or decommission an asset you do not know about. The NIST Cybersecurity Framework 2.0 places asset management (ID.AM) in its Identify function for this reason, and the OWASP API Security Top 10 (2023) lists Improper Inventory Management as its own risk category. In a Continuous Threat Exposure Management (CTEM) programme, external discovery is the input to every later stage.

Swagger and OpenAPI Exposure

What Is Swagger / OpenAPI?

The OpenAPI Specification is a standard, machine-readable format for describing HTTP APIs. An OpenAPI file, usually written in JSON or YAML, lists an API's endpoints, the methods each one accepts, the parameters and request bodies it expects, the responses it returns, and the authentication schemes it uses. Older versions of the format were called Swagger, and many people still use the two names interchangeably.

Swagger UI is a widely used open-source tool that reads an OpenAPI file and renders it as an interactive web page. Developers can browse the endpoints and, in many configurations, send test requests directly from the browser.

Developers use these tools for good reasons. They keep documentation in sync with code, speed up integration work, support client code generation, and make it easier for partners to adopt an API. Many frameworks can generate an OpenAPI file automatically from the code.

Swagger and OpenAPI are not insecure. They are documentation tools. The security question is where that documentation ends up and who can read it.

Why Exposed Swagger Files Matter

An OpenAPI file is written to make an API easy to understand. That is exactly why its exposure matters. Depending on how it was produced, a published file can reveal:

endpoint names and paths
HTTP methods for each endpoint
parameters and request structures
response structures and field names
authentication mechanisms and where they apply
API versions, including older ones still described
internal naming conventions
relationships between objects such as accounts, users and orders
endpoints marked as deprecated but still documented
administrative or internal functionality

Swagger documentation is not inherently a vulnerability. The risk comes from unnecessary exposure, sensitive information disclosure, weak authentication, insecure endpoints, or APIs that were never intended to be publicly discoverable.

Scanning data shows that this documentation is being looked for. In June 2026 the SANS Internet Storm Center reported that its honeypots had logged more than 32,000 requests for a single common Swagger file location since late 2020, with new location variants still appearing in 2026. The author compared a Swagger file to a directory listing for an API and advised organisations to check their own environments for documentation published by mistake.

What an Attacker Can Learn Without Exploiting the API

Everything in this section can be learned by reading documentation that has been left public. No request to the API itself is required.

Endpoint Discovery

Documentation may reveal endpoints that would otherwise be hard to find. An internal reporting endpoint, a bulk export function or a partner-only route might never be linked from the public application. If the documentation lists it, its existence is no longer private.

Technology Discovery

API documentation can reveal the framework that generated it, the specification version, naming conventions and architecture clues such as separate services for payments or identity. Server addresses listed in the file sometimes point to internal or staging hosts that were not meant to be published.

Authentication Discovery

Documentation usually declares how the API expects clients to authenticate: API keys, OAuth 2.0, JSON Web Tokens, session cookies or other mechanisms. It may also show which endpoints declare no authentication requirement at all. That is useful information for a defender reviewing access control, and it is equally useful to anyone deciding where to look first.

Business Function Discovery

Endpoint names often describe what the business does. Paths involving payments, users, orders, files, accounts, administration, reporting or internal workflows show where sensitive data and valuable actions live.

For defenders, this is the key point. The documentation shows an outsider which parts of the API matter most. If those parts have a weakness in authentication or authorisation, the documentation has shortened the time it takes to find it.

A Note on Swagger UI Itself

Swagger UI is a web application with its own release history. Some older versions had known cross-site scripting issues. Vidoc Security Lab, for example, documented a flaw in Swagger UI 3.x builds caused by an outdated sanitisation library. The defensive takeaway is simple: if Swagger UI must be reachable, keep it on a current version, including copies bundled inside other packages.

Exposed APIs

What Makes an API Exposed?

People often use "exposed API" loosely. These five terms describe different situations and call for different responses.

Term	What it means	Example
Public API	Intentionally reachable from the internet and designed for external use	A documented payments API for merchants
Unintentionally exposed API	Reachable from the internet but never meant to be	An internal service published through a misconfigured load balancer
Unauthenticated API	Accepts requests without verifying who is calling	A health-check endpoint (fine) or a customer lookup (not fine)
Weakly protected API	Has controls, but they are insufficient or inconsistent	Authentication on v2 but not on the still-running v1
Vulnerable API	Contains a flaw that can be abused	Missing object-level authorisation that lets one user read another's records

A public API can be well secured. An unauthenticated endpoint can be entirely appropriate. The label "exposed" describes reachability, not safety.

One more distinction matters throughout this article: authentication and authorisation are different controls. Authentication confirms who the caller is. Authorisation decides what that caller is allowed to see or do. An API can authenticate every request and still fail to check whether the caller should access a particular record. OWASP ranks Broken Object Level Authorization as the top API security risk for this reason.

Why API Exposure Matters

Unnecessary API exposure can create or reveal:

attack surface that serves no business purpose
sensitive endpoints that become discoverable
information disclosure through responses or error messages
authentication weaknesses
excessive data in responses, where the API returns more fields than the client needs
forgotten API versions with older controls
undocumented endpoints that skipped security review
security controls applied unevenly across environments or versions
insecure third-party integrations that trust the API too broadly

Not every exposed API has these problems. The concern is that an exposed API nobody owns is unlikely to be reviewed for any of them.

Shadow APIs and Forgotten Endpoints

A shadow API is an API that runs and responds but is not in the organisation's official inventory. APIs end up in this state after:

application migrations that left the old backend running
version changes where v2 launched but v1 was never switched off
acquisitions that brought in infrastructure nobody mapped
development projects that ended without cleanup
product launches built on a fast, temporary stack
infrastructure changes that moved traffic but not every DNS record
temporary testing that became permanent

Old API versions are especially hard to track. Mobile apps already in users' hands may still call them, so teams keep them running. Security fixes often land in the newest version and never reach the old one. The OWASP API9:2023 Improper Inventory Management entry describes exactly this pattern, including a beta API host that ran the same password reset flow as production without production's rate limiting.

The Optus breach in Australia is a real example of how inventory gaps compound. According to the Australian Communications and Media Authority's allegations in Federal Court, an access-control coding error affected both the main domain and an API subdomain. Optus fixed the error on the main domain in 2021 but not on the subdomain, which the attacker reached in September 2022. The fix existed. It stopped at one hostname.

Exposed Staging and Development Environments

Why Staging Environments Are Risky

Staging environments exist to test changes before they reach production. To do that job, they are often configured differently from production. Depending on how a team runs them, a staging environment may contain:

incomplete or relaxed security controls
debugging functionality left switched on
test accounts with simple or shared passwords
copies of production data, or data close enough to production to matter
temporary credentials and API keys
older software versions awaiting upgrade
experimental APIs not yet reviewed
internal documentation, including API documentation
verbose error messages that reveal stack traces or configuration

Not every staging system contains these things. Many are well run. The risk is that staging gets less attention, so problems that would be caught in production can persist there.

Why Staging Gets Forgotten

Staging and development assets slip out of view for organisational reasons more than technical ones:

They live in separate cloud accounts or subscriptions that central security does not monitor.
They were created as temporary deployments for a test, a demo or a migration.
Developers own the infrastructure directly, outside the platform team's processes.
DNS records outlive the systems they pointed to, or point to systems nobody remembers.
Old CI/CD pipelines keep deploying to environments that no one uses.
Feature-branch environments are created automatically and not always removed.
A project is abandoned, but its infrastructure is not.
A vendor or agency manages the environment on your behalf.
Infrastructure is created outside standard provisioning, so it never reaches the register.

Staging vs Production: Why the Security Model Can Drift

In many stacks, security controls are attached to production infrastructure rather than to the application code. Production might sit behind a web application firewall, enforce strong authentication, send logs to the SOC, apply rate limits at an API gateway, and run a hardened configuration.

A staging environment running the same code may have only some of those layers, or different versions of them. Nobody decided to make staging weaker. The controls were simply never added, or they drifted as production changed and staging did not.

This configuration drift is common but not universal. Some organisations mirror production controls into staging deliberately. The point for defenders is to check, not to assume.

Non-production does not always mean low impact. Microsoft disclosed in January 2024 that the threat actor Midnight Blizzard gained a foothold by compromising a legacy non-production test tenant account, then used that account's permissions to reach corporate email. The asset was labelled as test. Its permissions reached production.

What Attackers Can Discover First

The table below summarises what common exposed assets can reveal and the question a defender should ask about each.

Exposed Asset	What It Can Reveal	Security Concern	Defensive Question
Swagger UI	API endpoints and methods	API discovery	Should this documentation be public?
OpenAPI file	API structure, auth model, server addresses	Information disclosure	Does it expose sensitive functionality or internal hosts?
API endpoint	Application functionality	Unnecessary attack surface	Does it require authentication and enforce authorisation?
Staging site	Development functionality	Configuration drift	Should it be internet-facing at all?
Dev subdomain	Development application	Shadow asset	Who owns it?
Old API version	Legacy functionality	Forgotten controls	Is it still required?
Admin interface	Administrative functionality	High-value exposure	Why is it publicly reachable?
Debug interface	Diagnostic information	Information disclosure	Can it be disabled externally?
Forgotten subdomain	Unknown application	Shadow IT	Is the asset still needed?

How Attackers Discover These Assets: A Defensive View

This section explains where external visibility comes from so that defenders know what to monitor. It is not a reconnaissance guide.

Most external discovery draws on public or semi-public sources:

DNS records. Subdomains and the services they point to.
Certificate Transparency logs. Publicly trusted TLS certificates are recorded in public logs, so a certificate issued for a staging hostname can make that name visible soon after issuance. MITRE ATT&CK tracks this as T1596.003.
Public documentation. Developer portals, help centres and partner guides.
Search engine indexing. Pages that were never meant to be found can still be indexed.
Cloud asset records. Public IP ranges and hosted services.
Public code repositories. Configuration files, API base URLs and occasionally secrets.
Historical infrastructure records. Old DNS data and archived pages that show what used to exist.
Third-party references. Vendor integrations, status pages and job adverts that mention internal systems.

Defenders can use the same sources. The difference is intent and authorisation: you are mapping your own estate so you can decide what should stay exposed.

The Attack Surface Discovery Chain

External discovery tends to follow a chain from broad to specific:

Domain

↓

Subdomain

↓

Application

↓

Swagger / OpenAPI documentation

↓

API endpoints

↓

Authentication and access controls

↓

Technology and version

↓

Potential weakness

↓

Security validation

↓

Risk prioritisation

The first several stages can happen without any exploitation. An outsider can move from your domain to a list of documented endpoints, their declared authentication requirements and the technology behind them using only information you have published.

The defender's goal is to walk the same chain first. If you find an unnecessary subdomain, an internal OpenAPI file or a forgotten API version at stage two or four, you can remove or restrict it long before anyone reaches the stage where a weakness gets tested.

The Difference Between Exposure and Vulnerability

This distinction separates useful security work from noise. Six terms are often blurred together:

Exposed: reachable or observable from the internet.
Misconfigured: set up differently from what was intended or what policy requires.
Unauthenticated: reachable without proving identity.
Overly permissive: authenticated, but allowing more access or data than the caller needs.
Vulnerable: containing a flaw that could be abused.
Exploitable: vulnerable in a way that can actually be abused in its current context.

A finding can sit at any point on that list. Treating every exposed asset as a critical vulnerability exhausts teams and buries the findings that matter.

Finding	Automatically a Vulnerability?	Why It Matters
Public Swagger UI	No	Reveals API structure
Public OpenAPI file	No	May disclose endpoint and host information
Public API	No	Public APIs can be intentional
Unauthenticated sensitive endpoint	Potentially	Likely access-control issue
Exposed staging environment	Not automatically	May contain weaker controls or real data
Old API version	Not automatically	May have outdated controls
Debug interface	Potentially	May disclose sensitive information
Exposed admin panel	Not automatically	Increases high-value attack surface

An exposure becomes a vulnerability when a specific weakness is present. It becomes exploitable when that weakness can be abused in practice. Validation is how you move a finding from one category to the next with evidence rather than assumption.

How Security Teams Should Assess the Risk

Use these ten questions to assess any externally discovered asset.

1. Internet Reachability

Is the asset publicly reachable, or only visible in records such as DNS or certificate logs?

2. Business Criticality

What business function does it support? A payments API and a marketing microsite carry different stakes.

3. Data Sensitivity

Could it expose personal, financial, health or confidential business data?

4. Authentication

Does it require callers to prove who they are?

5. Authorisation

Once authenticated, are users limited to the data and actions they should have? OWASP's guidance on Broken Function Level Authorization is a useful reference here.

6. Environment

Is it production, staging, QA, development, or unknown? "Unknown" deserves attention in its own right.

7. Technology Risk

Is the technology outdated, or does it have known vulnerabilities? The CISA Known Exploited Vulnerabilities catalogue helps separate theoretical CVEs from ones being used in real attacks.

8. Ownership

Does a named person or team own the asset and answer for it?

9. Necessity

Does it need to be public at all?

10. Exposure Duration

How long has it been exposed? An asset reachable for years has had far more opportunity to be found than one that appeared yesterday.

A Practical Exposure-Prioritisation Model

The table below is an illustrative model, not a scoring system. Actual priority depends on your data, your business and what validation shows.

Finding	Exposure	Business Impact	Priority
Public API documentation for an internal API	Medium	Medium	Review
Public staging site	Medium	High	Investigate
Unauthenticated sensitive API	High	High	Immediate
Forgotten development subdomain	Medium	Unknown	Investigate
Old API version with a known vulnerability	High	High	Immediate
Public Swagger for an intentionally public API	Low	Low	Validate

Two findings with the same label can land in different rows. A public staging site with synthetic data and SSO in front of it is a review item. The same site holding a production database copy is an immediate one.

How to Find Your Own Exposed Assets

Step 1: Build an External Asset Inventory

Start from what is observable outside, not only from what is in the register. Track:

domains
subdomains
applications
APIs
cloud assets
certificates
remote-access services

Then compare the two lists. Anything visible externally but missing from the register needs an owner.

Step 2: Identify Development and Non-Production Assets

Look for naming patterns such as dev, test, qa, staging, uat, demo, beta, old and legacy. Naming conventions help, but they will not catch everything. Some staging environments use project codenames or random cloud hostnames, so confirm environment type with the teams that run them.

Step 3: Identify API Documentation

Find where Swagger UI pages, OpenAPI files and API documentation portals are reachable on your own estate. Ask your engineering teams which frameworks generate documentation automatically, because many do so by default. For each one, decide whether that documentation is meant to be public.

Step 4: Validate Ownership

Every internet-facing asset should have:

an owner
a business purpose
an environment classification
a named security responsibility

Step 5: Validate Exposure

For each asset, ask one question: does this actually need to be publicly reachable? Many do not.

Step 6: Validate Controls

For assets that stay public, check:

authentication
authorisation
TLS configuration
rate limiting
logging
monitoring
security headers
vulnerability status

The OWASP Web Security Testing Guide and the OWASP API Security Project provide structured checklists for authorised testing of your own applications.

Step 7: Remediate or Accept

Pick a decision for each asset and record it:

remove
restrict
authenticate
harden
monitor
document as intentionally public

For API documentation specifically, the cleanest fix is usually at the framework level: disable documentation generation in production builds for internal APIs, and publish reviewed documentation for public APIs from a deliberate location. For staging, put the whole environment behind SSO or network restrictions. An obscure hostname or a noindex tag is not an access control.

Common Mistakes

Assuming the main domain represents the entire attack surface. Subdomains, cloud hosts and vendor-run assets often outnumber it.
Treating Swagger as automatically vulnerable. It is documentation. Judge it by what it reveals and what sits behind it.
Ignoring staging environments. They may hold real data, real credentials, or both.
Forgetting old API versions. Fixes in v2 do not protect v1.
Letting temporary environments become permanent. Give every temporary asset an expiry date and an owner.
Not assigning asset ownership. An asset without an owner will not get patched.
Treating discovery as proof of compromise. Finding an exposed asset is the start of an investigation, not the conclusion.
Focusing only on CVEs. Many API failures are logic and access-control problems with no CVE number.
Ignoring API authentication and authorisation. Authorisation failures are among the most common and damaging API problems.
Not monitoring external exposure continuously. Engineering teams create new assets every week. A quarterly scan sees them months late.

From External Exposure to CTEM

Continuous Threat Exposure Management treats exposure as an ongoing cycle rather than a periodic audit. A simplified operational version looks like this:

Discover

↓

Validate

↓

Prioritise

↓

Remediate

↓

Monitor

Discovering an exposed Swagger file is not the outcome. It is an input. The useful outcome is answering:

Is it intentional?
Who owns it?
What does it reveal?
Does it expose sensitive functionality?
Does it connect to a vulnerable application?
What action should happen next?

That is the shift CTEM asks for: from collecting findings to resolving them in order of real risk. Our guide to what CTEM is and how it works covers the full framework, and our comparison of continuous monitoring and monthly scans explains why the gap between scans is where forgotten assets live.

"Am I Exposed?" Self-Check

Answer these from your own records:

☐ Do we know every internet-facing subdomain?
☐ Do we know every internet-facing API?
☐ Do we know where Swagger or OpenAPI documentation is publicly accessible?
☐ Do we have staging or development environments exposed to the internet?
☐ Are old API versions still reachable?
☐ Does every internet-facing application have a named owner?
☐ Do we know whether non-production systems contain sensitive data?
☐ Are authentication and authorisation controls consistent across environments?
☐ Can we identify externally exposed assets that were created outside the normal deployment process?

If you cannot answer these questions confidently, the gap may be asset visibility rather than vulnerability scanning.

How Scrutex Fits

Scrutex is an external attack surface and CTEM platform. It helps security teams maintain visibility into what their organisation exposes externally, so that unknown or unnecessary exposure can be investigated and prioritised.

Setup is agentless: a domain and a set of keywords. From there, Scrutex Vulnerability Insights continuously discovers internet-facing assets tied to your domains and flags external issues such as open ports, expired certificates, dangling subdomains and outdated web technologies. Findings are prioritised by real-world exploitability rather than raw CVSS scores. Where an exposed service, staging host or API key turns up in leaked data, Data Exposure Insights monitors paste sites, code leaks and breach corpora for credentials and keys tied to your domains.

As an example of what external discovery can surface, Scrutex's first scan at an ASX-listed financial services client (as part of a 12-month deployment) returned more than 30 internet-facing assets against a 20-asset manual register. Nine were unknown to the client, including a staging environment for a client-facing application.

Scrutex sees only what is externally observable. It will not find an API that is reachable only inside your network, and it does not inspect API traffic the way a gateway-based API security tool does. It does not replace application security testing, API security testing, a secure SDLC, penetration testing, your SOC, incident response or internal security controls. It gives those teams an accurate, current picture of what is exposed, so their effort goes to the right place. Findings reach your workflow through the REST API and webhooks today.

If unknown hosts are your main concern, Vulnerability Insights covers external asset discovery. If you suspect a staging secret or API key has already leaked, start with Data Exposure Insights.

Know what your organisation exposes before someone else discovers it

Run an external attack surface check on your domain with Scrutex. Domain only, no agent to install.

Final Takeaway

The most important question is not "Can an attacker find my Swagger file?"

It is: "Do I know what my organisation exposes externally, why it is exposed, who owns it, and whether it creates unnecessary risk?"

Organisations that can answer that question run a steady cycle: discovery, validation, prioritisation, remediation and continuous monitoring. They find the forgotten staging site, the internal OpenAPI file and the old API version first, and they decide what to do with each one deliberately. Scrutex helps keep that external picture current, so the decisions rest on what is actually exposed today.

FAQ

What is an exposed Swagger file?

An exposed Swagger file is an OpenAPI or Swagger specification that anyone on the internet can read without authentication. It describes an API's endpoints, parameters, responses and authentication methods. Exposure is a concern when the file describes an API that was not meant to be public or reveals internal hosts and functionality.

Is an exposed Swagger UI a security vulnerability?

Not by itself. Swagger UI is a documentation tool. It becomes a concern when it documents internal or sensitive APIs, lets visitors send live requests to a production backend, or runs an outdated version with known flaws.

Why are exposed APIs risky?

Unnecessary exposure increases attack surface and can reveal sensitive functionality. The real risk depends on whether the API enforces authentication and authorisation, what data it handles, and whether anyone owns and monitors it.

What is an exposed staging environment?

It is a pre-production copy of an application that is reachable from the internet. Staging environments may run with weaker or inconsistent controls and can hold test accounts, debug features or copies of real data.

Why are staging environments often overlooked?

They are often created quickly, live in separate cloud accounts, are owned by developers rather than central teams, and outlast the projects that created them. Many never reach the asset register.

How do attackers discover exposed APIs?

At a high level, they use public sources such as DNS records, certificate logs, search engine indexes, public code repositories and published documentation. Defenders can monitor the same sources for their own assets.

How can I find exposed APIs in my organisation?

Build an external inventory from outside-in sources, compare it with your asset register, identify API documentation and non-production hosts, then confirm ownership and controls for each. Continuous external attack surface monitoring keeps the inventory current.

How do I know whether an API should be public?

An API should be public only if external users, customers or partners need it and it has a named owner. If nobody can state its business purpose, restrict or remove it.

What is the difference between an exposed API and a vulnerable API?

An exposed API is reachable from the internet. A vulnerable API contains a flaw that can be abused, such as missing authorisation checks. Many exposed APIs are secure, and a vulnerable API is not always reachable externally.

What are shadow APIs?

Shadow APIs are APIs that run and respond but are not in the organisation's official inventory. They often result from migrations, old versions, acquisitions or temporary projects, and they tend to miss security reviews.

How should security teams prioritise exposed staging sites?

Prioritise by data sensitivity, authentication, links to production systems and how long the site has been exposed. A staging site with real data or production credentials should be treated as urgently as production.

How does external attack surface management help?

External attack surface management continuously discovers internet-facing assets from an outsider's view, including ones missing from internal records. That gives teams the inventory they need to validate, prioritise and fix exposure.