An attacker phished the npm maintainer “qix” (Josh Junon) with a fake 2FA reset
email from the domain npmjs.help. The attacker took over the account and
published versions of 18-20 packages, including chalk and debug, that
together have over 2 billion weekly downloads. The payload was a browser script
that rewrote crypto wallet addresses during transactions. The versions were live
for about two hours.
Source: Palo Alto Networks,
The Hacker News
A self-replicating worm spread through npm. When it ran in an environment that held npm tokens, it published new versions of any package those tokens could reach. It also harvested credentials and sent them to public GitHub repositories. It compromised over 500 packages. Researchers linked it to the earlier s1ngularity/Nx token theft from late August 2025. Source: CISA Alert, Unit 42, Wiz
A second wave used the same propagation idea but moved the payload to the pre-install step, which widened the impact. It affected tens of thousands of GitHub repositories and added a fallback that could delete a user’s home directory. Source: Unit 42, Datadog Security Labs
An attacker took over the npm account of the axios maintainer (jasonsaayman),
changed the account email, and published two versions (1.14.1 and 0.30.4).
These versions added a dependency, plain-crypto-js, whose post-install script
ran a cross-platform remote access trojan on Windows, macOS, and Linux. axios
has over 100 million weekly downloads. The attacker published with a long-lived
npm token from the CLI and bypassed the project’s GitHub Actions OIDC publishing
workflow. The legitimate 1.14.0 had been published through GitHub Actions; the
malicious 1.14.1 had no matching GitHub tag, release, or commit. Google and
Microsoft attributed the attack to a North Korea-linked group.
Source: Microsoft,
Google Threat Intelligence,
Unit 42
A group tracked as TeamPCP ran a worm that published versions through the projects’ own GitHub Actions release pipelines using hijacked OIDC tokens. It hit TanStack, UiPath, AntV, and others. Because the malicious code went through the real build pipeline, the published packages carried valid SLSA Build Level 3 provenance. This was the first reported npm worm to produce packages with valid provenance. Source: StepSecurity, Snyk
SLSA (Supply-chain Levels for Software Artifacts) is a framework from the OpenSSF. It defines how to record and check the origin of a software artifact. The record is called provenance: it states what built the artifact, what process was used, and what the inputs were. A consumer sets an expectation for how a package should be built, then checks each version’s provenance against that expectation.
SLSA is organized into tracks. Each track has levels. The current version is v1.2, approved in November 2025.
Reference: SLSA specification v1.2, SLSA security levels, Understanding SLSA: Tracks, Levels, and the Checks at Each Step
The attacks fall into two groups. SLSA handles them differently.
This group includes chalk/debug, the original Shai-Hulud, Shai-Hulud 2.0, and axios. In each case the attacker obtained publishing credentials (an account or a token) and pushed versions that never went through the project’s real build process.
For axios, the legitimate releases came from GitHub Actions with OIDC. The malicious release came from a manual token publish with no source commit behind it. For Shai-Hulud, the worm spread by reusing stolen npm tokens to publish.
SLSA addresses this group through the Build Track:
For this group the answer is: yes, Build Track, L2 to detect, L3 to prevent.
There is one condition. SLSA only stops these attacks if the registry or the
consumer actually checks provenance and rejects mismatches. Generating
provenance alone (L1) does nothing. The axios pipeline also showed a related
gap: it had OIDC set up but still passed a long-lived NPM_TOKEN, and npm used
the token when both were present. Removing standing tokens, which is part of the
L3 discipline, would have closed that path.
This group is the Mini Shai-Hulud / TeamPCP wave. The attacker did not publish outside the pipeline. The attacker hijacked OIDC tokens and published through the real GitHub Actions pipeline. The result was malicious packages with valid SLSA Build L3 provenance.
This shows a limit of the Build Track. SLSA provenance states where, how, and from what source an artifact was built. It does not state that the source or the build is safe. If the attacker controls the pipeline, the provenance is genuine and verification passes.
For this group the Build Track is not enough. Useful controls here are:
Even these do not fully prevent the attack. A privileged insider or a review bypass can still get through. They raise the cost; they do not remove the risk.
| Attack | Could SLSA have stopped it? | Track and level |
|---|---|---|
| chalk, debug, qix (Sep 2025) | Yes | Build L2 to detect, L3 to prevent, with verification |
| Shai-Hulud / 2.0 (Sep-Nov 2025) | Yes | Build L3 (removes the stolen-token publish path) |
| axios (Mar 2026) | Yes | Build L2 to detect, L3 to prevent, with verification |
| Mini Shai-Hulud / TeamPCP (2026) | No (Build Track alone) | Needs Source Track, two-party review, Build Environment Track; still partial |
The common lesson across all of these: SLSA helps only when consumers or registries verify provenance against an expected source and builder. npm now produces provenance and supports OIDC trusted publishing, but most installs do not check it. Provenance without verification is a record that no one reads.
Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.
Thank you for reading!
]]>This post explains what SLSA is, how it works, where it applies, and the checks required at each level. It covers version 1.2 of the specification.
Official specification: slsa.dev/spec/v1.2
SLSA is a set of guidelines for securing the software supply chain. You adopt it in steps. It works for two groups:
SLSA gives you:
Reference: About SLSA.
SLSA is organized into tracks. Each track is divided into levels.
The mechanism behind every track is the attestation. An attestation is a signed, machine-readable statement about how an artifact or source revision was produced. Verification means comparing the attestation that exists against the attestation that was expected.
Each ecosystem or organization decides the details: how expectations are defined, which formats are accepted, how attestations are distributed, when verification runs, and what happens on failure.
Reference: Tracks.
| Track | What it covers | Levels |
|---|---|---|
| Build Track | How an artifact was built: who built it, what process was used, what the inputs were. | L0 to L3 |
| Source Track | How a source revision was created and managed. | L1 to L4 |
Version history: the first version of SLSA used one track with levels 1 to 4. Version 1.0 removed source and focused on the build track. Version 1.2 adds source back as its own track.
| Audience | What SLSA provides |
|---|---|
| Software producers (open source projects, vendors, internal teams) | Protection against changes to software on the path to users. Reduces insider risk. |
| Software consumers (teams using open source, agencies, security officers) | A method to assess the practices behind software they depend on, and to confirm they received what they expected. |
| Infrastructure providers (package managers, build and CI/CD platforms) | A way to enable a secure supply chain between producers and consumers. |
The Build Track lets you prove that an artifact was built the way it was meant to be, on infrastructure you can trust. Each level includes the requirements of the level below it.
| Level | Requirement | Threat addressed |
|---|---|---|
| Build L0 | None | None |
| Build L1 | Provenance shows how the package was built | Mistakes and missing records |
| Build L2 | Signed provenance from a hosted build platform | Changes after the build |
| Build L3 | Hardened build platform | Changes during the build |
Reference: Build Track Basics. Detailed requirements: Producing artifacts. Verification: Verifying artifacts.
The Source Track lets you trust how a source revision was created and confirm that its history was not rewritten. The repository owner (the organization) defines the process and runs the controls that enforce it. Consumers review attestations to confirm a revision meets their bar.
| Level | Requirement | Focus |
|---|---|---|
| Source L1 | Use a modern version control system (produce discrete, immutable revisions) | Discrete revisions for precise use |
| Source L2 | Keep change history and produce source provenance | History backed by evidence |
| Source L3 | Enforce the organization’s technical controls | Controls that consumers can see |
| Source L4 | Require two-party review | Code review and insider-threat resistance |
Responsibility is split between the organization and the Source Control System (SCS), such as GitHub, GitLab, Gerrit, or a self-hosted system. Each has its own checks.
Claims apply only forward from the revision where a branch is onboarded to a level. No claims are made about earlier history.
| Check | L1 | L2 | L3 | L4 |
|---|---|---|---|---|
| Choose an SCS that can reach the target level | x | x | x | x |
| Configure access control and enforce history; prevent tags from being moved or deleted | x | x | x | |
| Document a safe process for removing content for legal or privacy reasons, with logging | x | x | x | |
| Provide evidence of continuous enforcement for every control claimed, and document each control | x | x |
| Check | L1 | L2 | L3 | L4 |
|---|---|---|---|---|
| Repositories are uniquely identifiable with a stable locator | x | x | x | x |
| Revisions are immutable and uniquely identifiable | x | x | x | x |
| Provide tooling to show diffs between revisions | x | x | x | x |
| Issue a Source Verification Summary Attestation (VSA) for any revision at L1 or above | x | x | x | x |
| Record all changes to references; allow a branch to move only to descendant revisions (no force-push) | x | x | x | |
| Track continuous enforcement of each control from a start revision | x | x | x | |
| Authenticate actors and let the organization set who can perform sensitive actions | x | x | x | |
| Produce source provenance for each revision at the time the branch is updated | x | x | x | |
| Let the organization enforce custom controls on chosen branches and tags, and record them | x | x | ||
| Require two trusted persons to agree to each change on protected branches | x |
Two-party review applies to the final submitted revision. Later edits are reviewed again. Organizations may grant standing exceptions to trusted automation, such as Dependabot or migration bots.
Reference: Producing source. Verification: Verifying source.
Every track is enforced through attestations. These use the in-toto attestation format. See the in-toto attestation specification.
https://slsa.dev/verification_summary/v1 in the in-toto attestation framework. See Verification Summary.Verification means a verifier compares the attestation against the expectations defined for the artifact or revision. The level tells the consumer how much weight that comparison carries.
Pair SLSA with vulnerability scanning, SBOMs, code review, and dependency management.
Reference: Threats and mitigations.
Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.
Thank you for reading!
]]>This post is about what you can do about them. Not in theory. In practice, today, with tools that exist.
Before getting into specifics, it helps to reframe how you think about model deployment. Most teams treat the model as output: something you receive, load, and use. Security thinking lives at the edges, in the API, in the prompt handling, in access controls.
But the model file itself is infrastructure. It is more like a binary you are running than a document you are reading. And you should treat it the way you treat any third-party binary: with verification, scanning, and a clear chain of trust.
Once you have that framing, the rest follows.
The first thing to do is stop loading model files without checking them.
This sounds simple, but a huge number of workflows skip it. Someone runs a tutorial, copies a torch.load() call, and loads a model they pulled from a repository. That call can execute code in the file. No exploit needed. Just loading is enough.
What to do:
Use the weights_only=True parameter in PyTorch when loading model files. This blocks the code execution path.
# Risky
model = torch.load("model.pt")
# Safe
model = torch.load("model.pt", weights_only=True)
Better yet, move to the safetensors format entirely. It was built specifically to avoid the serialization problem. It stores weights and nothing else. There is no code execution surface.
The safetensors library is maintained by Hugging Face and supports all the major frameworks. Switching is not hard, and most model hubs are beginning to prioritize it.
Model scanning is a real thing now, not just a future idea. A few tools are worth knowing.
ModelScan — open-source, built by Protect AI. It scans model files for unsafe serialization patterns, including pickle exploits. You can run it before loading any downloaded model.
GitHub: protectai/modelscan
pip install modelscan
modelscan -p path/to/model.pkl
Protect AI Guardian — the commercial version of the above, with a broader set of checks and integrations into ML pipelines.
HiddenLayer Model Scanner — another scanner that checks models for known malicious patterns. HiddenLayer has published research on backdoors in computational graphs (the ShadowLogic work), so their tooling reflects real threat research.
These tools will not catch everything, especially novel backdoors. But they catch known attack patterns and unsafe file formats, which covers a lot of the threat surface for models pulled from public repositories.
When you download a model from a repository, verify the hash. Most repositories provide SHA256 hashes alongside model files. Check them.
sha256sum model.safetensors
Compare the output to what the repository lists. If they match, the file is what was uploaded. That is not a full guarantee of safety, but it tells you no one tampered with it in transit or on the host.
For internal models, treat weights the way you treat build artifacts. Version them. Store them with checksums. Log who accessed them and when. If you are using object storage like S3 or GCS, enable versioning and access logging. Model weights can walk out the door just like source code can.
This is how you catch backdoors and hardcoded behavior that no file scanner will find, because they live in the weights, not in the file format.
The idea is to test the model across a range of inputs, including inputs that test for known backdoor trigger patterns, before you deploy it. This is called behavioral evaluation or red-teaming at the model level.
What this looks like in practice:
Build a test suite that covers the behaviors you care about. Run the model against edge cases, unusual inputs, and inputs that probe for inconsistency between what the model says about itself and what it does. If you are using a base model from a public source, run it through a standard set of jailbreak and trigger probes before you fine-tune.
Tools that help:
Garak — open-source, from NVIDIA. It is a framework for probing LLMs for a range of vulnerabilities including hallucination, data leakage, and backdoor-style behaviors. It is easy to run and generates reports you can act on.
pip install garak
python -m garak --model_type huggingface --model_name your-model --probes all
LLM-Fuzzer — a fuzzing tool for language models, useful for finding unexpected behavior under input variation.
Microsoft PyRIT — Python Risk Identification Toolkit for Generative AI. Built for red-teaming AI systems at scale. Covers a range of risk categories and is well-documented.
None of these are backdoor detectors in a strict sense. But they are how you build evidence that a model behaves consistently, which is the closest thing you have to assurance.
If you are training or fine-tuning models on data you collected or sourced, you need a process for reviewing that data before it goes into training.
This is analogous to input validation in software security. You do not trust external input. You inspect it, filter it, and log what you kept and what you dropped.
Practical steps:
For web-scraped data, use content filtering to remove known malicious domains, hate content, and adversarial patterns. Tools like Dolma from AI2 include filtering pipelines you can adapt.
For fine-tuning data from internal or third-party sources, do a human review sample at minimum. If the dataset is large, sample 1-2% and have someone read it. You are looking for content that would teach the model something you did not intend.
Keep records of what data you trained on. If you discover a problem later, you need to know whether the training data is the likely source.
Weight theft is often overlooked because it does not feel like a security incident until the model shows up somewhere it should not be.
Model weights are files. They need access controls.
Basic controls:
Restrict who can read model files in your storage systems. Not everyone on the team needs access to the weights. Apply least privilege: the inference server needs read access, most developers do not.
Log access to weight files. If a weight file is downloaded or copied, you want to know.
Encrypt model weights at rest and in transit. This does not stop an insider who has legitimate access, but it raises the bar for external attackers and reduces exposure from misconfigured storage buckets (a common issue).
If you are serving models via API, the weights should never be directly reachable by clients. The inference layer sits in between. But also be aware that a determined attacker with API access can probe your model to reconstruct its behavior, a process called model extraction. Rate limiting, output watermarking, and anomaly detection on query patterns are the defenses here.
If you are using a third-party quantized model, or if someone on your team compresses a model for deployment, treat the output as a new artifact that needs testing.
The compressed model is not the same model that was evaluated. Run your behavioral test suite against it. Check that safety behaviors held through compression. Check that outputs on your evaluation sets match expectations.
This is not a one-time thing. Every time a model is quantized, pruned, or otherwise transformed, the resulting artifact needs to go through the same checks as the original.
Tools help. But the bigger shift is having a process where model files are treated as something you verify, not just something you use.
In practice, this looks like:
A checklist that runs before any model is loaded into production. It covers format verification, hash checking, scanning, and behavioral evaluation. No model goes to production without passing it.
A record of where every model in production came from. The source, the version, the checks it passed, and when. This is your audit trail.
A clear owner for model security. Someone whose job includes asking “where did this model come from and do we trust it?” before deployment happens.
This does not require a large team. It requires a small amount of process and the willingness to treat the model file as infrastructure rather than output.
Some of these threats do not have strong technical defenses yet. Backdoor detection in trained weights is still an open research problem. There is no tool you can run that will reliably tell you whether a model has a backdoor embedded in it. The research cited in the previous post shows that backdoors can survive fine-tuning, which means even building on top of a compromised model does not clean it.
What you have instead is a combination of supply chain hygiene, behavioral testing, and file-level scanning. Together, these raise the bar significantly. They will not catch every attack. But they make your model deployment look much less like an open door.
The field is moving. Backdoor detection research is active. Model scanning tooling is improving. Formats like safetensors are gaining adoption. The picture in two years will look different from today.
For now: verify what you load, scan what you can, test how the model behaves, and keep records of where it came from. That is not everything. But it is where to start.
Tools mentioned in this post: safetensors, ModelScan, Garak, Microsoft PyRIT, Dolma
Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.
Thank you for reading!
]]>This post is about those threats.
A dynamic threat happens at runtime. The model is running, a user sends something, and that input triggers harmful behavior.
A static threat is different. It lives in the model’s weights, its training data, its file format, or its supply chain. It is there before deployment. It is there before the first request. And in many cases, the people deploying the model have no idea.
As more organizations build models in-house or pull models from open-source repositories, this matters more than ever. You can have the best prompt filtering in the world and still be running a model that is compromised at the foundation.
This is where it starts. A model learns from data. If someone can influence what data goes into training, they can influence what the model learns.
The attack works by injecting content into datasets before or during collection. This content is designed to teach the model specific behaviors. It might cause the model to produce false information on a particular topic. It might make the model favor certain outputs. It might plant a trigger that activates later.
What makes this hard to defend against is scale. Training datasets are often enormous. No one reads them in full. Automated filters catch some things but not everything, especially when the poisoned content is designed to look normal.
For organizations that train on data scraped from the web, or that fine-tune on data they did not fully audit, this threat is real and present today.
A backdoor in a model works like this: the model behaves normally in almost every situation, but when it encounters a specific trigger, it produces a specific output that an attacker designed.
The trigger might be a word, a phrase, a symbol, or even a pattern in an image. The model is trained to respond to it in a way that looks unintentional from the outside. Users see an error or an unusual output. They might not even notice something is wrong.
This kind of attack can happen during training, during fine-tuning, or even during model merging. And because the backdoor is stored in the weights, you cannot remove it by changing the model’s instructions or system prompt. It is part of the model.
Research has shown that backdoors can survive fine-tuning. That means even if an organization takes a compromised base model and fine-tunes it on their own data, the backdoor can persist.
Key research on this:
- Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training (Hubinger et al., Anthropic, 2024) — showed that backdoor behavior persists through supervised fine-tuning, reinforcement learning, and adversarial training. In one test, a model was trained to write safe code in 2023 but insert code vulnerabilities in 2024. Safety training failed to remove this.
- Watch your steps: Dormant Adversarial Behaviors that Activate upon LLM Finetuning (Gloaguen et al., 2025) — demonstrated that an attacker can release a model that looks clean but activates harmful behavior only after a downstream user fine-tunes it on their own data.
- A Survey on Backdoor Threats in Large Language Models (2025) — found that even parameter-efficient fine-tuning methods like LoRA are insufficient to remove backdoors, because they update too few parameters to overwrite what was embedded in pretraining.
This one is underappreciated even by people who think about security.
Model weights are stored in files. The most common format for PyTorch models is pickle. And pickle is a format that can execute code when it is loaded.
This means that a model file downloaded from the internet, when loaded with torch.load(), can run code on your machine without you doing anything other than loading the model. The weights might be perfectly fine, but the file itself is a vector for code execution.
This is not a theoretical attack. There have been cases of models uploaded to repositories that include pickle exploits. When you download and load them, you are running code someone else wrote.
The fix exists. PyTorch has a weights_only=True parameter. Safer formats like safetensors exist. But a lot of tooling, tutorials, and workflows still use the defaults.
The open-source model ecosystem has grown fast. Repositories like Hugging Face host thousands of models. Developers pull these models and use them directly, or use them as a base for fine-tuning.
The problem is trust. When you download a model, how do you know the weights have not been modified? A weight tampering attack involves changing a trained model’s weights in a targeted way, altering its behavior without changing the architecture or the file structure in a way that would be obvious.
Model hashes exist. Some repositories show them. But many users do not verify them. And even if the hash matches the repository, it only tells you the file is the same as what was uploaded. It says nothing about whether the weights are safe.
This threat is different in nature. It is not always the work of an attacker. Sometimes it is the result of the training process itself.
Models can learn behaviors from training data that are never intended and never documented. These behaviors can be consistent and predictable, which is what makes them a threat. They can also be deliberately introduced during fine-tuning by a party that has access to the training pipeline.
In an internal model built at an organization, the fine-tuning data controls a lot. If someone with access to that process wants to embed behavior into the model, whether it is a tendency to downplay certain topics, steer outputs in a direction, or produce unreliable outputs in specific contexts, the weights are where that happens.
This is hard to audit because there is no “check weights for bias” function. It requires testing, evaluation sets, and the knowledge of what to look for in the first place.
This is a threat to the organization that built the model rather than to its users.
Once a model is deployed, an attacker can send it many queries and use the responses to reconstruct the model’s behavior. In some cases, they can get close to recovering the weights themselves. In other cases, they can build a model that imitates the target closely enough to compete with it.
But there is also a simpler version of this threat: someone inside the organization copies the weights and takes them somewhere else. Model weights are files. They can fit on a USB drive. They can be uploaded to a cloud bucket. If the weights are not treated with the same care as source code or proprietary data, they will not be protected like source code or proprietary data.
When a model is compressed for deployment, through quantization or pruning, its behavior can change in ways that are not fully tested.
This becomes a threat when the compression is done by a third party, or when the compressed model is distributed without proper validation. The model that was tested and approved is not the same model that is running in production. And the differences might be in the directions that matter for safety.
There is also the possibility of deliberate manipulation during quantization, where a model is compressed in a way that introduces specific behavioral changes while looking like a routine optimization step.
Prompt injection is visible. You can demonstrate it in a demo. You can show before and after. It happens at the layer most people interact with.
Static threats are invisible by default. The model looks fine. It passes tests. It gives good answers in evaluation. The threat is waiting for a condition that testing did not cover, or it is already affecting outputs in ways that are not being measured.
There is also an attribution problem. If a model produces a wrong or harmful output, it is easy to assume the model just made a mistake. The idea that the model was deliberately compromised at training time requires a different mental model of how AI systems can fail.
The field needs to treat model files the way software engineering treats dependencies: with verification, auditing, and supply chain awareness. It needs to treat training data the way security teams treat input validation: as an attack surface.
Some of this is starting to happen. The safetensors format is gaining adoption. Some model repositories are adding scanning. Research on backdoor detection is growing.
But for organizations building or deploying models today, especially internal ones where security scrutiny is lower, most of these threats are not on the radar at all.
That needs to change. The model is not just an interface. It is infrastructure. And like any infrastructure, it can be compromised at the foundation.
If you are building or deploying AI models and want to think through your threat model, start with the weights. That is where the trust begins.
Now that we have a map of the threats, the next post will get into what you can actually do about them. We will go through the security measures that exist today, the tools you can use to scan models before you deploy them, and how to build a process that treats model files the way software teams treat code: with verification, auditing, and a real sense of what you are trusting. If you are building or running models in production, that post is the one to read next.
Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.
Thank you for reading!
]]>In November 2025, the Open Web Application Security Project (OWASP) released its eighth edition of the Top 10 security risks, and the message is clear: software supply chain security has graduated from a niche concern to one of the most critical threats facing modern organizations. Ranked at position #3 with an alarming 5.19% incidence rate, Software Supply Chain Failures represents a paradigm shift in how we must approach application security.
The elevation of supply chain security to the #3 position isn’t arbitrary. It reflects the harsh reality of our interconnected software ecosystem. In the 2025 community survey, exactly 50% of respondents ranked supply chain failures as their #1 concern, making it the most voted risk category in OWASP history.
The stakes have never been higher. Recent attacks demonstrate the devastating potential:
To understand why supply chain security has become so critical, we need to trace its evolution through OWASP’s Top 10 lists:
A9 – Using Components with Known Vulnerabilities first appeared in 2013. At this stage, the focus was narrow: organizations simply needed to update libraries with known security flaws. The solution seemed straightforward: patch your dependencies.
The risk persisted at A9:2017 - Using Components with Known Vulnerabilities, remaining in the same position. While the problem was recognized, the scope hadn’t expanded beyond vulnerable components.
By 2021, the category evolved to A06:2021 - Vulnerable and Outdated Components. The name change reflected growing awareness that the problem wasn’t just about known vulnerabilities — outdated components, even without CVEs, posed significant risks.
Now, in 2025, we have A03:2025 - Software Supply Chain Failures (jumped to #3 position!). This isn’t just a name change — it’s a fundamental reimagining of the threat. The scope now encompasses everything involved in building, distributing, and updating software:
Modern applications are built on stacks of dependencies. A typical web application might have hundreds or thousands of direct and transitive dependencies. Each one represents a potential entry point for attackers.
“Despite the increased scope, supply chain failures continue to be a challenge to identify with only 11 Common Vulnerability and Exposures (CVEs) having the related CWEs.” — (OWASP Top 10:2025)
This detection challenge is precisely what makes supply chain attacks so dangerous. Traditional security tools struggle to identify these threats, yet they have the highest average exploit and impact scores from CVEs in the entire OWASP Top 10.
The GlassWorm attack demonstrated a terrifying evolution: attackers are now targeting developer workstations as entry points. By compromising developer tools and extensions, malicious actors gain access to trusted environments where traditional security controls are often relaxed.
Once a developer’s machine is compromised, the malware can:
Supply chain attacks exploit our fundamental need to trust external code. When you install a package from npm or PyPI, you’re implicitly trusting:
A compromise at any point in this chain can cascade throughout your entire application.
OWASP’s recommendations for managing supply chain risk focus on visibility, verification, and vigilance:
Know exactly what’s in your software stack. An SBOM provides a comprehensive inventory of all components, including transitive dependencies. This visibility is crucial for rapid response when vulnerabilities are disclosed.
Use automated tools to continuously monitor your dependencies for:
Only obtain components from official, trusted sources over secure channels. Prefer signed packages to reduce the risk of including modified, malicious components. Verify checksums and signatures before use.
Your build infrastructure is now part of your attack surface. Treat CI/CD systems with the same rigor as production:
Given that developers are now prime targets, secure their environments:
The elevation of Software Supply Chain Failures to position #3 in the OWASP Top 10 isn’t just a ranking — it’s a call to action. The attacks are real, the consequences are severe, and the threat is only growing.
With the highest incidence rate (5.19%) and the highest average exploit and impact scores, supply chain failures represent a perfect storm of prevalence, difficulty to detect, and potential damage. Organizations that treat this as just another checkbox security item do so at their peril.
The message from OWASP is clear: supply chain security is no longer optional. It’s not a future problem — it’s a right now problem that demands immediate, sustained attention.
Start by conducting a supply chain risk assessment for your organization:
The full OWASP Top 10:2025 is available at https://owasp.org/Top10/.
The software supply chain has become one of the most critical battlegrounds in cybersecurity. The question isn’t whether your organization will be targeted — it’s whether you’ll be prepared when it happens.
Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.
Thank you for reading!
]]>You run your security scanner on your Node.js application. Everything’s written in JavaScript and TypeScript. Your package.json has React, Next.js, Express - all the usual JavaScript suspects.
Then the security report drops:
🔴 CRITICAL: Golang vulnerability CVE-2024-XXXXX in esbuild
🔴 HIGH: Go binary exploit in @esbuild/linux-x64
⚠️ MEDIUM: Multiple Golang security issues detected
Your first reaction: “But this is a Node.js project. We don’t use Go!”
Welcome to one of the most confusing aspects of modern JavaScript development. Let me explain what’s happening and, more importantly, how to fix it.
Here’s the reality: some of the most popular JavaScript build tools are actually written in other languages for performance reasons:
When you npm install these packages, you’re downloading pre-compiled binaries for your operating system. These binaries just happen to be Go (or Rust) executables.
Let me share a common scenario I’ve seen dozens of times:
// Your package.json
{
"dependencies": {
"@vanilla-extract/next-plugin": "^2.4.8",
"next": "^15.0.0",
"react": "^18.0.0"
}
}
Looks innocent, right? But here’s what actually gets installed:
node_modules/
├── @vanilla-extract/next-plugin/
│ ├── @vanilla-extract/webpack-plugin/
│ └── @vanilla-extract/integration/
│ └── esbuild@0.25.5/
│ ├── @esbuild/darwin-arm64/ ← Go binary for Mac ARM
│ ├── @esbuild/linux-x64/ ← Go binary for Linux
│ ├── @esbuild/win32-x64/ ← Go binary for Windows
│ └── ... (21 more platform binaries)
You now have 24 Go binaries in your node_modules.
Your security scanner finds them, checks for known CVEs, and raises the alarm.
The answer is nuanced and depends on when and where these binaries execute.
┌─────────────────────────────────────────────┐
│ Development / CI/CD (Build Time) │
├─────────────────────────────────────────────┤
│ $ npm install │
│ → Downloads esbuild binaries │
│ │
│ $ npm run build │
│ → esbuild EXECUTES (compiles your code) │
│ → Generates optimized JavaScript │
│ │
│ Risk: MEDIUM (if build env compromised) │
└─────────────────────────────────────────────┘
┌─────────────────────────────────────────────┐
│ Production (Runtime) │
├─────────────────────────────────────────────┤
│ $ npm start │
│ → Node.js serves HTTP requests │
│ → esbuild binary just sits there (idle) │
│ → NOT executing │
│ │
│ Risk: LOW (secondary exploit only) │
└─────────────────────────────────────────────┘
| Scenario | Can Exploit Go Vulnerability? | Risk Level |
|---|---|---|
| User sends HTTP request | ❌ NO - Go binary not in request path | 🟢 VERY LOW |
| Attacker gains shell access | ✅ YES - Could execute binary | 🟡 LOW-MEDIUM |
| Build environment compromise | ✅ YES - Binary executes during build | 🟠 MEDIUM |
Key Insight: Go binaries in production are like having a power drill in your closet. It’s there, but unless someone uses it, it’s not dangerous. And if a burglar breaks into your house, the drill isn’t the primary problem - the break-in is.
The cleanest solution is to keep build tools out of production entirely.
FROM node:20
WORKDIR /app
COPY package*.json ./
RUN npm ci # esbuild installed here
COPY . .
RUN npm run build # esbuild executes here
EXPOSE 3000
CMD ["npm", "start"] # esbuild STILL in container ⚠️
Problem: All 24 esbuild binaries ship to production unnecessarily.
# ===== STAGE 1: Build (Temporary) =====
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci # esbuild installed HERE
COPY . .
RUN npm run build # esbuild executes HERE
# After this, we're done with esbuild ↑
# ===== STAGE 2: Production (What Actually Deploys) =====
FROM node:20-slim AS production
WORKDIR /app
# Install ONLY production dependencies (no esbuild!)
COPY package*.json ./
RUN npm ci --production --ignore-scripts
# Copy ONLY compiled output from builder
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/public ./public
# Run as non-root user
USER node
EXPOSE 3000
CMD ["npm", "start"]
Result:
# Build production image
docker build -t myapp .
# Check if esbuild is present
docker run --rm myapp sh -c "find / -name esbuild 2>/dev/null"
# Expected output: (empty)
Sometimes the tool causing the alert isn’t even needed!
Many projects have this pattern:
{
"dependencies": {
"@vanilla-extract/next-plugin": "^2.4.8", // ← Brings esbuild
"@emotion/react": "^11.0.0",
"styled-components": "^6.0.0"
}
}
Question: Are you actually using @vanilla-extract?
# Search your codebase
grep -r "@vanilla-extract" --include="*.tsx" --include="*.ts" src/
# If no results...
npm uninstall @vanilla-extract/next-plugin
# Problem solved!
# Find .css.ts files (vanilla-extract pattern)
find src/ -name "*.css.ts"
# Check Next.js config
grep -i "vanilla" next.config.js
# Check imports
rg "from ['\"@]vanilla-extract" src/
Often, newer versions have patched vulnerabilities.
# Update specific package
npm update @vanilla-extract/next-plugin
# Update all dependencies
npm update
# Check for security patches
npm audit fix
# For major version updates
npx npm-check-updates -u
npm install
If you’ve confirmed the binaries are build-time only, configure your scanner appropriately.
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
ignore:
# Don't alert on esbuild patch versions
- dependency-name: "esbuild"
update-types: ["version-update:semver-patch"]
# Audit only production dependencies
npm audit --production
# Generate report excluding dev dependencies
npm audit --production --json > audit-report.json
For some projects, the Go binaries are unavoidable. Document why.
## Security Finding: esbuild Go Vulnerabilities
**Package**: esbuild@0.25.5 (via @vanilla-extract/next-plugin)
**CVEs**: CVE-2024-XXXXX, CVE-2024-YYYYY
**Severity**: MEDIUM
**Risk Assessment**:
- Vulnerability exists in build-time tooling only
- Not present in production container (multi-stage build)
- Not accessible to end users
- Build environment secured with:
- Ephemeral build agents
- Network segmentation
- Access controls
- Build process monitoring
**Mitigation Strategies**:
1. Multi-stage Docker builds (binaries not in production)
2. Build environment hardening (non-root, read-only FS)
3. Regular dependency updates (monthly)
4. Continuous monitoring for new CVEs
**Business Justification**:
- @vanilla-extract required by component library
- No viable alternative for our use case
- Performance benefits outweigh minimal risk
**Risk Level**: LOW (secondary exploit vector only)
**Accepted By**: Security Team
**Date**: 2025-10-01
**Next Review**: 2026-03-01
Let’s be concrete about what could actually happen.
Attacker → HTTP Request → Your App
↓
Node.js handles request
esbuild NOT involved
Result: esbuild vulnerability IRRELEVANT
Risk: None. The Go binary doesn’t execute.
Step 1: Attacker exploits DIFFERENT vulnerability (e.g., RCE in express)
Step 2: Gains shell access to container
Step 3: Discovers esbuild binary
Step 4: Attempts to exploit esbuild CVE for privilege escalation
Result: Could work, but you're already compromised
Risk: Low-Medium. The real problem was Step 1.
Step 1: Attacker compromises build server
Step 2: npm install runs → esbuild post-install scripts execute
Step 3: Exploits esbuild vulnerability DURING BUILD
Step 4: Injects malicious code into build artifacts
Result: Supply chain attack
Risk: Medium. This is the most realistic threat.
Mitigation:
npm ci not npm install in productionnpm audit)Finding Go vulnerabilities in your Node.js project is surprisingly common and usually low risk if handled correctly.
Go vulnerabilities detected
↓
Is the package needed?
├─ NO → Remove it
└─ YES
↓
Is it in production image?
├─ NO → Multi-stage build
└─ YES
↓
Can you use multi-stage builds?
├─ YES → Implement them
└─ NO → Document risk + harden container
# Why is this package installed?
npm ls esbuild
# Full dependency tree
npm ls --all > dependency-tree.txt
# Find all Go binaries
find node_modules -name "*.go" -o -name "*darwin*" -o -name "*linux*" | grep -i esbuild
# Check production vs dev dependencies
npm ls --production
npm ls --dev
Go vulnerabilities in Node.js projects are a symptom of the modern JavaScript ecosystem’s reliance on high-performance native tooling. While the initial security alert can be alarming, the actual risk is often much lower than it appears.
The key is understanding:
By following the solutions outlined in this post, you can either eliminate these vulnerabilities entirely (best outcome) or properly contextualize them with appropriate mitigations (acceptable outcome).
Remember: presence doesn’t equal execution. Just because a binary is in your node_modules doesn’t mean it poses a direct threat. Focus your security efforts on the vulnerabilities that are actually in your runtime attack surface.
Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.
Thank you for reading!
]]>Developers are integrating AI tools into their automated build and deployment processes. Instead of just using AI to write code on their local machines, they’re having AI make changes automatically as part of their software delivery pipeline. This means AI can modify code, update configurations, and make decisions without human oversight.
When you use AI tools in pipelines, your source code gets sent to external servers. This includes not just the code itself, but potentially sensitive configuration files, API keys, and business logic. You’re essentially giving a third party access to your intellectual property and secrets.
We don’t really know how these AI systems make decisions. When Claude Code suggests a change, we can’t audit why it made that choice or predict what it might do in unusual situations. This makes it nearly impossible to do proper security reviews or debug problems when they occur.
AI tools running in your pipeline have the same permissions as your build system. If something goes wrong, the AI could accidentally break security controls, bypass safety gates, or make changes that introduce vulnerabilities. There’s also the risk of prompt injection attacks where malicious input could trick the AI into doing something harmful.
In August 2025, attackers compromised the popular Nx build tool and specifically targeted AI development tools. The malware checked for Claude Code CLI and other AI tools, then used them with carefully crafted prompts to search for cryptocurrency wallets and credentials on infected systems.
What made this attack particularly dangerous was that the malicious logic was hidden in natural language prompts rather than traditional code, making it much harder for security tools to detect. Over 1,400 people had their credentials and wallet information stolen.
Many industries require detailed audit trails and accountability for code changes. When AI makes automated changes, it becomes difficult to meet these requirements. Who is responsible when the AI introduces a security bug? How do you explain to auditors that you can’t fully explain why certain changes were made?
If your teams are experimenting with AI in pipelines, you need to establish guardrails now rather than later. The risks aren’t just theoretical - attackers are already adapting to exploit these new tools.
This doesn’t mean you should ban AI tools entirely. Instead, take a measured approach:
Start with guardrails. Require security review for any AI integration in pipelines. Establish clear policies about what data can be shared with external AI services.
Maintain human oversight. Don’t let AI make changes without human review, especially in production systems.
Know your data flows. Understand exactly what information is being sent to AI services and ensure sensitive data is protected.
Plan for incidents. Have a response plan ready for when things go wrong with AI-generated code.
The potential of AI in development is enormous, but we need to be smart about how we adopt these tools. Security teams and developers need to work together to harness the benefits while managing the risks.
Sources:
The key is finding the right balance between innovation and security. Don’t let the excitement of new AI capabilities blind you to the fundamental security principles that have served us well for decades.
Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.
Thank you for reading!
]]>If you’re like most security teams, you’re probably hoping developers added the right code comments, wrote proper tests, and followed all your recommendations. But let’s be honest – that’s not always realistic.
Here’s how to independently verify that your threat model recommendations actually made it into production.
Most security teams make this mistake:
The problem? You’re completely dependent on developers to self-report their security implementations. That’s like asking students to grade their own exams.
Instead of asking developers what they built, test what actually works. Here are three simple methods any security team can use:
Create simple scripts that test your threats directly:
# Test authentication bypass (Threat: AUTH-001)
curl -X GET https://yourapp.com/admin
# Should return 401, not 200
# Test for SQL injection (Threat: DB-001)
curl "https://yourapp.com/search?q=' OR '1'='1"
# Should not return database errors
No code access needed. No developer cooperation required.
Configure your existing security tools to focus on your threat model:
Static Analysis (SAST) - Check the Code Itself:
# Example: Custom Semgrep rule for SQL injection threat
rules:
- id: sql-injection-python
message: "Potential SQL injection - using string formatting in execute()"
languages: [python]
pattern: |
$CURSOR.execute("..." % ...)
severity: WARNING
# This rule will catch this:
query = "SELECT * FROM users WHERE name = '%s'" % user_input # Flagged!
cursor.execute(query)
# But won't flag this (safe approach):
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,)) # Safe!
Dynamic Analysis (DAST) - Test the Running App:
Infrastructure Scanning:
The key is mapping your threats to specific tool configurations and creating custom rules that look for exactly what your threat model identified.
Many threats can be verified by checking configurations:
# Check if sensitive data is encrypted (Threat: DATA-001)
grep -r "password\|api_key" config/ | grep -v "encrypted"
# Verify HTTPS enforcement (Threat: NET-001)
curl -I http://yourapp.com | grep -i "redirect\|301\|302"
Here’s where it gets powerful. Create a simple mapping between your threat model and pentest scenarios:
| Threat ID | Threat Description | Pentest Test Case |
|---|---|---|
| AUTH-001 | Authentication bypass | Try accessing admin pages without login |
| INJECTION-001 | SQL injection in search | Test search with malicious SQL payloads |
| XSS-001 | Cross-site scripting | Submit script tags in form fields |
Share this with your pentesters. Now they’re not just finding random vulnerabilities – they’re specifically validating your threat model.
Week 1: Pick Your Top 5 Threats
Week 2: Automate the Tests
Week 3: Expand Coverage
The best approach is the one you’ll actually use. Start with:
Don’t try to verify everything at once. Pick the threats that keep you up at night and start there.
Your threat model is only as good as its implementation. Stop relying on developers to self-report their security work.
Build simple verification methods that give you confidence your security controls actually exist in production.
Because at the end of the day, attackers don’t care about your documentation – they care about what’s actually running in production.
Want to get started? Pick one critical threat from your threat model and write a simple test for it this week. You’ll be surprised what you discover.
Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.
Thank you for reading!
]]>The short answer: You need both.
Security tools are like really good watchdogs. They’re excellent at:
These tools have gotten way better over the years. They can scan millions of lines of code in minutes and catch mistakes that would take humans hours to find.
But here’s the thing - tools are great at following rules, but terrible at thinking creatively. Developers are still needed for:
Think of it this way: a security tool might tell you “this password field could be hacked,” but only a human developer can decide if that matters for your specific app and how to fix it properly.
The most secure companies don’t choose between tools and training - they use both together:
When developers understand security basics, they write better code that tools can check more effectively. It’s like having a good editor review a well-written first draft versus trying to fix a mess.
Don’t think of this as “tools vs. humans.” Think of it as “tools + humans = better security.”
Keep training your developers on security fundamentals, but also invest in good automated tools. Your future self (and your customers) will thank you when hackers come knocking.
Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.
Thank you for reading!
]]>The most significant weakness is Dependabot’s inability to handle transitive dependencies across most ecosystems. Looking at GitHub’s own documentation, only 4 out of 15 supported package managers have built-in transitive dependency analysis:
This means 73% of ecosystems lack native transitive dependency scanning. Python, Go, Rust, Ruby, .NET, and PHP developers get zero visibility into indirect dependencies unless they manually configure dependency submission actions.
Consider this: if you’re using pip for Python, Dependabot only scans your direct dependencies listed in requirements.txt. But your actual vulnerability exposure comes from hundreds of transitive dependencies you never directly specified. A vulnerability in a sub-dependency three levels deep remains invisible.
GitHub only added transitive support for Maven in March 2025. NPM support came earlier but still recently. Meanwhile, dedicated SCA tools have offered this functionality for years across all ecosystems.
The documentation reveals other problems:
.github/workflows/ to be recognizedAs noted in the GitHub Actions documentation: “Dependabot will only create Dependabot alerts for vulnerable GitHub Actions that use semantic versioning. You will not receive alerts for a vulnerable action that uses SHA versioning.”
The SBOM export documentation confirms that SBOMs are generated from the dependency graph, inheriting all its limitations. For ecosystems without transitive dependency support, your SBOM will miss critical components, making it unsuitable for compliance requirements like Executive Order 14028.
Dependabot works okay for small teams or projects where someone can manually triage alerts, but it scales poorly and lacks the intelligence that modern development teams need. Many organizations end up supplementing it with tools like Snyk Open Source, Semgrep Supply Chain or building custom filtering on top of it.
It’s basically the “good enough” option that’s better than nothing but frustrating if you need actual strategic dependency management.
Despite its limitations, Dependabot can work for:
If you’re stuck with Dependabot, you can improve the experience by implementing proper configuration and workflows. This guide shows how to set up automatic PR management using Dependabot: [How to Make Dependabot Actually Work for You]
Dependabot is not a comprehensive SCA solution. It’s a basic dependency updater with vulnerability alerts bolted on. The lack of transitive dependency support for 73% of ecosystems makes it unsuitable for serious security programs.
For organizations that need real supply chain security, look at dedicated SCA tools that offer:
Dependabot might be free, but the cost of missing vulnerabilities in your dependency tree could be much higher than investing in proper SCA tooling.
Feel free to contact me for any suggestions and feedbacks. I would really appreciate those.
Thank you for reading!
]]>