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.

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 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

"""

undefined