For years, the technology industry has embraced the mantra “move fast and break things.” While this approach has accelerated innovation, it has also quietly expanded the attack surface — particularly through third-party software and services.
From open-source libraries to AI-enabled coding assistants, modern development tools are helping organisations move faster than ever. Unfortunately, these same tools are also introducing new vulnerabilities into the software supply chain, creating attractive opportunities for threat actors.
Third-party risk is not a new problem, but its scale, speed, and complexity have changed dramatically.
Why Third-Party Risk Matters More Than Ever
Historically, ransomware and direct attacks dominated cybersecurity priorities. More recently, nation-state threats and cyberwarfare have drawn attention. However, regardless of motive, attackers consistently target the software supply chain because it offers high impact with low effort.
No matter how strong your internal controls are, a trusted vendor or embedded software component can still provide attackers with a pathway into your environment.
Two major incidents brought this reality into sharp focus:
-SolarWinds (2020) demonstrated how a compromised software update could quietly grant attackers access to thousands of organisations, including government agencies.
-Log4Shell (Log4J) revealed how a widely used open-source library could expose hundreds of millions of systems almost overnight.
These incidents showed that visibility into third-party dependencies is just as critical as perimeter security.
The New Risk: AI-Assisted Development
As generative AI tools become embedded in development workflows, a new category of third-party risk has emerged.
AI-enabled coding assistants can significantly improve productivity, but they are also prone to hallucinations — generating references to software libraries that do not exist. Threat actors have begun exploiting this behaviour by registering malicious packages under those hallucinated names.
Developers, trusting the AI output, unknowingly integrate these malicious components into their applications. This technique has been labelled “slopsquatting,” due to its similarity to typosquatting and cybersquatting.
This represents a shift in supply-chain risk:
The threat is no longer just upstream vendors
It now includes AI-generated dependencies introduced during development
A Longstanding Problem, Now at Scale
Supply-chain attacks are not new. Attempts to insert malicious code into open-source projects date back decades. What has changed is the scale and speed at which vulnerabilities can spread.
Open-source libraries are embedded into countless applications and systems, including operational technology (OT) environments where patching is slow or impossible. When vulnerabilities emerge, organisations often struggle to answer a simple question:
Where are we exposed?
Without clear visibility into dependencies, remediation becomes reactive, expensive, and disruptive.
Shifting Left: Managing Risk Before the Breach
A common theme across modern third-party risks is the need to act earlier.
In development, this is known as “shift left.”
In cybersecurity, it is often described as operating “left of boom.”
Both approaches focus on identifying and reducing risk before it is exploited.
Key foundations include:
- -Visibility of software dependencies
Using Software Bills of Materials (SBOMs) to track where components come from and how they are used.
- -Security testing throughout development
Static (SAST) and dynamic (DAST) testing to uncover vulnerabilities early.
- Comprehensive asset inventories
Understanding which systems matter most and what the business impact would be if they were compromised.
- Behavioural monitoring and detection
Identifying unusual activity, connections, or system behaviour — an area where AI can be used defensively to detect anomalies at scale.
Securing AI-Enabled Development
AI tools are here to stay, but they must be used responsibly.
Developers should:
- Treat AI-generated code as untrusted by default
- Embed security requirements directly into prompts
- Enforce human review, authentication controls, and input validation
- Apply consistent application security testing before deployment
Security teams and DevOps must work together to ensure that speed does not come at the cost of resilience.
Looking Ahead
The evolution from open-source risk to AI-driven supply-chain risk highlights a broader reality:
Trust in software can no longer be assumed — it must be continuously verified.
As third-party ecosystems grow more complex, organisations that invest in visibility, proactive risk management, and collaboration between development and security teams will be far better positioned to reduce exposure before attackers strike.