Sign Up

A 30-hour pentest expires the day after it ships

A web application pentest takes three days. The next one is in six months. Between them, your dependencies, IAM, and supply chain keep moving — and nobody is watching the way the pentester was. That gap is where things go wrong.

Cover Image for A 30-hour pentest expires the day after it ships

We just delivered a 30-hour web application pentest. Three days of work, one report, a handful of confirmed criticals and highs. The client signed off and asked for the next assessment in six months — or after the next big feature release, whichever comes first.

That six-month window is the actual problem.

What expires in 180 days

Between two pentests, a normal engineering team ships continuously. New dependencies arrive every week. New IAM bindings on every new service. Storage buckets get spun up and, eventually, forgotten. The supply chain absorbs whatever the upstream maintainers shipped that day. None of that is in scope of the pentest we just delivered.

We tested the application that exists today. Not the application that exists tomorrow.

This is not a complaint about scope. The scope is the scope by design. What we are naming is a structural gap. The audit ages out fast, the next time anyone looks is six months away, and during those 180 days nobody is watching the cloud account or the dependency tree the way the pentester was watching the app.

Two weeks ago a vulnerability called NGINX Rift (CVE-2026-42945) went public. Critical, CVSS 9.2, unauthenticated remote code execution inside the NGINX worker process. The flaw has been in every NGINX build since version 0.6.27 — released in 2008. Eighteen years of dormancy in the most-deployed web server on the planet, with a working public proof-of-concept landing the same week as disclosure. If your last pentest was a few months ago, your NGINX was vulnerable then too. The pentester could not have found it. Nobody outside the disclosing researchers knew it was there. What changed is not your code. What changed is what the world now knows about your code.

That is the structural risk a six-month audit cycle cannot cover. The thing exploiting your fleet next quarter is, statistically, already in your stack today.

The obvious answer, and why it doesn't fit

The market answer is continuous cloud scanning. In practice the choice for a small or mid-size team comes down to one of two paths:

Enterprise CNAPP. Wiz, Orca, Prisma Cloud. Their pricing assumes the customer already has a dedicated security team and the budget that comes with it. For a 20-person engineering org, an annual quote can land in the same range as a mid-level engineer's salary — money that would otherwise hire the person who would fix what the scanner finds.

Open-source DIY. A team that wants equivalent coverage from open source ends up stitching together six or seven separate engines: a posture checker, a vulnerability scanner, an image scanner, a misconfiguration scanner for the IaC, a secrets scanner, a cloud asset inventory, a supply-chain advisory feed, an IAM analyzer, an attack-path correlator. Plus the dashboard someone has to build to make any of it usable. Plus the scheduler. Plus the on-call rotation for when one of those engines starts erroring at 2am.

All real, all open source, all free as in you do the work. Setting up and operating the pipeline becomes a job in itself. The engineers who could be shipping product become unpaid platform operators instead.

Both options have the same end state for the team we are describing: the gap stays open because neither option is realistic to adopt.

What VikingCloud is for

We built VikingCloud to sit in the middle of that gap.

Connect a cloud account — GCP, AWS, Azure, or Kubernetes — in a few clicks. No agents, no eBPF, no IAM choreography. The platform scans on a regular schedule, plus on demand. Findings are correlated by a set of agents — we call them Viking agents — into prioritized issues with the chain of evidence visible. Not hundreds of alerts dropped into a queue. Attack paths render as a graph you can read at a glance. Compliance against CIS, SOC 2, PCI 4.0, ISO 27001, and other frameworks is a toggle.

Affordable. Automated. Built for teams that do not have a security operations function and are not hiring one this quarter.

What it deliberately does not do, yet: runtime protection, code-to-cloud tracing, replacing the human pentester. Those are different jobs. The job VikingCloud does is the one nobody else is doing for this market — keep watching the cloud and the dependency tree while you go back to building.

What to do today, with or without us

The pentest gap closes in three steps that do not require a procurement cycle:

  1. Build a current cloud inventory. Every account, every region, every cluster, every cloud organisation with subaccounts that may not yet be onboarded. Knowing what you have is the precondition for knowing what is wrong with it. Without this step the next two are guessing.
  2. Subscribe to the right advisory streams. OSV.dev for cross-ecosystem CVEs, the CISA Known Exploited Vulnerabilities catalog for what is actually being weaponized, and your cloud provider's security bulletin RSS. Three feeds, free. If NGINX Rift had landed against a team subscribed to these, the disclosure window between "the world knows" and "we know" would have been minutes, not weeks.
  3. Define a between-pentest checklist that fits in 30 minutes a month. Diff your IAM bindings against last month. Audit storage bucket ACLs for any newly-public state. Compare your top-level dependency manifests against the latest OSV feed. None of this replaces a pentest. All of it limits how far you can drift between pentests.

The pentest we just shipped will start aging the moment the next deploy goes out. The scan that runs tonight will not. That is the difference, and it is the entire reason we built the platform.

Start your 14-day free trial to connect your first cloud account and see your inventory cross-referenced against the latest CVE and KEV feeds in seconds, or book a demo if you would prefer we walk through the platform with your team.

References

  1. NIST National Vulnerability Database. CVE-2026-42945 Detail.
  2. Akamai. CVE-2026-42945: Mitigating a Critical Heap Buffer Overflow Vulnerability in NGINX.
  3. Picus Security. NGINX Rift: CVE-2026-42945 Critical Heap Buffer Overflow Vulnerability Explained.
  4. Cloud Security Alliance. NGINX Rift: 18-Year-Old Heap Overflow Enables Unauthenticated RCE.
  5. Security Affairs. NGINX Rift: an 18-year-old flaw in the world's most deployed web server just came to light.
  6. CISA. Known Exploited Vulnerabilities Catalog.
  7. OSV.dev. Open Source Vulnerabilities database.
  8. VikingStrike. The Supply Chain Clock Starts When the CVE Drops. April 22, 2026.