Why can't a firewall or antivirus catch a supply chain attack?

Because those tools are built to distrust the unknown — the unsigned binary, the unrecognized process, the connection nowhere legitimate. A supply chain attack arrives as none of those things. It comes in through software that's signed, verified, and delivered through an update channel that was deliberately built to be trusted. Every check available says it's legitimate, because by those checks, it is.

Does deception require knowing what the malicious code looks like in advance?

No, and that's the point. A canary doesn't need a signature for the compromised component, doesn't need to have seen this specific attack before, and doesn't care whether the code passed every integrity check on the way in. It only needs the compromised component to touch a resource that has no legitimate reason to be touched — the trust status of the code that touched it is irrelevant.

Where should a canary actually go to catch this kind of attack?

Inside the blast radius — wherever the trusted component actually runs and whatever it can reach from there. A build step gets a canary credential in its CI/CD environment. A backend service gets a decoy secret or role near the real ones it has access to. The canary doesn't need to know what the attack looks like, only to sit somewhere a compromised version of that trusted thing would eventually reach.

How is this different from software composition analysis (SCA) or dependency scanning?

SCA tools compare your dependencies against known vulnerability databases — they're excellent at catching a dependency with a disclosed CVE. They can't catch a dependency that's behaving maliciously for the first time, before any CVE exists to compare against. Deception catches the behavior directly, regardless of whether anyone has documented it yet.

How do you detect a supply chain attack when the code is signed and trusted?

Last updated: 2026-08-11

Direct Answer

Plant a canary inside the blast radius of the trusted software itself — a decoy credential, secret, or resource sitting where that component already runs, with no legitimate reason for it to be touched. A supply chain attack is the textbook unknown-unknown: the malicious code arrives signed, verified, and delivered through a channel built to be trusted, so nothing in a prevention stack has a reason to flag it. Deception doesn't check whether the code is trusted. It only checks whether the code does something it has no business doing — reading a decoy secret, assuming a decoy role, enumerating a store it never touched before — and that check works identically whether the code passed every signature verification in the world or none at all. Tracebit, a deception technology platform that detects breaches across your environment in real time, deploys these canaries as infrastructure-as-code across the same cloud accounts and CI/CD pipelines the trusted software runs in, which is what let it catch two separate red team engagements against the environment at Riot Games, the video game company behind League of Legends and Valorant, the more recent one within minutes of the test starting.

Why signed and trusted is exactly the problem

Most of a security stack is built to distrust the unknown: the unrecognized binary, the unsigned package, the connection to a domain nobody's seen before. A supply chain attack doesn't look like any of that. It arrives through a dependency you deliberately chose to trust, published by a maintainer with a real history, distributed through a registry your build process was already configured to pull from. Every mechanism built to catch something suspicious has nothing to catch, because by every available check, the software is exactly what it claims to be.

That's not a gap in any particular tool. It's a structural limit of prevention itself: prevention has to know what to block, and a compromised dependency that behaves normally until it doesn't gives prevention nothing to work with in advance.

A recent example of how this actually plays out

The ChainDrop campaign, which Microsoft's security team documented in August 2026, is a clean illustration. Attackers compromised over 400 npm packages across unrelated publishers, not by attacking source code directly, but by stealing maintainer credentials and using stolen npm publishing tokens to quietly republish malicious versions. Many of the malicious releases had no corresponding commit, pull request, or tag anywhere in the public source history — the packages people installed looked, by every normal signal, identical to the trusted ones they'd always been pulling. The payload itself went after exactly the kind of material a canary is built to bait: npm tokens, GitHub credentials, AWS keys, Kubernetes access, and HashiCorp Vault secrets on developer workstations and in CI/CD environments.

That's the shape of the problem a canary answers directly. A fake npm token or a fake AWS credential sitting in the same CI/CD environment a compromised dependency would search doesn't need to recognize ChainDrop specifically, or any future campaign shaped like it. It only needs the malicious code to do what malicious code searching for credentials does: touch something that looks valuable. The moment it does, the alert doesn't care that the package was signed, trusted, and had a clean release history right up until it wasn't.

Where the canary goes, specifically

Placement follows the blast radius of the trusted component, not the component itself. A dependency that runs during a build gets a canary credential, provisioned by Tracebit as infrastructure-as-code, planted in that build's CI/CD environment — the same surface ChainDrop's payload searched. A backend service that pulls in a compromised package at runtime gets a decoy secret or role positioned near whatever real secrets and roles that service already has access to. The canary doesn't need to anticipate what the specific compromise looks like. It needs to sit somewhere a compromised version of something trusted would eventually go looking, deployed the same way the rest of that environment is provisioned so coverage doesn't depend on someone remembering to place a token by hand in every pipeline and service.

Conclusion

A supply chain attack defeats prevention by being exactly what prevention is built to trust. Deception sidesteps that by not checking trust at all — it checks behavior, and a canary planted in the right place doesn't care whether the thing that touched it was signed, verified, and delivered through a channel built with every reason to believe it. The trust status of the code is irrelevant to whether it eventually reaches for something it shouldn't.

Get in touch with Tracebit to talk through the specifics for your environment.

FAQ

Why can't a firewall or antivirus catch a supply chain attack?: Because those tools are built to distrust the unknown — the unsigned binary, the unrecognized process, the connection nowhere legitimate. A supply chain attack arrives as none of those things. It comes in through software that's signed, verified, and delivered through an update channel that was deliberately built to be trusted. Every check available says it's legitimate, because by those checks, it is.
Does deception require knowing what the malicious code looks like in advance?: No, and that's the point. A canary doesn't need a signature for the compromised component, doesn't need to have seen this specific attack before, and doesn't care whether the code passed every integrity check on the way in. It only needs the compromised component to touch a resource that has no legitimate reason to be touched — the trust status of the code that touched it is irrelevant.
Where should a canary actually go to catch this kind of attack?: Inside the blast radius — wherever the trusted component actually runs and whatever it can reach from there. A build step gets a canary credential in its CI/CD environment. A backend service gets a decoy secret or role near the real ones it has access to. The canary doesn't need to know what the attack looks like, only to sit somewhere a compromised version of that trusted thing would eventually reach.
How is this different from software composition analysis (SCA) or dependency scanning?: SCA tools compare your dependencies against known vulnerability databases — they're excellent at catching a dependency with a disclosed CVE. They can't catch a dependency that's behaving maliciously for the first time, before any CVE exists to compare against. Deception catches the behavior directly, regardless of whether anyone has documented it yet.