Security

For the communities this serves, security isn’t abstract — a missed detail can put real people at real risk. We ask you to trust this catalog’s judgment about what’s safe to depend on, so we hold ourselves to the same standard we ask of the tools in it: an honest posture that holds up to inspection, and a door that’s open to anyone who finds a gap.

Reporting a vulnerability

Please report privately first

If you find a security issue in this site, the enforcement engine, or a recipe, report it privately via GitHub Security Advisories on the repository rather than opening a public issue. We aim to acknowledge within 5 business days.

Please include: what you found, how to reproduce it, and the impact you see. If it’s a false positive or false negative in the enforcement engine, a failing test case is the most useful thing you can send.

What the site is — and isn’t

This is a static site. There is no server-side application, no database, no user accounts, and no user-submitted data processed at runtime. The attack surface is correspondingly small: the build pipeline, the dependencies, and the hosting configuration.

Supply-chain integrity

The catalog’s reason to exist is supply-chain accountability, and it is applied to the catalog itself:

• Every dependency is screened by the three-layer enforcement engine on every pull request — direct, transitive, and provider-string layers.
• Licenses are pinned to a commit, not just declared, so a silent relicense is detectable.
• A weekly license-watcher hashes upstream LICENSE files and scans recent commits for relicensing keywords, opening a PR when something drifts.
• A weekly maintenance-checker reclassifies entries that have gone dormant or abandoned.

Secrets and tokens

The site needs no secrets to build the catalog. Deployment uses a scoped Cloudflare API token and account ID stored as repository secrets; an optional GITHUB_TOKEN raises rate limits for the indexing and weekly jobs. No model- provider keys are ever required or stored — anything that talks to a model does so client-side, BYOK, per the recipes.

Hardening checklist (what CI enforces)

• Content schema validated with astro check.
• Enforcement engine green (Layers 1–3 + recipe contract).
• Dead-link checking on every PR.
• Pinned action versions and Node version in CI.
• No analytics or third-party scripts unless explicitly configured.