Why do exposure and vulnerability counts change so quickly between pentests?

Why This Matters for Security Teams

Exposure and vulnerability counts are moving targets because the underlying environment is changing faster than a point-in-time test can capture. Cloud services spin up, secrets leak into code or CI/CD, third-party packages shift, and attackers do not wait for the next pentest window. That is why a clean report in one week can look stale the next. NHI Mgmt Group data shows 91.6% of secrets remain valid five days after notification, which is a strong indicator of how slowly real exposure is often removed even after it is known.

Security teams often misread pentest output as a stable inventory of risk instead of a snapshot of what was visible and reachable at a moment in time. The result is false confidence, delayed remediation, and surprise findings when a new service or API key appears after the engagement closes. For background on why non-human access changes the attack surface so quickly, see Ultimate Guide to NHIs — Why NHI Security Matters Now and current alerting patterns in CISA cyber threat advisories.

In practice, many security teams discover that their “pentest gap” is really a visibility gap only after a new exposure has already been used or inherited by production.

How It Works in Practice

A pentest measures what was exposed, reachable, and exploitable during a defined test period. Between tests, the environment can change enough to invalidate the result set. In cloud and software delivery pipelines, that change can come from autoscaling infrastructure, new IAM bindings, a merged pull request, a vendor dependency update, or a secret accidentally committed to a repository. That is why the count of exposures or vulnerabilities can rise quickly even when the organisation is not “doing anything wrong” in the traditional sense.

For security operations, the practical response is to separate point-in-time validation from continuous exposure management. Pentests still matter, but they should be paired with asset discovery, secret scanning, dependency monitoring, and configuration drift detection. Guidance from CIS Controls v8 supports this kind of continuous hygiene, while NHIMG research on Guide to the Secret Sprawl Challenge shows how quickly hidden credentials widen exposure. The operational question is not only “what was vulnerable?” but “what changed since the last scan, and which changes expanded blast radius?”

• Track newly exposed assets, not just newly discovered CVEs.
• Compare pentest findings against live cloud, code, and secret inventories.
• Prioritise internet-facing credentials, service accounts, and third-party integrations.
• Use change detection to identify risk added after the test date.

These controls tend to break down when organisations lack authoritative inventory across cloud accounts, repositories, and CI/CD systems because the test can only report against what it can actually see.

Common Variations and Edge Cases

Tighter exposure monitoring often increases operational overhead, so organisations have to balance remediation speed against noise, tooling cost, and ownership friction. The counts can also fluctuate for reasons that are not equally urgent. A disclosed CVE in a rarely used internal service, for example, is not the same as a newly exposed API key in a public repo, even though both change the numbers.

There is no universal standard for how often exposure counts should be refreshed, but current guidance suggests using risk-based intervals rather than waiting for the next formal pentest. Fast-moving environments such as ephemeral containers, serverless functions, and agent-driven workflows often need near-real-time control checks because assets appear and disappear too quickly for quarterly reviews to stay useful. For threat context on how quickly exposed credentials become operationally relevant, review the 52 NHI Breaches Analysis and Top 10 NHI Issues.

Edge cases matter most when third parties, shared SaaS tenants, or unmanaged service accounts are involved, because exposure can change outside the normal change-management path and arrive between test cycles without a matching ticket.

Related resources from NHI Mgmt Group

• What is the difference between vulnerability scanning and continuous exposure management?
• What is the difference between patching a WSUS vulnerability and reducing its exposure?
• How should security teams measure exposure drift between pentests?
• Should organisations use exposure metrics instead of traditional vulnerability counts?