The Six-Month Gap That’s Killing Your Security Posture

You ran a pen test in November. The report landed in your inbox in December, polished and bound, with an executive summary you forwarded to your CFO and a 200-page appendix nobody opened.

It is now May.

In the months since that report arrived, your team pushed hundreds of deployments to production. Elite software teams now deploy on demand, multiple times per day.^[1] A new analytics vendor was onboarded with a JavaScript snippet that never crossed your desk. A staging environment that should have been torn down in February is still running, and somebody pointed a public DNS record at it last week. Your CIO closed an acquisition you only learned about in March, and the new company’s external footprint is now technically yours.

The report you got in December describes a company that no longer exists.

The cadence of contracts versus the cadence of change

This is the six-month gap. It is the silent, structural problem at the heart of every modern security program.

Pen testing was built around a calendar. NIST SP 800-115, the technical guide that has anchored most pen testing programs since 2008, frames testing as a periodic activity within an information security program, not as a continuous one.^[2] Auditors expect annual evidence. Procurement signs annual contracts. Vendor capacity is finite, so testing windows get scheduled months in advance. By the time you negotiate scope, schedule the engagement, run the test, and finalize the deliverable, the calendar has burned through a quarter and your environment has moved on.

That cadence made sense in 2010. It does not match how environments change today. The gap between the two clocks is where attackers live. NopSec’s research has surfaced the asymmetry plainly: while organizations find one vulnerability every twelve hours, it takes attackers less than forty-five minutes to do the same, scanning the internet for vulnerable assets with malicious automation.^[3] The defender’s calendar runs in months. The attacker’s runs in minutes.

Why scanners do not close this gap

The reflexive answer is “we run scanners between tests.” Scanners are necessary. They are not sufficient.

A vulnerability scanner tells you a CVE is present on a host. It does not tell you whether that CVE is reachable from the internet through your specific configuration, whether a real attacker could chain it with another exposure, or whether your compensating controls would actually stop exploitation in practice. A scanner produces a list. A pen test produces a path. Our own research mapping CVEs to the MITRE ATT&CK framework shows that the same vulnerability can sit in different attack chains depending on what surrounds it, and the chain is what determines whether you have a problem worth losing sleep over.^[4]

This is why teams that rely on scanners alone end up with the same complaint: drowning in findings, no way to know what an attacker would actually use, no way to prove to leadership that the patches they prioritized were the patches that mattered. The scanner closes a different problem. It does not close this one.

The trap most teams are stuck in

Most security leaders we talk to describe the same trap. Pen testing is too slow, too expensive, and too infrequent. Scanners are too noisy and too shallow. The two tools do not meet in the middle, and the middle is where most actual risk lives.

The cost of staying in that gap is not theoretical. The IBM Cost of a Data Breach Report puts the average global breach at $4.88 million in 2024, with a mean time to identify and contain of more than 250 days.^[5] Patch cycles still average 55 to 94 days in many environments, while attackers operate on a different timeline entirely.^[6]

So teams compromise. Some add a mid-year test, doubling the cost and still missing eight months a year. Some supplement with bug bounty, which is excellent for hardened public targets but uneven coverage for everything else. Some accept the gap and hope the next breach lands somewhere else.

A different rhythm

The case for a different rhythm is not that annual pen testing is broken. It is that annual pen testing was never supposed to be the only signal. It was supposed to be the deepest signal in a layered program, and somewhere along the way it became the only signal a lot of teams could afford to run on their external attack surface.

NopSec Adversarial Simulation is what we built for the months in between. It runs on the cadence of change, not the cadence of contracts. It produces exploitability paths instead of vulnerability lists, which means you see what an attacker would see, not what a scanner would catalog. It uses the same five-phase pen testing methodology our team has been running on manual engagements for eighteen years, executed by purpose-built agents under human oversight at every critical decision point. It does not replace your annual deep-dive engagement. It fills the months between.

We are launching it on May 19. If you have ever opened a six-month-old pen test report and felt the strange dissonance of reading about a company that does not exist anymore, this is for you.

What to do next

NopSec Adversarial Simulation launches May 19. Keep an eye out.

Sources

1. Google Cloud / DORA, “Accelerate State of DevOps Report,” annual editions. Deployment frequency is one of four core software delivery performance metrics tracked since 2014. ↩
2. National Institute of Standards and Technology, “SP 800-115: Technical Guide to Information Security Testing and Assessment,” September 2008. ↩
3. NopSec, “Don’t Let Celebrity Vulnerabilities Steal Your Focus,” white paper, November 2021. Underlying figure attributed to MIT Technology Review. ↩
4. NopSec, “2024 State of Threat and Exposure Management Report,” Volume 3: Cyber Threat and Exposure Management. ↩
5. IBM Security, “Cost of a Data Breach Report 2024,” published in collaboration with the Ponemon Institute. ↩
6. NopSec, “The Future of Exposure Management Is Preemptive: What That Means for Security Teams,” blog post. ↩