AI is changing the software supply chain. Scanning harder is not enough.

Black October should get the attention of every executive responsible for building, buying, or operating software.

Not because every incident grouped under that name was caused by AI. The reporting does not establish that. The more important lesson is what the PHP discoveries demonstrated: AI-assisted vulnerability research can expose longstanding flaws faster than organizations can identify affected systems, test fixes, and deploy patches.

The flaws were real and the clock was short. CVE-2026-109618 and CVE-2026-109619, since named PHP2Shell, are unauthenticated remote code execution bugs reaching back through most of PHP's deployed history. They were patched the same day they were disclosed, on 21 October, and operators worldwide took sites offline while they worked out whether they were exposed. Coverage from AFP and CNBC connects the PHP discoveries to that acceleration — not every incident filed under the Black October label.

That creates a difficult situation for CTOs, CISOs, and CIOs.

The software may have been running for years. It may have passed previous security reviews. It may be embedded in an application the organization did not develop. Then a disclosure changes the risk overnight.

Leadership immediately needs answers:

• Where are we using the affected software?
• Which business services depend on it?
• Is it inside a vendor product or a container image?
• Who owns the response?
• Can we rebuild, test, and deploy a replacement safely?
• How will we verify that the affected version is no longer running?

These are not questions a code scanner can answer by itself. They require an understanding of the entire software supply chain, from the components entering development to the artifacts running in production. The CERT-EU advisory makes the point directly: many products use PHP as a backend and could be affected "even if they do not directly expose a PHP installation."

AI is accelerating discovery. The organization still has to do the operational work.

Change the supply, not just the scan

At RockPoint Cyber, we approach this problem by looking upstream.

Before asking how to find more vulnerabilities, we ask why so much unnecessary code and so many uncontrolled inputs are entering the supply chain.

Scanning remains necessary. Source analysis, dependency analysis, application testing, and runtime monitoring all have a role. But finding problems after software has been assembled cannot be the entire strategy.

Our approach centers on three connected capabilities:

1. Reduce unnecessary code and govern what enters the supply chain.
2. Establish cryptographic trust in how software is built and released.
3. Operationalize software bills of materials so they support real decisions and response.

The objective is not to produce less useful software. It is to deliver the same business capability with fewer unnecessary components, fewer uncontrolled entry points, and better evidence about what gets shipped.

A package that is not in a production image does not need to be patched in that image. An approved dependency with a known origin is easier to govern than a package discovered after deployment. An artifact verified against an authorized build identity and expected provenance has a stronger basis for trust than an image accepted because its registry tag looks familiar.

This changes the work from repeatedly processing findings to reducing the conditions that create exposure. AI makes that change more urgent, because it affects both how weaknesses are discovered and how software is produced.

AI changes more than the code developers write

Most discussions about AI in development begin with generated code. Did the assistant introduce a vulnerability? Did it choose an unsafe function? Did someone review its output?

Those questions matter, but they cover only part of the problem.

AI assistants can also recommend dependencies, read repository content, modify build workflows, generate tests, and execute commands. As these tools become more capable, their permissions and inputs become part of the software supply chain.

Research identifies two particularly relevant risks. Models recommend packages that do not exist, creating an opportunity for attackers to publish under those names — measured across Python, JavaScript, and Rust in Importing Phantoms. Agentic coding assistants also encounter malicious instructions embedded in material they read, including rules files, code comments, and issue threads, which becomes a prompt-injection problem the moment that material influences a privileged action. A systematic analysis of agentic coding assistants traces those paths through to shell execution and credential theft.

The executive issue is the trust boundary.

A package recommendation is not a procurement decision. A README is not an authorized instruction. A generated workflow is not an approved change simply because it works.

When an assistant can turn those inputs into installed software, executable commands, or pipeline changes, an organization needs controls around the action, not just a review of the final text.

That means treating an AI coding agent as a development identity with defined permissions and accountability. Its authority should be limited to the task. Its changes should remain reviewable. Access to secrets, publishing credentials, and production systems should not become an accidental side effect of convenience. That is the scope of our AI Code Governance Starter.

The answer is not to remove AI from development. It is to integrate it without quietly expanding what the organization trusts.

The attack follows the software lifecycle

The traditional cyber kill chain describes how an attacker progresses from reconnaissance to an objective. For software producers, that progression can intersect with almost any stage of the SDLC.

An attacker might seek access to a developer account, introduce an upstream dependency, alter a build workflow, substitute an artifact, or exploit software already deployed.

AI does not make every one of those techniques new. It introduces additional ways to research targets, generate convincing content, and interact with development workflows. The defense still has to address the underlying paths to compromise.

The lifecycle groups into four connected stages — plan and develop, then source and build, then publish and deploy, then operate and respond — and an attacker has an opportunity at each handover. The table maps representative opportunities to control objectives. It is a threat model, not a claim that every path has been observed in one campaign.

SDLC stage	Representative attack opportunity	Control objective
Plan and design	Sensitive information exposed through ungoverned AI use	Define data boundaries and accountable owners
Develop	Unsafe generated code or a prompt-injected agent	Scope permissions and review changes
Source and dependencies	Malicious packages or compromised upstream inputs	Govern intake and reduce unnecessary dependencies
Build and test	Workflow tampering or stolen build credentials	Isolate builds and protect identities
Package and publish	Artifact substitution or unauthorized publishing	Bind signatures, provenance, and SBOMs to artifacts
Deploy	An unverified release accepted into production	Verify evidence against release policy
Operate and respond	A new vulnerability with unknown deployed exposure	Connect inventory, ownership, response, and verification

This is why securing application code is not the same as securing software delivery.

A compromised build environment can undermine a reviewed repository. An unauthorized publisher can bypass the assumptions behind a trusted package name. An incomplete deployment inventory can delay the response to a critical disclosure.

The transitions between stages deserve as much attention as the code inside them. If you want to see which of these you already cover, the Secure Pipeline Builder lays the stages out against the controls that sit on them.

Reduce what the organization has to trust

Reducing the supply of code starts with understanding what is necessary.

A production application may need a runtime and a defined set of libraries. It may not need the compiler, package manager, debugging utilities, and unrelated packages that came with its base image.

A team may need a new capability. It may not need another overlapping framework or a dependency selected because an assistant produced a plausible package name.

We examine the inputs that accumulate across delivery:

• Direct and transitive application dependencies.
• Container base images and runtime packages.
• Build tools, plugins, and reusable workflows.
• Package registries and dependency sources.
• Duplicate libraries and overlapping platforms.
• Unsupported components without a practical replacement path.

The question is not whether every component has a published vulnerability today. It is whether the component is necessary, where it came from, who maintains it, and how it will be replaced when circumstances change. That is the work in an Estate Rationalization Review, and the overlapping-investment half of it is what Vendor Risk Rationalization was built to answer.

There is an important limit here. Removing unrelated packages will not fix a flaw in a runtime the business actually requires. PHP2Shell is the case in point: nothing about a smaller image would have removed PHP from an application that is written in PHP. Necessary components still need maintenance and timely updates.

Reduction makes that responsibility more manageable. It does not eliminate it.

Establish trust through evidence

Many software delivery systems rely on assumptions that have become familiar enough to feel like controls.

The package came from the usual registry. The image has the expected name. The pipeline finished successfully. The publishing account has always had access.

None of those facts, alone, establishes why a particular artifact should be trusted.

Cryptographic signatures help bind an artifact to a signing identity and detect changes to its contents. Build provenance provides evidence about how the artifact was produced and its relationship to source and build inputs. SLSA describes provenance as verifiable information that traces an artifact through the supply chain to its origin.

That evidence needs to be evaluated against expectations. Was this the authorized builder? Was this the expected repository? Does the evidence refer to the exact artifact being deployed? Does the release meet policy?

A release path that answers those questions runs approved source and inputs through a controlled build, emits the artifact together with its signature, provenance, and SBOM, and then checks that bundle against release policy before anything deploys. What happens next is the part worth designing deliberately:

Verification outcome	What should happen
Pass	Deploy
Exception	Proceed with a named owner and an expiry date
Fail	Block, with feedback that says what to fix

Signing is not a declaration that software is safe.

A signed artifact can still contain vulnerable code. A compromised authorized builder can still produce a harmful release. Provenance explains production; it does not certify correctness.

The value comes from combining protected identities, controlled builds, verifiable evidence, and explicit deployment policy. The identity half of that is its own engagement — a Trust and Identity Audit — because publishing credentials and build identities are where this most often turns out to be thinner than assumed.

For leadership, the outcome is an answer to a basic question: why did we allow this software into production?

Turn the SBOM into an operational capability

An SBOM should be more than a file produced for an audit or a customer request.

Its value increases when component information connects to the artifact that contains it, the environment running that artifact, the service it supports, and the team responsible for it.

Consider a newly disclosed vulnerability. In a document-centered process, teams collect SBOMs, search for component names, compare results, and then try to reconcile them with deployment inventories and ownership records.

In an operational process, those relationships already exist, and the response runs in order:

1. An advisory names affected components.
2. SBOMs match those components to artifacts.
3. Artifacts resolve to deployments, services, and owners.
4. Teams prioritize, rebuild, test, and redeploy.
5. Verification confirms the affected releases are gone.

The difference is not simply faster searching. It is the ability to move from "we use this library somewhere" to "these deployed services require action, these teams own them, and this is how we will verify completion." That is exactly the gap the Exposure Answer engagement closes, and PHP2Shell is the kind of morning it is built for.

An SBOM does not automatically establish exploitability or runtime reachability. It also cannot compensate for missing deployment data. Those limitations should be visible.

Unknown is not the same as unaffected.

Gantry helps us start downfield

Connecting the entire software supply chain is why we have spent more than a decade developing Gantry.

Gantry is RockPoint Cyber's software supply chain knowledge graph. It provides a model of the relationships among capabilities, threats, controls, tools, and evidence, so an engagement does not begin as a disconnected collection of product reviews.

These are relationship problems.

A tool may support a control, but only in certain configurations. A control may address a threat in the build system while leaving the publishing path exposed. Several products may duplicate one capability while an important verification step remains unowned.

A list of tools does not explain those relationships. A graph gives us a structured way to examine them. The Periodic Table of Software Supply Chain Security is one view of it, running live against the graph rather than from a cached copy.

The football analogy is straightforward. We do not want to spend the opening weeks of an engagement trying to move off our own one-yard line by rebuilding the basic model of software supply chain security. Gantry lets us start downfield and focus earlier on the client's actual decisions.

That does not mean we arrive already knowing the environment. We still validate architecture, delivery practices, business constraints, and evidence. We distinguish what is modeled from what is implemented, and what is implemented from what has been verified.

The advantage is a prepared analytical foundation, not a shortcut around discovery. That foundation helps us identify unnecessary exposure, gaps in trust, overlapping investments, and practical modernization priorities.

Security should improve the delivery system

RockPoint Cyber's founders come from software development as well as cybersecurity. We have spent decades inside the SDLC, building and supporting the systems that security controls must work within.

That background matters.

A policy that repeatedly interrupts routine work is not a finished implementation. A release gate that says "blocked" without explaining the fix transfers the problem to engineering. A control that depends on recurring manual effort is difficult to sustain.

Our Supply Chain Modernization work focuses on making the supported delivery path the secure path:

• Approved components are easy to find and consume.
• Maintained runtime images reduce avoidable package exposure.
• Build pipelines generate evidence automatically.
• Developers receive useful feedback early.
• Routine releases pass through automated verification.
• Exceptions have clear ownership, justification, and expiration.
• Remediation includes verification in the deployed environment.

Enforcement should follow evidence. Start with visibility, test policies against actual delivery behavior, resolve avoidable friction, and progressively enforce the requirements that matter. Where a program has nothing in place yet, the First Ten Controls is the shortest honest version of that sequence.

The goal is stronger security without a standing developer-speed tax.

That is different from promising that nothing will ever be blocked. Some releases should stop. The important distinction is whether the interruption is intentional, proportionate, and actionable.

Developer velocity belongs in the success criteria alongside security coverage.

Measure readiness, not just findings

Executives need to know whether the organization can manage the next disclosure, not simply how many vulnerabilities its tools found last month.

A useful scorecard connects security to operational performance.

Leadership question	Evidence of progress
Are we reducing unnecessary software?	Fewer unnecessary dependencies and runtime packages against a defined baseline
Can we explain why releases are trusted?	Verified artifact identity, authorized builders, provenance, and policy coverage
Can we locate affected systems?	Current relationships between components, artifacts, deployments, and services
Can we act quickly?	Time to identify affected services, assign owners, and complete remediation
Are controls preserving delivery speed?	Policy-related delays, false blocks, exception volume, and resolution time
Did the fix reach production?	Verified replacement of affected deployments, not just closed tickets

These measures need to be read together.

A faster pipeline is not an improvement if it bypasses verification. More security gates are not an improvement if teams routinely work around them. An inventory is not reliable merely because it contains a large number of records.

The objective is a delivery system that is both easier to trust and easier to operate.

Prepare for the next disclosure

Black October does not prove that every attack is now an AI attack.

It shows why the gap between discovery and response deserves executive attention. AI-assisted research helped expose critical PHP weaknesses, while organizations still had to identify their exposure and carry out the work of protecting their systems. Reporting on the resulting patching effort makes that operational burden clear.

Buying more detection without changing the delivery system leaves that gap largely intact.

The more durable response is to reduce unnecessary inputs, establish verifiable trust, and connect software evidence to the services the business actually runs.

That is the work RockPoint Cyber focuses on: modernizing the software supply chain so security becomes part of how software moves, rather than another queue it waits in. If you want to find out where your own program sits, a Supply Chain Diagnostic is where most engagements start.

The central issue is control. What enters the supply chain, how it is built, what reaches production, and how quickly the organization can respond when the facts change.