Python Vulnerability Lookup

Simon Willison built a security tool last week, and he wants you to know he cannot verify it works.

The tool is called Python Vulnerability Lookup. Released March 29, it is a single HTML file — 674 lines in the simonw/tools GitHub repository — that queries OSV.dev, Google's open source vulnerability database, and returns known CVEs for your Python project's dependencies. You paste a pyproject.toml, requirements.txt, or a GitHub repository URL, and it shows you what vulnerabilities your packages have. Willison built it with Claude Code, which is to say: an LLM wrote the code and he barely reviewed it.

This is not a secret. Willison — co-creator of the Django web framework and creator of the Datasette data-exploration tool — disclosed exactly this two days earlier. On March 27, he published a post about vibe-coding two macOS menu bar apps — Bandwidther and Gpuer — with the headline admission: "I do not know Swift and I hardly glanced at the code they were writing." He added warnings to both GitHub repositories. He had caught Gpuer reporting he had 5GB of memory left when he clearly did not.

"I am completely unqualified to evaluate if the numbers and charts being spat out by these tools are credible or accurate!" he wrote on March 27.

Five days earlier, on March 24, Willison had published something that landed harder: a walkthrough of the litellm v1.82.8 supply chain attack. A malicious actor published a compromised version of the popular LiteLLM package to PyPI — Python's official package index — containing a credential stealer hidden in a configuration file. Installing the package triggered it even without importing the library. The stealer scraped SSH keys, AWS credentials, git configs, and more from the developer's home directory. PyPI quarantined the package within hours, but anyone who installed it during that window was already compromised.

That litellm post is the backdrop for Python Vulnerability Lookup. The tool Willison published March 29 is the kind of thing that might — might — have helped someone catch a malicious package before installing it.

The tension is not subtle. Here is a developer who has spent years building trusted open source infrastructure. He published a post acknowledging that his own recent code, produced via vibe coding, could be returning incorrect data. And five days later he shipped a security tool, built the same way, that the community is now supposed to trust for checking whether their dependencies are safe.

Willison did not hide the caveat. The tool's page notes it was built with Claude Code. His GitHub account is well-known in the Python ecosystem — it hosts Datasette and llm, his widely-used CLI tool for running LLMs locally. That credibility is also what makes the self-deprecation notable. Most tool makers do not advertise the gaps in their own verification. Willison has built a following partly on being direct about what he knows and does not know. The Bandwidther and Gpuer posts are not humble-bragging — they are genuinely useful documentation of what vibe coding looks like in practice: fast, functional, and unreliable in ways the builder cannot always catch.

Whether that same transparency is sufficient in a security context is the open question. A menu bar app showing wrong memory readings is inconvenient. A vulnerability lookup missing a CVE is a different kind of problem. OSV.dev itself is a credible database — Google maintains it, and it aggregates vulnerabilities from the Python Packaging Advisory Database, GitHub Advisory Database, Debian, the Linux kernel, and dozens of other sources. The risk is not in OSV.dev; it is in whatever the HTML layer does with the data.

The litellm attack Willison documented gives this real stakes. PyPI supply chain attacks play out on a timescale of hours. A developer who pastes a requirements.txt into a web tool and sees no vulnerabilities is doing exactly the workflow that litellm exploited. If the tool misses something because the HTML layer introduced a bug, or because the API response got misparsed, that developer walks away with false confidence.

The tool is available at simonw/tools on GitHub. OSV.dev's API has no rate limits and supports browser-based CORS queries, which is what makes the single-file approach technically viable. Willison's own posts on the vibe-coded SwiftUI apps and the litellm supply chain attack document his thinking directly.