From the
team.

TL;DR

• What happened: A threat actor (the same group behind the earlier Trivy and LiteLLM compromises) stole CI credentials from Checkmarx, pushed malware into their public KICS Docker image and two of their VS Code extensions, and dumped Checkmarx’s internal source code on the dark web.
• What was NOT compromised: Customer scan data. Checkmarx confirmed publicly that customer source code is never stored in their internal GitHub repos.
• What WAS compromised: Customers who pulled the poisoned Docker image (~28 minute window) or the poisoned VS Code extension versions had credential-harvesting code execute on their developer machines and CI runners.
• The Bitwarden CLI angle: A separate but related attack used a compromised CI runner with valid credentials to publish a poisoned Bitwarden CLI build, exfiltrating secrets from the runners that pulled it.
• The structural problem: Hosted security tools auto-update their published artifacts. When their pipeline gets popped, every customer pulling the latest version is the target.
• What Snitch did this week: Shipped v7.4.0 with a runtime egress allowlist, build-time URL audit, SLSA build provenance, npm publish provenance, recommended SHA pinning over @v1, and published a full threat model. The result: even if our publish credentials get popped tomorrow and a malicious version of the Action ships to every customer, the runtime allowlist throws on any attempt to exfiltrate data to an attacker host.

Timeline of the Checkmarx incident

The chain unfolded over five weeks. Each step is independently documented in vendor and press disclosures (links at the end of this post):

• March 23, 2026: The TeamPCP threat actor group used CI credentials stolen via earlier Trivy and LiteLLM supply-chain attacks to compromise Checkmarx’s GitHub Actions workflows.
• March 30, 2026: Attackers exfiltrated GitHub repository data: source code, API keys, employee credentials. Customer scan data was not in scope.
• April 22, 2026: Second wave: poisoned Docker Hub tags on the public KICS image (Checkmarx’s open-source IaC scanner) and two VS Code extensions (ast-results 1.17.0 and Developer Assist 1.19.0) shipped with credential-harvesting payloads. The KICS image was malicious for ~28 minutes; the GitHub Action that depends on it was compromised for ~84 minutes; the VS Code extensions were patched in version 1.18.0.
• April 25, 2026: The exfiltrated GitHub data was posted on the dark web by LAPSUS$, who claimed credit alongside the original TeamPCP group.

Checkmarx’s communications throughout were unusually forthright by industry standards: dated security updates, scope disclosures, and an explicit claim that customer scan content was never accessed because it’s never persisted in the compromised repositories. We take them at their word here. The framing of “they leaked our scans” that’s floating around isn’t accurate.

What did happen is arguably worse for the AppSec category as a whole: customers who trusted Checkmarx’s publishing pipeline (Docker Hub, VS Code Marketplace) had attacker code running on their dev machines and CI runners. The vendor’s tools became the attack vector.

The Bitwarden CLI angle: a runner credential is enough

During the same window, the Bitwarden CLI was compromised through an adjacent but separate vector: a CI runner with stolen credentials published a malicious version of the official@bitwarden/cli package. Anyone whose CI pipeline or dev environment pulled the latest version had their secrets exfiltrated to an attacker-controlled endpoint.

The lesson is the one that’s easiest to dismiss because it sounds basic: a single compromised runner credential, not a zero-day, not a model error, not a social engineering campaign against the CISO, is enough to weaponize an entire publishing chain. Once an attacker can publish under your name, your “trusted” auto-update is their attack delivery mechanism.

For tools the customer’s CI pulls and runs, SAST scanners, secret managers, security audit GitHub Actions, this is the whole game. The customer’s code doesn’t have to have a single vulnerability. The customer’s identity and access systems don’t have to be misconfigured. The customer’s developers don’t have to click anything suspicious. They just have to keep using the tool they paid for, on the version the tool’s vendor said was the latest.

Why “hosted security tool” is structurally a target

Three properties make AppSec tools especially juicy targets:

1. They run with elevated trust on customer machines. A SAST scanner needs to read every file in your repo. A secret scanner needs to grep through environment variables. An IaC scanner needs to evaluate your cloud configuration. The whole product’s value depends on having privileged access to the things attackers most want.
2. They auto-update. The pinning hygiene that customers do for application dependencies (npm ci, lockfiles, Renovate) typically isn’t applied to security tools, where customers want the “latest threat detection.” @v1 on a GitHub Action force-updates to whatever the publisher pushes today.
3. They run in CI environments with broad credentials. The CI runner that scans your code also has access to your AWS deploy role, your npm token, your Stripe webhook secret. A scanner that decides to phone home is in a privileged position to phone home with a lot.

Combine those three and you have an attack class where compromising the vendor is more efficient than compromising any individual customer. The Checkmarx incident is the textbook example. Bitwarden CLI is a smaller-scale demonstration of the same mechanic. There will be more.

What Snitch did this week (v7.4.0)

We had three of the four structural defenses in place before this week (BYO-key, source-never-leaves, minimal Action permissions). The Checkmarx incident pushed us to ship the fourth, and we did this week as part of the v7.4.0 release. Here’s the full stack now:

1. Runtime egress allowlist (NEW in v7.4.0)

The single most important defense. The very first thing the Snitch GitHub Action and CLI now do, before any scan code runs, is install a wrapper around the global fetchfunction. The wrapper checks every outbound request against an allowlist of hostnames Snitch knows it needs to talk to:

// from packages/snitch-github/src/egress.ts (excerpt)
const SNITCH_HOSTS = new Set<string>([
  "snitchplugin.com",
  "api.osv.dev",
  "api.github.com",
  "uploads.github.com",
  // ... GitHub Actions internal services
]);
// Plus the customer-selected AI provider host (and only that one).

Any request to a host not on this list throws aSnitchEgressBlocked error and surfaces as a loud::error:: in the workflow log. A poisoned transitive dependency that tries to call out to attacker.example.com(or even to a different AI provider than the one the customer selected) cannot complete the request. The customer sees the attempt the moment it happens.

This is the structural answer to the Bitwarden incident. Even with attacker code running inside our published package, the attacker has to reach out to their own infrastructure to get any value from it, and the egress check stops them at that gate.

2. Build-time URL audit

Defense in depth. Before every Action publish, our publish script runs scripts/audit-dist-urls.sh, which greps the bundled dist/index.js for every URL it contains and fails the publish if any URL is on a hostname not on our allowlist. A poisoned transitive dep gets caught at publish time instead of at customer runtime.

3. SLSA build provenance

The snitchplugin/snitch-github-action mirror runs a GitHub Actions workflow on every release that usesactions/attest-build-provenance to attach a Sigstore-signed claim that the dist/ bundle was built from a specific source commit on a specific GitHub-hosted runner. Customers verify with:

gh attestation verify dist/index.js --owner snitchplugin

Same for the CLI on npm: npm publish --provenanceattaches a verifiable claim. Customers verify with npm audit signatures.

4. SHA pinning, recommended in the install snippet

The dashboard YAML template now recommends pinning to a specific commit SHA for security-sensitive repos:

# For supply-chain hardening (recommended for security-sensitive repos),
# pin to a specific commit SHA instead of @v1:
- uses: snitchplugin/snitch-github-action@<40-char-sha>  # vX.Y.Z

Customers on @v1 auto-update. Customers on a SHA opt into immutable, vetted versions. If our publish credentials get popped, SHA-pinned customers are completely unaffected.

5. Minimal Action permissions

Our action.yml requests only:contents: read, pull-requests: write,security-events: write, statuses: write, and models: read. We do not requestactions: write (can’t modify your CI configs),id-token: write (can’t mint OIDC tokens against AWS / GCP), or packages: write (can’t publish to your registry). Even if a malicious version of our Action runs, the maximum blast radius is “comment on a PR, write a SARIF, set a check status”, not arbitrary code execution against your cloud accounts.

6. Source never leaves your machine

Snitch’s servers do not have, and structurally cannot have, the contents of any file you scanned, the findings produced by any scan, or your repo / org / PR identifier (we hash it client-side before sending). The AI inference happens on your runner against your own provider key. We never see your prompts or responses. So even in the imaginary worst case where Snitch gets popped, our customer database does not contain anything that maps back to your source.

What happens if our publish credentials get compromised

Realistic worst case: an attacker with our npm token + GitHub publish credentials pushes a malicious version of the Action to the @v1 tag.

1. Customers on @v1 get the malicious code on their next CI run.
2. The runtime egress allowlist catches any attempt to exfiltrate to an attacker host. Their CI run logs show ::error::[snitch-egress] Blocked outbound request to <host>.
3. The Action’s permissions cap the damage: the worst the malicious code can do is comment on a PR or set a check status, not exfiltrate secrets to an attacker’s server.
4. SHA-pinned customers are completely unaffected.
5. We rotate credentials, force-revert @v1, post an incident notice on snitchplugin.com/changelog within 24 hours, and email every active customer.

The full threat model lives at /docs/security. It’s public; read it before you trust us with anything.

Lessons for buyers of AppSec tooling

If you’re evaluating any security scanner that runs in your CI or pulls from your developers’ machines, ask the vendor these five questions before you buy:

1. What hostnames does your tool talk to at runtime, and is there a runtime check that enforces it? If the answer is “trust us” or “the docs are accurate,” that’s not enforcement. The Bitwarden incident proves that the gap between “the docs say we don’t” and “the runtime can’t” is the gap an attacker drives a truck through.
2. How is your published artifact signed? Sigstore / SLSA provenance / npm provenance / GitHub attestations are all reasonable answers. “We use a strong CI password” is not.
3. What permissions does your tool require? If it asks for id-token: write or actions: write and isn’t a deployer, push back. Most security tools don’t need either.
4. Where does my source code go? If the answer involves your code crossing the vendor’s infrastructure, treat the vendor as a single point of failure for the confidentiality of every codebase you point it at.
5. Can I pin to a specific version that you cannot retroactively replace? If the only available pin is a moving tag, you’re subscribing to whatever the vendor pushes next.

Snitch’s answers to all five live in our public threat model. We don’t expect every vendor in this category to adopt the same defenses, but we do expect every buyer to ask the questions.

Where to learn more

Snitch documentation:/docs/security (full threat model),/docs/iac (the new IaC scanner),/docs/dependencies (SCA),/docs/dead-code (DCA),/changelog (v7.4.0 release notes).

Vendor disclosures and press coverage of the Checkmarx incident:

• Checkmarx Security Update: April 22
• Checkmarx Security Update: April 26
• Checkmarx Supply Chain Incident Update
• Checkmarx Confirms GitHub Repository Data Posted on Dark Web (The Hacker News)
• Malicious KICS Docker Images and VS Code Extensions (The Hacker News)
• Bitwarden CLI Compromised in Ongoing Campaign (The Hacker News)

The Snitch GitHub Action is at /action. Free with GitHub Models, runs in your runner. Snitch's servers never receive your code, and we don't store anything about it. The egress allowlist ships with every release starting v7.4.0.

Have a security concern, an incident report, or a tip on a vendor we should look at? Email eric.waters@snitchplugin.com.

What the scan found

Four representative findings from the run:

• CriticalCloud metadata SSRFapp/api/appointments/route.ts:47

  An endpoint fetched a user-supplied callback URL with no validation. With @aws-sdk/client-s3 in the stack, an attacker could redirect that fetch at the AWS metadata endpoint and exfiltrate IAM credentials.

• CriticalMalicious install-script patternpackage.json:6

  The preinstall script silently curled an external URL and swallowed failures. If that host is ever compromised or name-squatted, every developer and CI machine runs whatever it returns, with failure hidden behind `|| true`.

• HighReDoS in email validatorapp/api/validate/route.ts:6

  An email regex used nested quantifiers, the classic shape for catastrophic backtracking. One crafted request can pin the event loop and stall the process.

• HighPrototype pollution via user JSONapp/api/validate/route.ts:23

  Object.assign was given a JSON-parsed user object. That path invokes the __proto__ setter, polluting Object.prototype for every other request the worker handles.

What Snitch does with a finding

Every finding in the report carries the same payload: file path, line number, the exact code evidence, the risk in plain language, a concrete fix, and CWE, OWASP Top 10:2025, and CVSS 4.0 tags. No hand-waving. If Snitch cannot show you the vulnerable line, it does not report it, that rule is baked into the skill itself.

After the report is displayed, Snitch offers to fix findings one by one or in a batch. Scanning and fixing are always two phases. The scan is read-only. Nothing touches your files until you pick a fix and confirm it.

Why Snitch exists

AI coding tools write most of the code now. They’re fast, they’re capable, and they’re good enough that the demo always works. But demos aren’t the failure mode. The failure mode is the webhook that doesn’t verify signatures, the callback URL that is never validated, the regex that looks like email validation but is actually a denial-of-service switch.

Traditional scanners drown you in 500 findings. Ad-hoc AI review prompts miss the structural classes of bugs. Snitch sits in the middle, 68 structured categories, evidence-first reporting, contextual false-positive suppression. First line of defense for code that was vibe-coded into existence in the first place.

One audit, every model you vibe with

Vibe coding isn’t one model anymore. Developers reach for whichever frontier model is best at the task in front of them. Snitch runs inside all of them:

• Claude Opus 4.7 , inside Claude Code
• OpenAI Codex 5.4 , inside Codex CLI
• Gemini 3.1 Pro , inside Gemini CLI

Same catalog, same evidence requirements, same fix flow, whichever model you’re pairing with. The vibeHealth audit you just read was executed by Claude Opus 4.7. The exact same scan, run by Codex 5.4 or Gemini 3.1 Pro, produces the same findings.

What’s new

These target the classes of bugs we kept seeing in audits without a dedicated check for them:

• ReDoS, regex patterns that hang your server on crafted input
• Prototype Pollution, __proto__ and deep-merge attacks through user JSON
• JWT Algorithm Attacks, signature bypass and algorithm confusion
• Cloud Metadata SSRF, outbound fetches that leak AWS / Azure / GCP credentials
• Insecure Deserialization, Python pickle, Java object streams, Ruby Marshal, PHP unserialize, unsafe YAML
• Typosquatting & Install Scripts, lookalike package names and suspicious postinstall hooks
• Type Coercion Bypasses, loose equality in auth paths, non–constant-time password comparisons
• Agent Prompt Injection, RAG and tool-use patterns that let untrusted data steer the model

Every plan gets every category

Free, Base, Pro, and Enterprise all include the full catalog. Upgrade if you need more rulesets, more projects, or higher limits, not for category access.

How to upgrade

Check your original purchase email and run the install command you received. It pulls the latest version automatically:

curl -sL https://snitchplugin.com/x/YOUR_TOKEN.sh | sh