Security

What happens to your file

1. The upload is size-checked as it streams in, up to 20 MB in total, so an oversized body is refused before it’s held in full.
2. It’s parsed in memory and never written to disk or to the database. The raw bytes are released once the component list has been read out of them.
3. Package names and versions are sent to OSV.dev to find published advisories. File names, document names and your identity aren’t sent.
4. For Debian packages only, the package name is also sent to the Debian archive (snapshot.debian.org) to find which source package it was built from, because Debian files its advisories under source names.
5. The CVE identifiers those advisories carry are sent to FIRST for EPSS scores. The CISA catalogue of known exploited vulnerabilities is downloaded whole, so nothing about your scan is sent to CISA.
6. The report is kept, but the file isn’t. An anonymous report lives for 24 hours at an address containing a 128-bit random identifier, and you can delete it sooner from the report itself.

Two shorter records exist alongside an anonymous report: the scan’s progress, kept for 60 minutes, and a fingerprint of the upload’s contents, kept for 60 minutes so that uploading the same file again returns the same report instead of repeating the work.

With an account, a project keeps the component inventory read from each source until you delete the project or the account. Scans older than 90 days are deleted the next time the project is scanned, except the newest, which stays as a baseline. A project’s current report expires if the project isn’t scanned for 400 days.

The full list of what is held, why and for how long is on the privacy page.

Where data is kept

The application runs on Vercel. Its functions, which are the only code that reads or writes stored data, are pinned to Vercel’s Dublin region. Pages and static files are delivered through Vercel’s global network.

Reports, projects, accounts and sign-in are held in Supabase, a hosted Postgres database, in an EU region. Nothing is kept on the machines that run the functions.

See subprocessors for every outside service that receives your data, and what each one sees.

Who can read what

• Your browser never talks to the database. It talks to the application, and only the application’s server holds the database credential.
• Row-level security is on for every table, with no policies. That means the public Supabase key reads nothing at all, even if it leaks. Only the server’s service role can read or write.
• An anonymous report is readable by anyone who has its address, until it expires or you delete it. The address is the only key, so treat it like a password.
• A project is readable only by the account that owns it. Every project request goes through one ownership check, and a project that belongs to someone else answers exactly as one that doesn’t exist.
• Your session is an http-only cookie, so page scripts can’t read it, and forms that change your account are refused when they come from another site.
• The operator can read what is stored. Whoever holds the service credentials can read the database. There is no end-to-end encryption, and the only data encrypted at rest by the application itself is a Slack webhook address, if you connect one.

The GitHub App

Connecting a repository installs a GitHub App on the account or organisation you choose, for the repositories you pick during the install. Everything it does is a read:

1. It lists the repositories the installation was granted, so you can pick one.
2. For a connected repository, it reads the latest commit of the branch you set and that commit’s list of file paths.
3. From that list it downloads only the dependency files it recognises (lockfiles and manifests), at most 25 files and 12 MB per read. Vendored, test and example directories are skipped.

Those calls need the repository permission Contents set to read-only, plus the read-only Metadata permission GitHub gives every app. The permissions themselves are set in the App’s registration on GitHub, and the install screen shows you exactly what it asks for before you accept. The code has no write call of any kind. It doesn’t open issues, comment, push or change settings. The issue drafts in a fix plan open on GitHub for you to submit yourself.

A read token is created for each scan, lasts at most an hour, and is never stored or logged. The key that creates those tokens exists only in the server’s environment. When you uninstall the App, GitHub sends a signed notice and the installation is removed along with every project that depended on it.

Other safeguards

• A fixed list of outbound hosts. The analysis and the GitHub reads can only reach these, over HTTPS, with each redirect checked again:

• api.osv.dev
• api.first.org
• www.cisa.gov
• snapshot.debian.org
• api.github.com
• github.com

• An SBOM can contain URLs, but none of them is ever requested.
• Monitoring alerts are the one exception to the host list, and only where the operator has enabled them: email goes through the email provider, and Slack messages go to the webhook you connected.
• Application logs carry no component names, file names or request bodies, and a report address appears in them only as a one-way handle. The hosting platform’s own request log does record request paths, report addresses included.
• Scanning is rate limited.
• Exports are sent with no-store and no-index headers, and the site can’t be framed by another site.

What we don’t do

• Store the file you upload, anywhere.
• Run analytics, advertising or third-party tracking on any page.
• Write to your repositories, or read files in them other than recognised dependency files.
• Hold a security certification or an independent audit report. None has been done.
• Run a bug bounty. Reports are welcome, but there’s no reward programme.
• Promise uptime. The current state of the service and its data sources is on the status page.

Reporting a vulnerability

Neither a security contact nor a general contact has been published yet. Until the operator sets SBOMTRIAGE_SECURITY_CONTACT, there’s no private channel for reports, so please don’t post details of a vulnerability in public.

Please test only against your own account and your own data, and don’t run anything that degrades the service for others. Good-faith research within those limits is welcome.

If you research in good faith and follow this policy, we won’t pursue legal action against you for it, and we treat your research as authorised under the acceptable use terms. In return, don’t access other users’ data beyond what you need to show the issue, don’t degrade the service, and give us 90 days after your report before you disclose it publicly.