Most teams can’t easily list every dependency holding their software together. That is the gap I wanted to explore with Nigel Douglas, Head of Developer Relations at Cloudsmith, who spends his days helping developers understand and avoid supply chain compromises.
I’ll admit going in that this wasn’t a topic I’m fully across. I know enough to be dangerous, as I said to Nigel at the start, but I came away from this conversation with a much clearer picture of just how much of what we run in production came from outside our own codebase, and how little visibility most teams have into it.
Watch the episode
You can watch the episode with Nigel below.
Inside Platform Engineering with Nigel Douglas
You don’t know what you don’t know
Nigel’s framing early on was great. Every library, every scanning tool, every base image you pull in is something someone else built, and each one is a new door into your environment. He used Falco as an example, a tool he uses for detection, and pointed out that the moment you adopt it, you’ve inherited whatever risk lives inside it. Multiply that by every dependency, and every dependency’s own dependencies, and you get what he called transitive dependencies stacking up into a problem nobody can fully see. As he put it, you don’t know what you don’t know. The real challenge is knowing what’s in your software stack across your organization, not just whether it’s secure.
Attackers have moved from ransomware to poisoning the well
One of the most interesting parts of the conversation was Nigel’s read on why supply chain attacks have ramped up in the last couple of years, and his theory is refreshingly practical. Nation-state actors and organized groups are rational actors chasing the best return on effort. Ransomware against a single company might not even get paid. Compromising one maintainer account on a package downloaded a hundred million times a month is a far more lucrative outcome for the same amount of work. These groups didn’t suddenly discover supply chains, but instead realized the return on effort favors them there, given the scale.
SBOMs are only useful if you keep them
We spent a good chunk of the episode on software bills of materials (SBOM), and Nigel was honest that adoption is still low despite SBOMs being, in his words, a fantastic technology. Generating one isn’t the hard part, but keeping it useful is, since an SBOM is stale within hours as dependencies and their own transitive dependencies keep shifting underneath you.
His point about log4j resonated with me as I too lived through it, knowing the library was in use somewhere without knowing exactly where, then facing an uphill audit across every application to find the affected versions. If you’d been capturing SBOMs at every build and storing them somewhere like Dependency-Track, that same exercise becomes minutes of querying instead of hours of manual digging. Nigel compared this with insurance, where nobody cares about it until the moment something goes wrong, and that’s exactly the moment you need the historical record already sitting there.
Platform teams are well positioned to own
What I liked most about Nigel’s take is that he doesn’t see supply chain security as a bolt-on security team responsibility, he sees it as squarely a platform engineering job. A CISO can set the policy, but they’re not the ones building the golden paths developers actually use. Platform teams are already the ones deciding what goes into a build process, so they’re well placed to bake in tools like OSV scanning at the edge, or to route developers through a curated registry rather than pulling blindly from the public internet. His broader point was that the open tooling to do most of this already exists and is free, so the barrier really is accountability and ownership rather than a lack of technology.
Where this is heading
Nigel didn’t sugarcoat the trajectory. AI is accelerating both vulnerability discovery and attackers’ ability to write and plant bad code, something he called, half jokingly, the “vulnpocalypse.” The volume of threats isn’t going to shrink, but he was equally clear that the defensive side has kept pace. The open source tooling for scanning, tracking and hardening what you run has matured fast, and platform teams have little excuse not to have a handle on this today.
AI’s impact on supply chain security is a topic I think I’ll get Nigel back for, so we can hyper-focus just on that one aspect of software development, and dig into both the positive and negative impacts.
Happy deployments!
Inside Platform Engineering is a series of conversations with Matt Allford and a guest, bringing their own experience and perspective from the world of Platform Engineering.
You can find more episodes on YouTube.
