Before we start - one request.

Put the phone away. Close the laptop. Just for 30 minutes.

I promise - by the end of this, you'll be the smartest person in the room the

next time “software supply chain” comes up in conversation.

Just listen. That's all I need from you.

2

Kumar “Cyberbali” Shivam

Product Security Architect

1

www.cyberbali.in

Security engineering is what I do – at work and outside of it.

​

Cyberbali is my effort to give back to the community. I write deep technical articles and build tools based on my experiences with running the security team on a multi billion-dollar product line. The goal is to ignite conversations, and guide others to ensure our community is able to help engineer product security in its finest form.

​

If after this session, you feel like I am not full of shit, then do follow my work ☺

Before we begin, I would like to brush up basics of 2 topics

​

​

Open-Source Software & Supply Chain

OSS – The 8^th wonder of mankind !

• An example of the selfless behavior we engineers have embedded in our DNA. People around the world came together to build this ecosystem that each of us use – every day.

​

• It single handily revolutionized computing by inverting a fundamental premise of the modern economy: that valuable technology must be hoarded behind proprietary legal walls to generate value. Instead, it turned software into a shared, self-reinforcing public utility.

​

• Thanks to OSS, we engineers do not have to solve same foundational problems from scratch. OSS provides battle tested building blocks. Linux, Kubernates, PyTorch, almost whole of cryptographic library etc.

​

Today, every modern application is built out of millions of line of stranger’s code, glued together.

Supply chain that binds the world of software !

4

A software supply chain refers to everything and everyone that touches a piece of software from the moment the first line of code is written until it runs in production.

​

• Source Code

​

• Third-Party Dependencies: Open-source libraries, packages, and frameworks fetched via package managers (such as npm, PyPI, Maven, or Crates.io), along with their transitive dependencies (the packages those libraries depend on).

​

• Build Systems & Pipelines: Compilers, package managers, (CI/CD) runners, scripts, and build servers.

​

• Packaging & Artifacts: Binary executables, software packages, or container images (e.g., Docker images)

​

• Infrastructure & Tooling: IDEs, source control platforms (GitHub, GitLab), Monorepo.

Take a restaurant for example. You don't check every ingredient yourself - you trust the restaurant, who trusts their supplier, who trusts the farm. Poison something far upstream, and it quietly ends up on everyone's plate.

​

Until very recently, all of this was the honeymoon era of shared software. Statements like “if it’s on GitHub/NPM, it’s safe – led to blind pulling of latest tags.

​

We were in for a shock !

The fall of trust !

• The hounds who were spending months breaching high security enterprise systems – found out that they could just take on the unvetted, running as root third-party dependencies instead.

​

• It soon became a gold-digging operation. Hidden within the pile of dust lies valuable artifacts – and attackers tasted blood !

​

• Taking over repositories, harvesting secrets and credentials, using access tokens to push malware infected software – this all is just the beginning.

4

A few numbers !

4

• We are losing this battle, and we are losing it fast. Not a single day goes by where I do not hear news of another compromise. Even the biggest of the organizations are somewhat helpless.
• This is probably the most pressing issue in cybersecurity today – the mother of all cyber attacks. Every ransomware, phishing and other traditional cyber attacks seems to be originating from here.
• This battle needs soldiers – It needs you.
• To spread awareness.
• And to find an antidote – to protect the weakest link in all this (the end user)
• Let me help you get started !
• 7 different ways this is spreading right now
• 6 defenses against them
• ….and what to do if you are already hit !!

4

Why I chose to do this today ?

4

CASE STUDY 1 – TEAM PCP

One Stolen Credential – Team PCP Campaign

One leak, left only half-cleaned-up, kept unlocking new doors for six months.

6

• Initial Access: In late February 2026, attackers exploited a misconfigured GitHub Actions workflow in Trivy to steal a service account token.

​

• The Payload Drop: On March 19, 2026, TeamPCP force-pushed malicious code to 76 out of 77 version tags in the official aquasecurity/trivy-action and setup tools.

​

• The Stealer: The injected code was a three-stage cloud credential stealer that harvested environment variables, SSH keys, cloud provider secrets, and API tokens from build runners

​

• The Cascading Effect: Because many popular open-source tools and libraries used Trivy or shared runner environments without version pinning, the breach cascaded into other software ecosystems. Stolen creds were reused to poison LiteLLM (and many more) - Malicious versions of the popular AI proxy package were pushed to PyPI because its build pipeline ran the unpinned, compromised Trivy.

CASE STUDY 2 – SHAI HULUD

The Worm That Keeps Coming Back

This isn't a bug you patch once. It's a threat that evolves faster than most teams can react.

7

• The Shai-Hulud worm campaign is a massive, self-propagating software supply chain attack targeting the Node Package Manager (npm) and GitHub ecosystems, named after the giant sandworms from the Dune series

​

• What it is: A self-replicating digital worm that harvests developer credentials, CI/CD pipeline secrets, and cloud access tokens, then uses them to automatically infect and republish additional software packages

​

• Initial Vector & Propagation: The worm typically enters via compromised maintainer accounts or vulnerable CI/CD/GitHub Actions workflows. Once installed on a developer or build machine, it scans for local secrets (like AWS keys, npm tokens, and GitHub tokens) using tools like TruffleHog.

​

• Self-Replication: Using stolen maintainer tokens, it automatically injects malicious code and republishes updated versions of packages under the victim’s control.

​

• The Dark Mark: Stolen data is beamed back to public or private GitHub repositories created by the attackers, often tagged with the signature string "Shai-Hulud: Here We Go Again".

CASE STUDY 3 - AXIOS

When the Developer's Laptop Is the Weak Link

Attackers broke into the personal computer of a trusted lead developer - not a server, not the cloud.

Two fake updates went out within 39 minutes, hitting both the current and an older version at once.

The malware deleted itself afterward, erasing the evidence.

Even the best safeguards don't help if someone gets direct access to a trusted person.

8

CASE STUDY 4 - GLASSWORM

Malware You Cannot See

Even a careful human staring right at the code would see nothing wrong.

9

• Glassworm’s sophisticated attack represents an evolutionary leap in malware design that every developer should understand.

​

• Invisible Code Injection: The malware uses invisible Unicode and Private Use Area (PUA) characters to hide malicious code that literally disappears from code editors during review. This makes detection through standard code inspection nearly impossible.

​

• Unkillable Infrastructure: GlassWorm leverages the Solana blockchain as its command and control (C2) infrastructure. By embedding payload URLs in blockchain transaction memos, attackers created a decentralized, immutable C2 system that cannot be taken down.

​

• True Worm Behavior: What sets GlassWorm apart is its autonomous replication. After infecting a system, it harvests NPM tokens, GitHub credentials, and OpenVSX access tokens. These stolen credentials are then automatically used to compromise additional packages and extensions, with each new victim becoming a launch point for further infections.

​

• Impact: Infected 50,000+ VS code extensions, stole credentials, drained crypto wallets, turned developer machines into criminal infrastructure.

CASE STUDY 5 – NOTEPAD++

When the “Update” Button Itself Is the Trap

One of the world's most-used text editors - practically every developer has it installed.

State-sponsored hackers broke into the hosting providers who host update servers, not the app itself.

Selected targets who clicked “Check for Updates” got a fake, trojanized installer instead - everything looked completely normal, possible as the installation process never verified if the installer they downloaded was genuine signed by a real dev.

You don't need to steal a password if you can just become the update server.

10

CASE STUDY 6 – AI AGENT TOOLS

It's Already Happening to AI Tools Too

The same tricks are now hitting “skills” and plug-ins that AI agents use to take action on your behalf.

Roughly 1 in 3 tested AI skills had some kind of flaw - even inside popular, trusted projects.

A malicious AI skill doesn't just run code - it can access your files, cloud accounts, and memory, all at once.

AI MARKETPLACES ACCEPTED A FAKE MALICIOUS SKILL

9 / 11

We spent 20 years teaching developers not to blindly trust npm install. AI agents just reset that lesson - with a bigger permission set.

11

CASE STUDY 7 – ATOMIC ARCH

Nobody Hacked Anything - They Just Asked Nicely

Arch Linux lets anyone "adopt" a package if the original maintainer goes quiet for a while - a normal, helpful community feature.

Attackers used this completely legitimate process to legally take ownership of about 1,500 abandoned packages that people already trusted and had used for years.

Once in control, they quietly edited the install instructions to pull in a hidden extra package - so a routine update installed the malware for you, automatically. Some infections planted a rootkit that hides itself from the operating system entirely

Every other story tonight involved a broken lock. This one didn't. They just asked for the keys to something nobody was watching anymore - and the system said yes.

11

THE WATCHTOWER

Leading the battle

​

Dumbledor’s Army !

12

THE DEFENSE PLAYBOOK

"Fix #1: Logins That Expire" (Credential Hygiene)

13

• The mechanism: It is called OIDC Trusted Publishing. It integrates the security of OIDC framework enabling direct publishing of npm packages from your CI/CD securely. No more storing, rotating, or accidentally exposing npm tokens in your CI/CD environments. Each publish is authenticated using short-lived, workflow-specific credentials that cannot be exfiltrated or reused.

​

• What it stops: Trusted publishing creates a trust relationship between npm and your CI/CD provider. When you configure a trusted publisher for your package, npm will only accept publishes from the specific workflow you’ve authorized. So, no more reusing keys weeks later which powers shai-hulud.

​

• Do this Monday: If you publish any package, turn this on - and once it works, disable the old-style permanent keys entirely.

THE DEFENSE PLAYBOOK

"Fix #2: Prove You Are Who You Say You Are" (Provenance)

13

​

• Every package can carry a signed, tamper-proof receipt showing exactly which system built it and from what source code. Sigstore Cosign secures the software supply chain by bridging the gap between where code is built and where software runs. It creates an unforgeable, cryptographically verifiable paper trail proving that an artifact was produced by an approved workflow from an authentic source, and has not been tampered with in transit.

​

• Do this Monday: Enable OIDC permissions, Drop sigstore/cosign-installer into your build job right after checking out your code. Build and push your container, saving its output digest rather than just the mutable tag, Run cosign sign --yes <image>@<digest> to generate an ephemeral certificate and publish the proof to Rekor with zero managed secrets.

THE DEFENSE PLAYBOOK

"Fix #3: Slow Down, and Watch" (Cooldowns + Behavior)

13

​

• Pin exact versions, don't auto-upgrade, and add a short delay before adopting anything new - every attack tonight was caught within 40 minutes to 3 hours. A few days' delay turns someone else's bad luck into your early warning.

​

• Turn off automatic script execution during install - this is the exact mechanism nearly every payload tonight used to run itself the moment it was installed.

​

• Layer in tools that watch behavior, not just known threats - things like Socket, GuardDog, or Snyk catch a package doing something suspicious even before anyone's officially labeled it dangerous.

THE DEFENSE PLAYBOOK

"Fix #4: Lock Down the Factory" (CI/CD Pipeline)

13

• Lock third-party actions to an exact snapshot of code, never a moveable label. Instead of pointing to a label (that can always change what it hides), point to a commit SHA (which will never change).This single control would have prevented the Trivy tag-rewrite attack from cascading via trivy-action.
• Principle of least privilege. By default, repository settings often grant GITHUB_TOKEN broad read and write access to issues, pull requests, packages, and code. If an attacker runs code in your build, they could push backdoored code to your branches or steal data. Strip the token of all powers at the very top of your workflow and only hand out specific keys to the individual job that actually needs them.
• persist-credentials: false on actions/checkout so the token isn't left on disk for subsequent steps/malicious code to find. When actions/checkout pulls your code, it automatically writes the GITHUB_TOKEN inside the hidden .git/config file on the virtual machine's disk so subsequent Git commands just work.
• OIDC over long-lived cloud/registry secrets wherever your CI needs to authenticate outward - this closes the exact reuse window that let TeamPCP pivot from Trivy → Checkmarx → LiteLLM using the same stolen-secret pattern each time.
• CODEOWNERS on .github/workflows/ so workflow file changes require dedicated review - stops a malicious PR from quietly modifying CI behavior.
• Complete containment, not partial: the Trivy campaign happened twice in three weeks because the Feb 28 root cause (a misconfigured workflow token) wasn't fully rotated the first time. Verify full credential rotation, not just removal of the malicious artifact.

​

THE DEFENSE PLAYBOOK

"Fix #5: The Same Rules Apply to AI Agents"

13

​

• Every AI "skill" or plug-in your agent uses should be treated exactly like an unreviewed install script - because that's functionally what it is, just with a bigger blast radius.

​

• Scope agent/MCP permissions minimally - Give AI tools only the access a task actually needs - not standing access to your files, cloud accounts, and credentials by default.

​

• "It's on the official marketplace" is not a safety signal yet - 9 of 11 marketplaces tested accepted a fake malicious plug-in with zero review.

​

• OWASP now has a named checklist for this exact risk category (the "Agentic Skills Top 10") - worth knowing it exists, even if you never open it.

THE DEFENSE PLAYBOOK

"Fix #6: Watch Who's Holding the Keys" (Ownership Changes)

13

​

• Every other fix tonight assumes the code changed. Atomic Arch proved that's not the only thing to watch - ownership can quietly change while the code looks identical.

​

• Know who maintains every critical dependency you rely on, and get an alert when that changes - most teams have zero visibility into this today.

​

• Treat a recently-adopted or newly-transferred package with the same suspicion as one from a stranger, even if its name and history are years old.

​

Because It Will Happen Eventually

If You're Already Hit: The First Hour

13

• Confirm the finding against at least two sources where possible (e.g. vendor advisory + OpenSourceMalware.com / OSV.dev) before triggering a full response - but don't let confirmation-seeking delay containment if the signal is strong.

​

• Identify every version and every internal service/repo that resolved the affected package, using your SBOM inventory and internal registry pull logs - this should be a single query if that infrastructure is in place, not a manual grep across dozens of repos.

​

• Rotate everything reachable - passwords, tokens, SSH keys, cloud credentials - not just the one thing you're sure was exposed. Verify that rotation across system has taken place.

​

• Assume deeper compromise until proven otherwise, especially if anything ran with elevated/root access. Shut down and isolate any CI/CD tool or pipeline that it might have touched.

​

• Pin to a known-clean version and rebuild all affected artifacts from a clean state - don't simply patch forward on top of a potentially-compromised build environment.

​

• Search for persistence mechanisms specifically - scheduled tasks, systemd services, modified shell profiles, or new SSH keys - introduced during the compromise window.

​

• Re-run full SBOM generation and provenance verification on all rebuilt artifacts before declaring services healthy

​

• Then ask why it took as long as it did to notice - Run a blameless root-cause review focused on which link in the trust chain failed, and which control family would have caught it earlier.

Questions, war stories, or disagreements - the floor is yours.

www.cyberbali.in