DEF CON 33 in Las Vegas wrapped the week after Black Hat, and where Black Hat's supply chain program felt engineered and polished, DEF CON's felt alive. The main track briefings, the Packet Hacking Village demos, and especially AppSec Village produced a constant stream of new attack techniques, tooling releases, and "here is the weird edge case nobody noticed" talks that only DEF CON consistently delivers.
For defenders working on software supply chain, DEF CON 33 was less about polished vendor narratives and more about the raw capability growth of the attacker side of the house. Here is the take-home.
What was different about supply chain content at DEF CON 33?
It got more specific. In past years, DEF CON supply chain talks often operated at the level of "look at these wild things you can do with npm." In 2025, the talks were more targeted: specific ecosystems, specific classes of attack, specific CI/CD providers, specific package managers whose trust models had a weak assumption that nobody had stress-tested yet.
The research in AppSec Village especially reflected this shift. Multiple talks demonstrated end-to-end attack chains that started with a single low-privilege foothold and ended with artifact-level compromise of production builds. Others looked at less-examined registries — Go modules, Terraform Registry, Helm charts, VS Code extensions — and showed that the security assumptions baked into the more mature ecosystems (npm, PyPI, Maven) are not universal.
The implication for defenders: if your security program has a coverage model built around your top three package managers, DEF CON 33 was a clear signal that attackers are not constrained by that same scope. Every registry your developers pull from is part of the attack surface, and the less-famous ones are often the least hardened.
Which package ecosystems took the most heat?
npm remained the favorite target, but the most interesting new research was outside of it. Several talks at AppSec Village demonstrated novel attack primitives against VS Code and JetBrains plugin marketplaces — extensions that can read the user's entire source tree, call out to remote servers, and execute arbitrary code are frequently published with minimal review. Because developer machines typically have broad access to source repositories, secrets, and cloud credentials, a compromised extension can compromise an entire team.
Container registries also got fresh attention. Talks explored attacks on Docker Hub tag handling, OCI artifact confusion, and registry-level mirror substitution where a misconfigured pull-through cache could serve attacker-controlled images to downstream consumers. These are not theoretical — the demos included working proofs of concept.
A third thread was registry infrastructure itself. Several talks and hallway conversations focused on how package registries handle account recovery, email change flows, and 2FA enforcement. The pattern that emerged is that registry security is improving rapidly at the package-level (trusted publishers, provenance attestation) but account-level security — the ability for an attacker to hijack a maintainer's identity — remains inconsistent across ecosystems.
What did CI/CD abuse demos show this year?
That the depth of trust CI systems extend to external inputs remains the most exploitable property of the modern software factory.
The demos ranged from fresh primitives to refined exploitation of well-known issues. Researchers showed how reusable GitHub Actions and GitLab includes can be subverted when tags are mutable; how cache poisoning in language-specific runners (pip cache, npm cache, Go module proxy) can persist across unrelated builds; and how environment variable ordering in shared runners can leak secrets between jobs.
A particularly memorable AppSec Village segment walked through a realistic scenario: a pull request from a fork triggers a workflow that runs on a self-hosted runner, which has network access to internal systems, which are reachable from the build environment even though the repository is ostensibly public. The attacker never needed to compromise a maintainer account or a build server. They just needed to notice that the workflow trigger configuration was slightly too permissive.
For defenders, the actionable pattern is clear: audit workflow triggers, scope runner network access, and treat every pull_request_target and equivalent cross-fork trigger as a potential initial access vector.
Were there notable open-source tool releases?
Several. DEF CON has always been where researchers drop tools they have been sitting on for a year, and 2025 was consistent with that tradition.
New open-source work presented or referenced during the conference included package-trust evaluators (tools that score packages based on maintainer behavior, update patterns, and known indicators of compromise), CI workflow scanners (linters that flag risky patterns in GitHub Actions and GitLab CI configurations), and artifact provenance verifiers (utilities that check signatures and attestations on in-toto, SLSA, and Sigstore artifacts).
The quality of these tools varies. Some are production-ready and already being adopted by major enterprises; others are research prototypes that demonstrate a point but are not yet suitable for daily use. The right posture for defenders is to evaluate them carefully — DEF CON tool releases tend to become the standard tools of the following year's security programs if they are good, so it is worth tracking which ones get momentum in the months after the conference.
What community themes emerged from the villages?
Three stood out. First, a growing frustration with how slow the ecosystem is to respond to clearly documented risks. Presenters and attendees repeatedly pointed out that many of the attacks being demonstrated had been theoretically possible for years, and that registries and CI providers are still catching up to threat models that researchers have been publishing since at least 2020.
Second, a sharper focus on the developer as the unit of compromise. Supply chain attacks that start at the developer workstation — via a malicious VS Code extension, a compromised npm dev dependency, a trojanized CLI tool — bypass most of the controls organizations have invested in at the CI/CD layer. Several village discussions centered on how to extend the same level of scrutiny defenders apply to production systems to the endpoints where code is written and committed.
Third, an acknowledgment that artifact provenance is necessary but insufficient. SLSA, Sigstore, and in-toto solve the problem of knowing that an artifact came from the build system it claims to have come from. They do not solve the problem of whether the source code itself was what it appeared to be, whether the maintainer account was legitimate, or whether the build pipeline had been subverted before the signature was applied. The maturing consensus: provenance is a layer, not the whole solution.
Which DEF CON 33 sessions should defenders prioritize watching?
If you only have bandwidth for a handful of recordings, focus on three areas: the AppSec Village talks on developer tooling compromise, the main-track briefings on CI/CD pipeline abuse, and the tool-drop segments where researchers walked through new defensive tooling. The talks in these areas tend to produce the highest actionable signal for defenders, whereas the more exotic exploitation research is often interesting but less directly relevant to program prioritization.
It is also worth watching the villages broadly. DEF CON's format rewards browsing — the best supply chain insight of the week might come from a Cloud Village talk, a Car Hacking Village demo where the target happens to use a vulnerable Yocto recipe, or a hallway conversation that sparks an audit idea. If you can rewatch village content, do.
How Safeguard.sh Helps
The themes from DEF CON 33 map directly to what Safeguard.sh was built to address. Our package risk intelligence evaluates dependencies across ecosystems — including the less-famous ones researchers spent the week poking at — and surfaces maintainer trust signals, suspicious update patterns, and known-malicious indicators before code lands in a build. Our CI/CD scanner analyzes GitHub Actions and similar workflow definitions for the same risky patterns that AppSec Village demonstrated end-to-end exploitation of: mutable action references, overly broad workflow permissions, and misconfigured cross-fork triggers. And because Safeguard combines reachability analysis with provenance verification, we let your team distinguish between a technically present vulnerability and one that actually matters in production — so when a DEF CON-style attack technique becomes a real-world incident, your triage queue is already focused on the findings that are exploitable in your environment.