Supply chain attacks enter through connected suppliers or software rather than directly breaching a company's internal systems.
Companies depend on cloud platforms, SaaS, payment processors, contractors, APIs, open-source packages, and AI tools. Some of these can access internal systems or sensitive data (p.20).
AI does not create vulnerabilities that were not there.
It does, however, accelerate attackers' ability to find, understand, and exploit vulnerabilities, making weak links in the supply chain easier to discover (p.20).
Responses to supply chain attacks must therefore change too.
Move beyond annual questionnaire responses and manage supplier security through evidence that can be tracked and rechecked to establish its basis and whether it remains valid (p.21).
What our company depends on
A company's security increasingly depends on the security of connected organizations and software.
Begin by reviewing who has access, what data they handle, and what software is brought in (p.20).
| Dependency | Example | What to check |
|---|---|---|
| Cloud | Server and storage platforms | What data is uploaded? |
| SaaS | Online business services | Who can access what? |
| Payment processing | Payment processors | What customer information do they handle? |
| Contractors | Development and operations partners | Do they have access to internal systems? |
| APIs | External service integrations | Which activities depend on them? |
| Open source | Public packages | What software is brought in? |
| AI tools | Coding and business AI | Permissions and scope of connections |
Attackers do not need to confront the strongest company's defences head-on.
If a small supplier, contractor, or software dependency already has a trusted route in, attackers use it (p.20).
Merely listing supplier names when reviewing supply chain attacks will not reveal these connections.
What AI gives attackers is speed
Attackers use AI to process technical documents, find public information at scale, create or modify tailored phishing messages and scripts, and analyze exposed services.
These tasks previously required far more manual work (p.20).
As a result, weak connections in the supply chain have become easier to find, lowering the barrier to supply chain attacks.
This is why even companies with strong internal controls must examine third-party risks arising through trusted external routes (p.20).
A supply chain attack case: phantom packages invented by AI
At a large educational and research institution, researchers and teaching assistants used autonomous AI coding agents to build curricula and internal research tools.
The agents repeatedly invented nonexistent package dependencies, or “phantom libraries” (p.16).
The sequence was as follows (p.16-17). Attackers tracked the package names the agents repeatedly invented.
They registered packages containing malicious code under those names in public repositories.
Automated builds subsequently retrieved the packages.
Sensitive academic research materials and institutional intellectual property were quietly exfiltrated.
The industry also calls this practice of targeting invented package names “slopsquatting.”
AI coding agents had become a new entry point for a supply chain attack.
Why annual questionnaires are insufficient
Supplier security questionnaires are useful for gathering information.
However, their answers depend on suppliers' self-reporting, and submitted information quickly becomes outdated.
Customers must check what evidence supports the answers, whether it is current, and what has changed since the last review (p.20).
The key is not whether the questionnaire was answered correctly.
What matters is whether the trust decision can still be explained months later (p.20).
Five ways to manage supply chain security through evidence
The contribution proposes moving from security “claims” to “evidence” that can be tracked, versioned, and rechecked (p.21).
| Action | How to do it |
|---|---|
| Map dependencies | Record not just supplier names but access scope, data handled, software introduced, and activities that depend on them |
| Require evidence | Review penetration test reports, certifications, policies, remediation records, and independent assessments alongside answers |
| Preserve provenance | Record who supplied the evidence, when it was approved, which version was reviewed, and whether it changed afterward |
| Keep sensitive evidence private | Encrypt reports and control access. Blockchain can record only fingerprints, timestamps, and ownership records without uploading documents |
| Maintain continuous trust | Make evidence expiry, changes, and replacement visible rather than relying on a year-old snapshot |
Development teams must also control how packages enter their systems.
Prevent unrestricted access to public repositories by AI coding agents and build pipelines. Accept only packages that have passed cryptographic provenance verification, package age requirements, and automated behavioural checks through private mirrors (p.17).
An easily overlooked trap
The most dangerous assumption is that something true at review remains true today.
Penetration test reports are superseded, and certifications expire.
Vulnerabilities thought to be closed reopen, and suppliers' environments change.
Meanwhile, customers continue relying on the same PDFs and questionnaire answers (p.21).
The interval between a change in a supplier's security posture and the customer's discovery of it is itself an attack surface (p.21).
Recording provenance and change history does not by itself prove a security claim true.
Bad evidence remains bad evidence (p.21).
Frequently asked questions
Q1. Can small and medium-sized companies face supply chain attacks?
Yes. If a small supplier or contractor has a trusted route to a large customer, an attacker can exploit it (p.20).
Start by mapping dependencies, including the SaaS and open-source packages your company uses.
Q2. What should we request from suppliers?
Request evidence supporting their questionnaire answers.
For high-risk items, review penetration test reports, certifications, policies, remediation records, and independent assessments. Record who supplied them, when they were approved, which versions they are, and whether they changed afterward (p.21).
Q3. Should we stop using AI coding tools?
No. KCBCA Signals also asks how to reduce phantom dependency risks without significantly undermining the speed of AI coding (p.7).
The answer is boundaries rather than a ban.
Require packages to enter only through private mirrors (p.17).
Key points
- Supply chain attacks enter through connected suppliers and software
- AI accelerates the discovery and exploitation of weak links
- There have been cases where package names invented by AI returned as malicious packages
- Move beyond annual questionnaires and manage security with current evidence that can be rechecked
Future supply chain security will be judged less by the number of questionnaires sent and more by whether current evidence explains why a supplier remains trusted (p.21).
Read KCBCA Signals Vol.1 Issue 1
References: KCBCA Signals Vol.1 Issue 1. Rob Goehring (Wisr.ai CEO), p.20-21; Jack Wong (KCBCA GLOBAL director), p.16-17; discussion questions, p.7
