From XZ
to NPM

The new normal.

Twelve days in March. Five open source projects compromised. Every one of them sits inside infrastructure you're probably running right now.

1. Date Project What it is Blast radius
2. 2026-03-19 Trivy Container scanner C2 hits in 12,000+ public repos
3. 2026-03-23 Checkmarx KICS IaC scanner 5M+ Docker pulls
4. 2026-03-24 LiteLLM AI gateway 95M downloads/month
5. 2026-03-27 Telnyx SDK Telephony SDK 742K downloads/month
6. 2026-03-31 Axios HTTP client for JS 100M downloads/week
7. ????-??-?? ? ? Next week, next month, next ?

Matt Crozier.

Lead DevSecOps / Cyber Security Consultant @ Sekuro.

Experience spans startups, enterprises, government, and critical infrastructure.

Background in platform engineering and network engineering.

Three things, 30 minutes.

1. 01 Supply chain attacks 101 Overview of the modern software supply chain.
2. 02 The TeamPCP case study A brief overview of a recent campaign targeting Trivy.
3. 03 Five gaps I see every engagement And the controls that actually close them.

Visualising the modern
software supply chain.

Most orgs defend a slice, usually just the running app. Modern attacks land upstream in humans, pipelines and dependencies.

From rare to routine.

Cumulative malicious open source packages tracked across npm, PyPI, Maven, NuGet, and Hugging Face.

The four steps. Trivy compromised.

# .github/workflows/ci.yml
- uses: actions/checkout@v6
- name: Build an image from Dockerfile
  run: docker build -t docker.io/my-organization/my-app:${{ github.sha }} .
- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@v0.34.2 # rewritten for ~12h on Mar 19, 2026
  with:
    image-ref: 'docker.io/my-organization/my-app:${{ github.sha }}'
    severity: 'CRITICAL,HIGH'

Two PR triggers. One word apart.
Total opposites.

GitHub Actions has two ways to run a workflow when a PR is opened. They look almost identical. They behave nothing alike. GitHub now flags it.

on:
  pull_request_target: # ← not pull_request
jobs:
  pre-merge-thing:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with: 
          ref: "${{ github.event.pull_request.head.sha }}" # fork code, full secrets
      - run: go run do_a_thing.go

No one owns the bridge
between dev and security.

Most security teams have minimal, often zero presence in the SDLC, and when they do engage, it's far too late. Dev teams get handed generic, non prescriptive requirements that fail to translate into controls they can actually ship. The result: shouting across the gap.

Check your org.

If any of these sound familiar, nobody owns the bridge.

• →CI changes ship without security review.
• →“Security review” means “ask security the day before release.”
• →Your security team owns a SIEM, an EDR, a CSPM, a CNAPP, and an ASPM. They do not own a seat in sprint planning.
• →Your vulnerability dashboard has 14,000 open findings. Nobody has time to triage.
• →Penetration test findings get a Jira ticket. Jira tickets get a label. Labels get a dashboard. Dashboards get a screenshot in a board pack.
• →Your SOC can enumerate MITRE ATT&CK. Not one analyst has read a GitHub Actions workflow.

You can't secure
what you can't see.

70 to 90% of the average application is open source. Most orgs have no idea what's in production.

• → Generate SBOMs in CI. Every build, aggregated and queryable.
• → Run continuous SCA. Every push, against the locked graph, not just the manifest.
• → Watch maintainer health, not just CVEs. OpenSSF Scorecard, Socket, deps.dev.
• → Invest in a CNAPP. See which prod workload is running which dep, with context.

Non prod is often where
attackers land first.

Security teams pour budget into prod monitoring. Dev and staging often get nothing: no logging, no segmentation, sometimes direct connectivity to prod.

• → Network isolation first. Fastest to implement, hardest to work around.
• → Separate IAM per environment. No shared roles across dev, staging, prod.
• → Don't share data stores. Surprisingly common. Same RDS or Mongo across envs means a dev compromise reads prod data.
• → Avoid click ops dev environments. Same IaC patterns and guardrails as prod: log retention, region lockdowns, tagging.
• → Include non prod in your SIEM. You won't catch what you don't log.

Commit access is deploy access.

The same repos protecting the kingdom often let anyone with commit access push straight to main.

• →Enforce branch protection on main. No direct pushes, no force push, required PR, linear history.
• →Require reviewers, not your own. Minimum one approver, block self approval.
• →Use CODEOWNERS for sensitive paths. CI configs, IaC, release scripts, auth code.
• →Audit access quarterly. Rotate stale PATs, remove ex employees, downgrade over scoped tokens.
• →Require signed commits. gitsign beats PGP: keyless, OIDC backed, no long lived keys.

You don't have a runbook for this.

Teams drill ransomware, credential dumps, DDoS. Nobody drills "the npm package we depend on shipped malware overnight." Axios lands at 2am. The first hour gets burned figuring out who to wake up. Zero orgs I've worked with have rehearsed this scenario.

• → Build the runbook AND drill it. Decision tree: is it in our graph, what's the blast radius, what gets rotated, who calls impact. Tabletop it like you tabletop ransomware.
• → Name the team upfront. Sec? Platform? App team? Don't argue ownership at 2am.
• → Know your kill switches. Halt all CI, revoke every GITHUB_TOKEN, rotate cloud OIDC. Most teams can't, so builds keep pulling the backdoor for hours after disclosure.
• → Watch the right feeds. Socket, GHSA, OSV, your registry's advisories. If your first signal is a LinkedIn thread, you're already last.

Five gaps. A path forward.

1. 01 Fund the bridge between dev and security A role with authority to block releases.
2. 02 See all of your dependencies, aggregated and queryable SBOMs in CI. Continuous SCA. Maintainer health, not just CVEs.
3. 03 Treat non prod like prod Network isolation. Separate IAM. No shared data stores.
4. 04 Lock down git Branch protection. CODEOWNERS. Signed commits.
5. 05 Review your pipelines! SHA pinned actions. OIDC. Allowlisted publishers. Secure templates.
6. + Drill the IR runbook Supply chain attacks need their own scenario.

Want to learn more?

Start with opensourcemalware.com, an excellent source for the latest attacks and breakdowns.

• →SLSA. Supply-chain Levels for Software Artifacts. Framework for hardening the build pipeline. slsa.dev
• →OWASP Top 10. Baseline vocabulary for the whole org. owasp.org/Top10
• →GitHub Security Lab advisories. Attack write-ups and CVE research. securitylab.github.com
• →Socket. Live npm and PyPI malware feed. socket.dev
• →OpenSSF Scorecard and Best Practices. openssf.org