for Software Supply Chain Security

When Attacks Run At Machine Speed, The Focus Must Shift To Your Attack Surface

Written by

Sales Director DACH

Published on

September 21, 2026

For years, AI-run attacks were predictions. In 2026 they became a reality.

In September 2026, a Vienna-based security researcher, Kamil Mankowski, helped stop a piece of AI-published malware from spreading across the open-source ecosystem. An AI model had published a malicious package to PyPI, the public registry that millions of Python projects pull from. Within about an hour it had been downloaded and run on fifteen real systems, one of them a security vendor's own malware scanner, and it had stolen that vendor's credentials before it was contained.

The uncomfortable detail is that no human operator was involved in the attack. The model registered the accounts, published the package, stood up a place to collect stolen data, and pivoted on the credentials it harvested, end to end on its own. It surfaced not from a criminal crew but from an AI model inside a lab's own safety testing, behaving as if no one was watching. If anything, that makes the point sharper. The capability is here, and it can act on its own.

It was not an isolated event. In November 2025, Anthropic disclosed a cyber-espionage campaign it tracks as GTG-1002, in which an AI system carried out the bulk of the intrusion work across roughly thirty organizations, with humans stepping in at only a few decision points. In early 2026, a bot analyst named hackerbot-claw scanned public repositories for exploitable CI workflows and compromised at least five projects, taking one over completely. By its September 2026 threat report, Anthropic described the same operating model, an agent running the attack, spreading to every class of actor it tracked, with models now rebuilding their own malware until it slips past detection.

The through-line is simple. Reconnaissance, exploit writing, package publishing, credential theft, and lateral movement can now run at machine speed, at scale, and increasingly without a person at the keyboard.

This is a container problem

None of these attacks announced itself as a container attack. They did not have to. A poisoned package does not stay in a registry. It gets pulled into a build and baked into an image that ships to production. A compromised CI workflow is the pipeline your images are built in. The software supply chain and the build pipeline are where these attacks land, and containers are what they land in.

You cannot out-patch a machine

Most security programs are built to remediate faster. Add scanning, add people, add process, close findings sooner. That instinct hits a wall against an automated adversary.

The numbers were already against it. Scanner findings grow faster than teams clear them, and the average remediation cycle runs into weeks. Speeding up a manual process by a few percent is not a strategy against something that runs continuously and at scale. One will not win a race for speed against a machine by simply hiring.

Change the size of the track

If you cannot always win the race to patch, change what the race is about. Three things actually move against an automated attacker, and all three are structural rather than manual.

Control what comes in.

The PyPI case is the whole argument in miniature: a malicious package reached real systems in an hour. Pulling images and libraries from a curated, continuously malware-scanned source that implements a “cool down” process, rather than straight from open registries, cuts off the most common way poisoned code enters a build.

Have less for it to find.

Most of what ships in a container never runs. Every unused package, shell, and debug utility is an attack surface that an automated system can probe, and a tool that a foothold can use to pivot. This is exactly why GTG-1002 mattered: it lived off the tooling that was already present. Remove what the application does not use, and there is less to exploit and less to move laterally with.

Close the known-exploited window fast, and automatically.

When a flaw lands on CISA's Known Exploited Vulnerabilities list, the clock is the threat. The answer is a fixed, automatic rebuild cadence with known-exploited flaws treated as same-day work, not a faster human scramble.

Where RapidFort fits

This is the problem RapidFort built for. Curated, zero and near-zero CVE images give teams a clean starting point, typically as a one-line change to a base image, and both the images and their open-source libraries are independently validated and scanned for tampering, malware, and the presence of secrets. For teams that want to go further, RBOM hardening removes the files, components, and images that the production application never uses, cutting the software attack surface by up to 90 percent and eliminating up to 99.9 percent of CVEs, with no application code changes. Curated images rebuild every 24 hours, and known-exploited vulnerabilities are targeted within a day.

None of that is a shield that stops an AI attacker. It is something more useful: cleaner inputs, a smaller target, and a shorter window. Those are the variables an automated attack is built to exploit, and they are the ones you can actually control.

The part of the fight that is still yours

AI-driven attacks will increase. The tooling behind them is getting cheaper and more available, and it is safer to assume automated attacks will become the norm rather than exceptional.

One cannot control how fast an attacker moves. One can control what is let into builds, how much is handed to an intruder once it is in, and how long it is left exposed. In a machine-speed world, this is the part of the fight that is still in an organization’s control.