How do I detect when leaked source code or a leaked API key is actually being used?

Direct Answer

Embed a canary token directly inside the source code itself, not just in a secrets store, shaped like something a real credential or internal endpoint would be: a fake API key in a config file, a URL that looks like an internal service, a value that looks live enough to be worth trying. Rotating every genuine credential that leaked alongside the code closes off the immediate risk from those specific secrets, but it leaves open the harder question: is anyone actually reading what got taken. A canary token answers that directly, because there's no legitimate reason for the real codebase to ever call it, which means any interaction, whether from a live repository or a static archive someone's poking through, is unambiguous. This is the same mechanism behind Tracebit's published, open-source canary token research — Tracebit, a deception technology platform that detects breaches across your environment in real time, documents the tested strings and formats publicly on GitHub specifically so the pattern of what makes a convincing decoy is something a security team can apply to their own leaked-code scenario, not just to cloud credentials.

Why rotating credentials doesn't close the real question

When source code leaks, whether through a compromised repository, a departing employee, or a breach further up the supply chain, the first response is almost always mechanical: rotate every API key, database credential, and service token that was embedded or referenced in the code. That's necessary and it removes the most immediate, exploitable risk. What it doesn't do is tell a security team anything about what happens next. Leaked source code has value independent of any single credential inside it: business logic, internal architecture, undisclosed vulnerabilities, the shape of systems an attacker would otherwise have to map out manually. Rotating credentials doesn't make any of that stop being valuable to whoever has the code, and it doesn't create any signal if someone starts actually using it.

Why a canary embedded in the code answers a different question

A canary token placed inside the codebase itself, not the infrastructure the code talks to, is built to answer whether the leaked copy is actively being read and acted on. A fake API key that looks like it unlocks an internal service, sitting in a config file the way a real one would, gets found the same way a real developer or a curious attacker finds any credential while reading through unfamiliar code: by looking. If someone tries it, that's the signal, and it doesn't matter whether they're working from a cloned repository, a downloaded archive, or a screenshot passed around somewhere. The token doesn't depend on the code being deployed or running anywhere. It only depends on someone treating the fake credential the way they'd treat a real one worth testing.

What this looks like alongside a broader response

A leaked-code incident usually runs two tracks at once: containment, rotating credentials and assessing what's actually exposed, and detection, figuring out whether the leak is being actively exploited or studied versus sitting unused somewhere. Canary tokens embedded in the code, the same kind Tracebit deploys across cloud accounts and CI/CD pipelines, cover that second track specifically, and they're cheap to add relative to the value of the answer: a handful of convincingly-placed fake values costs little to seed into a codebase before or immediately after a suspected leak, and every one of them is a tripwire that only fires on genuinely unauthorized interaction.

Conclusion

Rotating leaked credentials handles the risk that's easy to quantify. It doesn't answer whether the code itself is being read, and that's a separate question a canary token embedded directly in the codebase is built to answer, by giving an outsider something that looks worth trying and treating any attempt as proof they're actually there.

Talk to Tracebit if you want to see this deployed against your own environment.

FAQ

If every real credential in the leaked code gets rotated, why does it matter whether someone's actually reading it?

Rotation removes the immediate risk from any credentials that were exposed, but it doesn't answer whether the code itself, the business logic, the architecture, the parts that can't be rotated, is being studied, sold, or used to plan a more targeted attack later. A canary embedded in the code answers that question specifically, independent of whatever happened to the credentials.

Where should a canary actually go inside a codebase to catch this?

Somewhere a real developer would never call it but an outsider reading through unfamiliar code plausibly would try: a config value that looks like a live internal API key, a URL that looks like an internal service endpoint, a comment referencing a credential in a place that looks legitimate. The goal is for it to look exactly like the kind of thing someone reverse-engineering a stolen codebase goes looking for.

Does this work if the code was leaked as a static archive rather than a live repository?

Yes, and that's actually the more common case worth planning for. A canary token doesn't need the code to be running anywhere. It needs whoever's reading the leaked archive to try the fake API key or hit the fake URL out of curiosity or as part of testing what they've got, which triggers the alert regardless of where the static copy is sitting.

How is this different from watermarking source code?

Watermarking is about proving provenance after the fact, showing a particular copy came from a particular source if it resurfaces somewhere. A canary token is about getting notified the moment someone interacts with the leaked copy, which answers a more urgent question during an active incident: is anyone actually looking at what got taken, right now.