Rafter Is Now on the GitHub Marketplace

Rafter is now on the GitHub Marketplace. You install it, add the Rafter Action to your workflow, and your next push gets scanned in CI — dependency and supply-chain findings, committed secrets, and a security score on the report.

This post is the argument for why a one-click install at the place your code already lives is the right shape for the threat we're seeing right now, not a convenience feature we tacked on.

The repo became the attack surface

In May 2026, Socket documented a campaign it named TrapDoor: 34+ malicious packages spread across npm, PyPI, and Crates.io, totaling 384+ versions. The earliest, a PyPI package named eth-security-auditor, was published May 22, 2026. Each ecosystem got a tailored execution path — build.rs for Rust, a postinstall hook for npm, and import-time execution for Python.

The credential stealer targeted wallets, SSH keys, cloud credentials, browser profiles, and environment variables, and it used Git hooks and AI-assistant config files for persistence. That part is not what makes TrapDoor worth a blog post.

What makes it worth a post is the delivery. The attackers embedded hidden instructions inside CLAUDE.md and .cursorrules files using zero-width Unicode characters. You open the file and see nothing unusual. Some AI coding tools may read those hidden instructions, depending on the tool and the model. Socket reported that the hidden text appeared designed to trick Cursor or Claude Code into running a fake "security scan" that could exfiltrate the secrets above, and it cautioned that the technique may not work consistently — so treat it as an attempted poisoning path rather than a guaranteed one.

They didn't stop at packages. The campaign opened malicious pull requests against real, widely depended-on projects, including browser-use/browser-use, langchain-ai/langchain, and langflow-ai/langflow. Public reporting does not show those PRs were merged, so treat the PR route as an attempted secondary vector rather than a proven one.

The shape of that is worth slowing down on. The trust boundary most developers rely on is "I read the diff, it looked fine." TrapDoor shows a credible way to bypass review practices that lean on visible diffs alone, because the bytes that mattered were invisible to the human and legible to the agent working alongside them.

The moment vibe-coded becomes real code

There's a specific moment in every project where the risk changes character. It's when a prototype you generated in an afternoon stops being a toy and becomes a repo that other people clone, depend on, deploy, and run in CI.

Before that moment, a poisoned dependency or an invisible instruction in a config file is a problem for one machine — yours. After that moment, it's a problem for everyone downstream of you, and for every secret your CI runner can reach.

That transition often arrives with no security review attached, because the review lives somewhere else. It lives in a separate tool you have to remember to run, a pipeline you have to stand up, or an audit you have to schedule for a quarter that keeps slipping. The friction between "this is real now, I should secure it" and actually doing it is exactly where the window opens.

This is the same lesson the config-as-execution incidents taught over the past year: project files that used to be inert metadata now carry execution semantics, and the trigger is often passive. The dangerous step can be routine installation, build, import, or an agent processing the repo's instructions, rather than an obvious manual command. TrapDoor is that pattern aimed squarely at your AI assistant.

Security has to live where the code lives

The fix for that friction is not a better reminder. It's putting the control in the place where the decision is already being made.

You are already in GitHub. The code is already in GitHub. The pull request — the precise moment where new code asks to become part of the project — already happens in GitHub. So the security review should happen in GitHub too, on the same push, without a context switch.

That's why Rafter is now on the GitHub Marketplace. You install it and add the Rafter Action to your workflow, and the next push runs a scan in CI.

What the scan produces

Dependency and supply-chain analysis is the first thing the Action surfaces. Rafter flags known-vulnerable packages and groups the CVE findings by package, so instead of a flat list of forty advisories you see which dependency is dragging in the risk and what upgrading it would clear. For a campaign like TrapDoor, the operative question is "what did this repo just pull in, and is any of it known-bad" — and dependency scanning helps answer that for the vulnerable or known-malicious packages its advisory sources cover.

Secrets scanning runs across the repo, so the access key or token that got committed in a hurry surfaces before it ships rather than after an attacker finds it.

A security score lands on the report. One number that moves as you fix things, with the findings behind it, so the state of the repo is legible at a glance instead of buried in CI logs.

Two scan modes exist for the two situations you're actually in. Fast mode keeps the scan quick enough to run on every push without becoming the thing people disable to unblock a merge. Plus mode goes deeper for the changes that warrant a harder look.

What this fixes, and what it doesn't

A Marketplace scan does not read the zero-width Unicode in a poisoned CLAUDE.md and tell you a hidden sentence is buried in it. That's a different detection problem, and being clear about scope is the point of this section rather than a footnote to it.

What the scan does is shrink the part of the attack surface that's mechanically checkable, at the moment it's cheapest to check. A package with a known malware advisory, a dependency with a CVE, a leaked credential, a supply-chain advisory against something you just added — those are findings a scan can put in front of you on the same push that introduced them, when they're covered by the scanner's advisory sources, before the prototype-that-became-real ships to everyone downstream.

The campaigns will keep getting more creative about delivery. The defensive move that keeps pace is not a smarter quarterly audit; it's a control that runs where the code already lives, on every change, with no step between deciding to secure something and securing it.

Get started

Install Rafter from the GitHub Marketplace and add the Action to your workflow. Your next push gets scanned, and the report comes back with the dependency findings, the secrets check, and the score in one place.

# .github/workflows/rafter.yml
name: Rafter Security Scan
on: [push, pull_request]
jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Raftersecurity/rafter-cli/github-action@v1
        with:
          api-key: ${{ secrets.RAFTER_API_KEY }}
          severity-threshold: high

Add your RAFTER_API_KEY as a repository secret under Settings → Secrets and variables → Actions, and the scan runs on every push and pull request.

If you'd rather own Rafter outright instead of running it on a subscription, the AppSumo lifetime deal is still live.

The gap between "I should secure this" and actually doing it used to be a budget cycle. Now it's one click in a tab you already had open.

Further reading

• The AI Agent Attack Surface Is Real: 5 Incidents That Prove It
• git clone Considered Harmful: How Malicious Repos Exploit AI Coding Tools
• Silent Exfiltration: How Secrets Leak Through Model Output
• When Your AI Agent Becomes the Hacker