In conversation with … Nate Dunning on Securing the Software Supply Chain in an Age of Growing Cyber Risk

Intro: Scene setting

In an era where open-source software forms the backbone of much of our digital infrastructure, a new wave of supply chain compromises has left developers, enterprises, and security experts reeling. On September 8, 2025, 18 of the most-ubiquitous npm packages, including chalk, debug, ansi-styles and strip-ansi, were hijacked after a maintainer’s account was compromised via phishing. What stands out most from this attack is the worm-like propagation, once a package is compromised it becomes a force multiplier and turns a supply chain attack into a steam engine of additional supply chain attacks.

Just last month, another alarming breach struck the NPM developer when attackers were able to insert malware into “nx”: an open-source code development toolkit. They were able to harvest credentials from unsuspecting users by introducing code that sourced user’s devices for authentication tokens from destinations like GitHub and NPM, as well as SSH and API keys. Perhaps most chillingly, these attacks share many similarities, so could it be the same hostile cyber actor responsible?

These twin incidents are a stark warning: even trusted dependencies, core developer tools, and standard workflows are no longer out of reach for determined attackers. The question isn’t if your supply chain can be compromised, but when, how badly, and how prepared you are.

We sit down with Nate Dunning, Co-Founder of Ossprey, who has been working at the front lines of securing these very pipelines. We explore what we can learn from these incidents and how organisations can build resilience before the next breach.

Section 1: Lessons from Recent Supply Chain Incidents

Q: Recent events like NPM chalk and debug hijacking, the NX Compromise, and the Shai-Hulud campaign have put software supply chain risk in the headlines. What do you think are the biggest lessons organisations should have learned from these incidents?

[Nate Response]

The biggest lesson is that the software supply chain is in the middle of a growth cycle unlike anything we’ve seen before. Incidents like Shai-Hulud, Qix, and NX show how quickly attackers can exploit weaknesses at scale and how unprepared many organisations still are.

One accelerant here is the rise of AI-assisted coding (“vibe coding”). While it unlocks incredible productivity, it also introduces new risks: projects are expanding at unprecedented speed, often with unnecessary complexity from AI-driven package hallucinations. Such as dependencies that no human consciously chose, but which now sit inside production systems.

The takeaway is simple: speed without visibility is dangerous. Organisations need stronger guardrails, automated monitoring, and resilient processes to keep pace with this new development reality. Otherwise, the next supply chain compromise isn’t just likely, it’s inevitable.

Section 2: The Ongoing Challenge of Threat Detection

Q: Despite years of investment in security tools, visibility into the modern software supply chain remains a huge challenge. Why is this still so difficult, and what can organisations do to get better at detecting risks earlier?

[Nate’s Response]

The challenge is genuinely difficult. Security teams must maintain an active inventory of all third party vendors, software components, AI models, extensions, and packages across an organisation. But simply having a list isn’t enough. You need risk ratings, approval thresholds, and processes that enable the business to use the technology it needs without creating unacceptable exposure.

This complexity is exactly why attackers love supply chain attacks. They only need to compromise one corner of an organisation, then expand their reach from there.

What makes this particularly dangerous is that most organisations don’t realise just how large their attack surface actually is. Software package dependencies, particularly transitive dependencies, are an excellent example of this issue.

The hidden iceberg of transitive dependencies

When assessing your software supply chain, you might focus on the packages your engineering team directly installs. However, most exposure is sat “below the waterline.” Each package you use has dependencies, which in turn have their own dependencies and so on.This creates a multiplier effect on your blast radius.

Manage just your direct packages isn’t enough. You must understand the full dependency tree. This requires a robust Software Bill of Materials (SBOM), the ability to risk-assess changes within those dependencies, and do it at a speed that doesn’t hamstring your organisation’s growth.

Why behavioural detection matters more than reputation

The market is flooded with tools offering reputation and signature-based detection. Essentially flagging packages based on their history of good or bad reputation. But this model crumbles when attackers compromise legitimate, trusted vendors.

Recent attacks on SolarWinds, Nx, and tj-actions demonstrate the problem: attackers hijack established trust relationships to gain access, exfiltrate data, and exploit victims further. No amount of reputation checking helps when the trusted vendor itself is the attack vector.

Organisations need to shift toward behavioural detection that can identify anomalous activity, even from previously trusted sources.

Q: AI and automation are often framed as both a solution and a threat. How do you see automation shaping the future of supply chain threat detection, and how should defenders prepare for adversaries using these same tools?

[Nate’s Response]

From the defender and engineer’s point of view - usage and complexity of tools is exploding. We’re seeing vast adoption of AI coding assistants that exponentially increase the speed at which code is generated.

Last year’s Github’s Open Source Survey highlighted that

“AI Adoption is growing. The use of AI tools like GitHub Copilot is on the rise, with 73% of open source respondents reporting they use these tools for coding or documentation” - Github Octoverse 2024

Is all of the generated code good? No. Definitely not. These AI assistants regularly recommend overly-complicated, unnecessary code and hallucinates package dependencies that either aren’t needed or don’t exist. If engineers are not closely scrutinising the recommendations, this code can make its way into production applications. This means that you are now including packages that you don’t need and haven’t been vetted.

Attackers know this and are “package squatting” - creating packages that seem legit, that mimic a real package, and have embedded malicious code. Example: fast_log (legitimate), faster_log (malicious).

In order to keep up with the boom of newly generated code, you need embedded security tooling that works with the engineer to help vet all packages (even transitive dependencies!) are secure. 

Section 3: Open Source as Both Strength and Weakness

Q: Open source forms the backbone of modern applications, but it also creates risk when vulnerabilities emerge - especially when it comes to coding. How should organisations balance the innovation benefits of open source with the need for stronger security assurance?

[Nate’s Response]

Open source is indispensable. Modern software simply can’t survive without it. Organisations that avoid open source will fall behind both technologically and financially. But with that dependence comes responsibility: balancing the undeniable productivity benefits with equally critical security needs.

The right mindset for open source adoption is “trust, but verify.”

You can’t just consume open source blindly. You need systems that ensure each dependency is safe and properly maintained. Crucially, this verification can’t slow developers down. If engineers are stuck waiting for manual security reviews, innovation grinds to a halt.

Two approaches to managing open source security.

1. The Walled Garden: Security as a Gatekeeper

Only permit engineers to use pre-approved, “known good” packages. This relies on your supply chain vendor to have reviewed everything available and constantly re-reviewing each new version…. forever.

This works in highly regulated organisations with low risk postures (e.g. GCHQ, SWIFT, etc), but it can hamper innovation in other organisations that can’t afford to slow down.

2. Security as the Enabler: Real-time Guidance

Imagine an AI security engineer sitting alongside every developer in your organisation, gently guiding their work to ensure it’s fully compliant and secure while being written.

If your software supply chain vendor can’t keep pace with your organisation’s innovation, they aren’t the right long-term partner.

This is why I founded Ossprey. Like any good partner should, our goal is to help engineers ship secure code from the start – not slow them down with barriers. We inspect all open-source packages and dependencies automatically as part of your development workflow, immediately blocking malicious packages while approved components flow through seamlessly.

Section 4: Regulation and Resilience

Q: The UK’s Cyber Security and Resilience Bill (CSRB) and the EU’s Cyber Resilience Act (CRA) are both poised to reshape expectations for security and accountability. How do you see these regulations affecting companies in practical terms?

[Nate’s Response]

The timelines for compliance are about to get very real, very fast. Both the UK’s CSRB and EU’s CRA make secure-by-design the new baseline expectation. It’s no longer a nice-to-have – it’s table stakes.

In practical terms, procurement processes will start requiring Software Bills of Materials (SBOMs) and verifiable provenance for all software components. Vendors that can demonstrate a strong CRA/CSRB aligned posture upfront will quickly become the default choice, saving companies both time and money during procurement. (This is exactly the kind of space where Remitech is built to shine.)

SBOMs: From checkbox to living document

SBOMs aren’t new. They’ve been gathering dust in compliance folders. The problem? We’ve treated them like static artifacts: generate once, file away, forget until audit time.

That approach never worked. In the new era of resilience-first and provenance-first technology, SBOMs bust become living, actionable intelligence. They need to flow seamlessly into your CI/CD pipelines, trigger automated risk assessments when dependencies change, and integrate directly into security review cycles. An SBOM that doesn’t update in real-time or inform immediate decisions isn’t worth the storage space it occupies.  [1] 

The shift from “we have an SBOM” to “our SBOM actively helps to protect us” will separate compliant organisations from genuinely resilient ones.

Why this matters now

The most immediate impact will fall on regulated companies that get pulled directly into scope. For them, the shift may initially feel bureaucratic or like a drag on velocity. But these regulations exist for a reason: after the surge of high-profile supply chain incidents the UK has suffered this year, resilience has to move to the center of the conversation.

The reality is that the era of relying on strong perimeters is over. Organisations need to focus instead of building robust, transparent, and verifiable security capabilities that assume compromise and ensure resilience by design.

Q: Do these moves suggest we’re heading toward greater harmonisation in cybersecurity standards globally, or are we more likely to see a fragmented landscape that companies must navigate region by region?

[Nate’s Response]

On the surface, the landscape looks increasingly complex. The EU’s CRA, UK’s CSRB, the US Executive Order on secure software development, Australia’s security legislation reforms, and China’s cybersecurity laws all have different scopes, timelines, and enforcement mechanisms. Each region is asserting its own approach.

But in practice, global enterprises will need to play by the rules of the most stringent regulations in their customer or user ecosystem. We’ve seen this before: GDPR reshaped global data practices, even for organisations outside the EU, simply because no one could afford to ignore it.

The CRA could become the GDPR for resilience – setting a new global benchmark for how organisations approach supply chain and secure-by-design practices. While the regulatory landscape will always have regional nuances, most companies couldn’t afford to maintain different standards for different markets. The same dynamic is emerging for supply chain security and resilience.

So while on paper the landscape may look fragmented, in reality these laws are likely to push us toward a de facto harmonisation around stronger resilience standards.

Section 5: Looking Ahead

Q: Looking forward, what blind spots in the software supply chain worry you the most? What can we learn from the recent attacks?

[Nate’s Response]

The CVE-less threats. The cybersecurity industry has spent the better part of the last decade creating and improving vulnerability management programs that identify and work to remediate CVEs. There are still pain points organisations continue to mature what good vuln management looks like, but for the most part, if it has a CVE there is a known pattern of management.

However, this falls apart if the supply chain threat isn’t nicely labeled. Malware in open source packages, by definition, aren’t vulnerabilities and don’t come with CVE. This means that all the scanning tools you have will miss nearly all malicious packages.

Q: If you had to give one piece of actionable advice to security leaders right now to strengthen supply chain resilience, what would it be?

[Nate’s Response]

If I could do one thing today: PR-time dependency gating across all repos. Require signed artifacts and block risky packages at merge. If you don’t know which packages are risky, time to bring in a vendor or threat intel feed that specialises in it.

This isn’t another security tool blocking engineers, this is ensuring the correct level of security is in place by default, which enables development velocity and innovation at scale.