Following the discussions around the LiteLLM compromise and today's terrifying telnyx zero-day, my team and I wrote up a technical breakdown of how the TeamPCP actors are bypassing legacy SCA tools.

The tl;dr is that traditional scanners are looking for signatures, while the attackers are weaponizing context. By hiding an executable payload inside mathematically valid .wav audio frames, TeamPCP ensured that content filters and CVE databases waved the Telnyx payload right through.

We spent the weekend building an open-source CLI (wtmp) to hunt for this exact behavior. Instead of asking "Is this package on a blacklist?", it maps your Node/Python dependency graph and uses a LangGraph process to actually read the code. It asks things like: "Why is a telephony SDK running an XOR decryption loop on an audio file and piping it to a shell?"

The reality check: Because it relies on LLMs to infer intent, expect false positives. It is not a deterministic CI/CD blocker; it’s a flashlight to help you triage your blast radius during an active crisis like today.

I’ll be hanging out in the comments. I’d love for you to read the write-up, test the CLI against your local trees, and absolutely tear apart our prompt architecture and logic.

Thanks for taking a look at the docs. That section covers the default behavior of the CLI, which acts as a standard OSV known-vulnerability checker (since basic signature hygiene is still step one).

The semantic/behavioral analysis we built to hunt for these Telnyx/LiteLLM zero-days is a new module we just pushed this weekend. You trigger it using the --supply-chain flag (which requires an Anthropic API key).

When run with that flag, it moves past the OSV database and runs the LangGraph intent analysis on the actual dependency code. I'll get the landing page updated today to make the --supply-chain flag and LLM capabilities more prominent.

The 'flashlight not a blocker' distinction is the right call. Curious to know - how do you handling false positive rate in practice?

In our experience with LLM-based code analysis, the signal-to-noise ratio is the thing that determines whether teams actually use the tool or just forget about it after a week.

The linked page seems to be a normal known vuln checker? From doc :

""" The tool will:

    Recursively find all package.json and requirements.txt files
    Parse the dependencies
    Query OSV
    Display a beautiful report