A conversation with Nigel Douglas, Head of Developer Relations at Cloudsmith, explores why teams struggle to track dependencies and avoid supply chain compromises. Topics covered include transitive dependency risk, why attackers have shifted from ransomware to compromising widely-used packages for better return on effort, the value and limitations of SBOMs (using log4j as a case study), and why platform engineering teams, rather than security teams alone, are best positioned to own supply chain security by baking scanning tools and curated registries into golden paths. The discussion closes on AI accelerating both vulnerability discovery and attack capability, dubbed the 'vulnpocalypse.'
Table of contents
Watch the episodeYou don’t know what you don’t knowAttackers have moved from ransomware to poisoning the wellSBOMs are only useful if you keep themPlatform teams are well positioned to ownWhere this is headingTags:Questions this post answers
Why have supply chain attacks increased compared to ransomware in recent years?
Attackers are rational actors optimizing return on effort: ransomware against a single company may not even result in payment, while compromising one maintainer account on a package downloaded a hundred million times a month affects far more targets for similar effort. Nation-state and organized groups have realized supply chains offer better scale for the same work, not that they only recently discovered them. Teams weighing where to invest security effort can follow supply chain risk analysis like this on daily.dev.
Why is generating an SBOM not enough to manage software supply chain risk?
An SBOM becomes stale within hours because dependencies and their own transitive dependencies keep shifting underneath a build, so the hard part is keeping it current, not generating it once. Capturing SBOMs at every build and storing them in a tool like Dependency-Track turns an incident like log4j into minutes of querying instead of hours of manual auditing across every application. Anyone building an SBOM strategy can track practical dependency-tracking approaches on daily.dev.
Should platform teams or security teams own software supply chain security?
Platform teams are better positioned to own it because they already control what goes into the build process and the golden paths developers use, while a CISO can only set policy without building those paths. This means baking in tools like OSV scanning at the edge or routing developers through a curated package registry falls naturally to platform engineering rather than a separate security team. Platform engineers deciding who owns supply chain tooling can follow this debate on daily.dev.