A public, LLM-maintained knowledge base tracking security audit coverage of the most-downloaded open source packages across all major ecosystems.

How much of this can I trust? See METHODOLOGY.md — it explains exactly what is LLM advisory-mapping (verifiable lookups, every row linked to a primary source) versus human-verified source review, and how to check any claim yourself.

Built in the Karpathy llm-wiki pattern: raw sources feed into a persistent, compounding wiki maintained by LLMs.

Every major vulnerability database (OSV, NVD, Snyk, GitHub Advisory) tracks vulnerabilities after they're found. None of them answer:

"Has anyone ever done a proactive security audit of this package?"

A maintainer whose package has 50M weekly downloads has no way to know if anyone has systematically looked for RCE, prototype pollution, path traversal, or supply chain attacks in their code. This knowledge base fills that gap.

For each package:

• 📦 Download stats — weekly/monthly downloads from registry APIs
• 🔍 Audit history — who looked, when, what scope, what methodology
• 🐛 Findings — bugs found (with links to issues/CVEs), bugs not found (equally important)
• 🔒 Security posture — disclosure policy, security contact, last known review
• 🕸️ Dependency risk — transitive dependencies, known-vulnerable deps

raw/                    ← Immutable source documents (audit reports, CVE writeups, researcher posts)
wiki/
  index.md              ← Master searchable index (LLM-maintained)
  log.md                ← Append-only ingest/audit log
  TEMPLATE.md           ← Canonical page template / stub starting point
  npm/                  ← Package pages + ecosystem landing page
  rust/
  dotnet/
  python/
  go/
  homebrew/
  kubernetes/
  linux/
SCHEMA.md               ← LLM wiki maintenance instructions
CONTRIBUTING.md         ← Contributor workflow and evidence standards
SECURITY.md             ← Security reporting process for this repo

For maintainers: Search the wiki for your package. If it's not there or shows "not audited" — that's a data point. Consider commissioning an audit or reaching out to security researchers.

For security researchers: After completing an audit (regardless of findings), open a PR adding or updating the package's wiki page. Zero-finding audits are just as valuable — they establish baseline coverage.

For developers: Before adding a dependency, check its audit history here alongside its CVE history.

1. Fork the repo
2. Add or update a wiki page in the appropriate ecosystem folder
3. Add your source document to raw/ if applicable
4. Update wiki/index.md, the relevant ecosystem landing page (for example wiki/npm/index.md), and wiki/log.md
5. Open a PR

See SCHEMA.md for page format conventions and CONTRIBUTING.md for evidence / review expectations.

This is not a replacement for OSV, NVD, or Snyk. It's a coverage layer on top — tracking the research process, not just the outcomes.

A searchable web interface is published at travis-burmaster.github.io/oss-security-kb (built from wiki/ on every push). The GitHub repo is the source of truth; the website is a read-only view.

The contents of this knowledge base are licensed under CC BY 4.0. Use it, build on it, cite it — attribution appreciated.

Maintained by Travis Burmaster with LLM assistance. Not affiliated with any CVE authority or standards body. See METHODOLOGY.md for what that means in practice.