Half the cybersecurity industry spent the past week congratulating an OWASP project for bolting an LLM onto three container scanners, while Check Point VPN gateways were being actively exploited and Oracle PeopleSoft servers were taking direct hits in production. The reaction to DockSec was predictable. Scanner good. AI helpful. 0 to 100 score, ship it. None of that addresses the question nobody seems to want answered: who in your organization is actually reading the output of the scanners you already paid for? If the honest answer is “nobody, regularly,” then a fourth tool stacked on top of the first three is theater.

The Scan Ran. Nobody Owned The Output.

Walk into any mid-sized engineering organization and ask who is responsible for triaging Trivy findings on the gateway service. You will get one of three answers. “Security.” “Platform.” Or the truly memorable: “I think we get a Slack alert.” None of those is an owner. They are vibes.

This is the actual unowned control surface the news keeps surfacing. The Check Point VPN devices being exploited this week were patchable. The PeopleSoft servers being attacked have publicly documented hardening guides. The teams who got hit didn’t fail at scanning. They failed at the part after the scan, which is somebody reading the result, deciding it matters, and shipping the fix before someone with a Cobalt Strike license shipped theirs.

An LLM-generated remediation paragraph does not fix that. It makes the report more readable for the person who still isn’t reading it.

Why Stacked Scanners Aren’t Defense In Depth

DockSec’s pitch is that running Trivy plus Hadolint plus Docker Scout, then correlating their findings, gives you a more complete picture. Maybe. The technical work is real and the project is open source, so credit where credit is due. Three correlated scanners with an explainer on top is a useful UX improvement for the analyst who already cares.

That is not defense in depth, though. Defense in depth means controls that fail independently. Three CVE scanners reading the same SBOM and consulting overlapping vulnerability databases are not independent. If the upstream database is wrong or stale, they are all wrong together. If the developer running them ignores all three, they are all ignored together.

The independence test

Ask whether your layers fail for unrelated reasons. Container scan plus runtime egress monitoring plus host-level threat detection plus identity-aware proxy. Those break for different reasons on different days. Trivy plus Grype plus Snyk all break the same way when the NVD is behind. Stacking similar tools is not a control. It is reassurance, packaged as a roadmap line item.

What The Check Point And PeopleSoft Stories Actually Tell You

The Check Point VPN zero-day this week is the second in roughly sixty days. The Oracle PeopleSoft attacks aren’t novel either. Both target the boring, owned-by-no-one layers that sit between corporate and the internet. The interesting part isn’t the bug class. It is how predictable the failure mode has become.

Defenders treat edge appliances and ERP systems like furniture. They get patched on a quarterly cycle. They are scanned, sort of. They are monitored, sort of, by whoever owns the SIEM that quarter. And then a zero-day drops and the response is a flurry of asking “do we even have one of those?”

You do. The attackers already mapped you. The week’s news is a reminder that your edge inventory and your post-finding workflow matter more than any new scanner you add to the pipeline. Brute-force telemetry on the firewall management plane is more useful right now than a fourth CVE database.

What Closing The Loop Actually Looks Like

Here is the unglamorous part. The scanner is the easy purchase. The workflow around it is the work. If you want container findings, firewall findings, and ERP findings to stop dying in a ticket queue, the steps are concrete and tool-agnostic.

1. Name an owner per finding class. Not a team. A person, with a named backup. “Container image CVEs above CVSS 8.0” is owned by Maya. Period. If Maya leaves, the handoff is a one-day blocker, not a quarterly oversight item.
2. Set a clock that starts at scan time, not triage time. The SLA on a critical finding is measured from when the scanner first saw it, not when a human noticed. Anything else lets latency hide inside the ticket queue.
3. Wire brute-force and exploit telemetry back to the scan owner. If your VPN gateway is being hammered, the person who owns that appliance’s CVE backlog hears about it first, not the SOC manager who pages them at 2 AM.
4. Pre-authorize the kill switch. “Take this gateway offline” should not require three approvers when CVSS 9.8 is actively exploited. Decide who pulls the cord before the day you need it pulled.
5. Rehearse the boring incident. Not the ransomware tabletop. The “we knew about this for sixty days and didn’t fix it” tabletop. Walk through where the ball was dropped, and patch the workflow, not the personality.

These are not exciting. They will not get you a SOC 2 line item. They will measurably reduce the gap between scan finding and live exploit, which is the actual security hardening metric that matters this year.

Where AI Cybersecurity Tooling Helps And Where It Doesn’t

To be fair to DockSec and the broader category, LLM-assisted remediation does have legitimate use. Junior engineers writing Dockerfiles benefit from a one-line, in-context explanation of why running as root inside a container is a bad idea. Threat detection products that summarize alert sequences save analyst time. Incident response playbooks generated from existing runbooks lower the bar to consistent execution under pressure.

The trap is treating those benefits as a hardening strategy. They are an ergonomic improvement on tools that still require ownership, prioritization, and follow-through to produce a security outcome. If your firewall ruleset is wrong, a better summary of the wrongness does not make it less wrong. If your VPN gateway is two patch cycles behind, no model is going to convince the change advisory board to move faster than the attacker. If your threat protection strategy starts with “we bought a thing,” the thing is not the strategy.

The right framing: AI tooling is a UX layer on top of cyber security work that humans still have to do. Treat it that way and it pays off. Treat it as a control and you have just added a dependency that fails when the model is wrong, the integration drifts, or the budget gets cut.

Frequently Asked Questions

Is DockSec worth running?

Probably, if your developers already use Trivy or Hadolint and you want them to act on findings without consulting security. Just don’t count it as a new layer of defense in depth. It is a better interface to layers you already have, not a new independent control.

Should we patch Check Point VPN gateways right now?

Yes, and verify exposure first. The zero-day this week is being actively exploited. If you cannot patch immediately, restrict management interfaces to a jump host, enable brute-force lockouts, and watch authentication logs for anomalous geographies and short-interval failures.

How do we know our incident response actually works for this attack pattern?

Run a tabletop where the scenario is “we received a critical scan finding 45 days ago and never acted on it, and the affected system is now being exploited in production.” If the conversation devolves into finger-pointing instead of execution, your workflow is the gap, not your tooling.

Sources

• Week in review: Exploited Check Point VPN zero-day, Oracle PeopleSoft servers under attack