What you can upload
An SBOM, or the dependency files your package manager already writes. You can upload several files at once. They’re merged into one inventory and produce one plan.
SBOMs
- CycloneDX JSON
- SPDX JSON
Components are matched by their package URL (purl). A component without one can’t be checked at all. It’s counted and shown as unchecked, and never described as safe. VEX statements embedded in a CycloneDX file are applied. The findings they cover stay in the report, shown as suppressed alongside the statement.
XML SBOMs and SPDX tag-value files are refused, with a message explaining how to convert them to JSON. XML is left out on purpose: accepting it from anonymous uploads would open the service to a whole class of parser attacks.
Lockfiles and manifests
Files are recognised by name. A prefix is fine, so api-requirements.txt is still read as requirements.txt. Some names also accept a suffix, such as requirements-dev.txt.
- JavaScript (npm, Yarn, pnpm)
- package-lock.json, package.json, yarn.lock, pnpm-lock.yaml
- Python
- requirements.txt, Pipfile.lock, poetry.lock
- Rust
- Cargo.lock
- Go
- go.mod
- PHP
- composer.lock
- Ruby
- Gemfile.lock
- .NET (NuGet)
- packages.lock.json
A lockfile records the versions actually installed, which is what a vulnerability check needs. Two of these files usually hold ranges instead: package.json, and requirements.txt lines that aren’t pinned with ==. A range such as ^4.17.15 says what may be installed, rather than what is. Those components are checked at the bottom of the range and every finding on them is marked as range-derived. If you upload the lockfile as well, it takes precedence for its directory.
Limits
- Total upload
- 20 MB
- Files at once
- 25
- Components per scan
- 10,000
If any file isn’t recognised, the whole upload fails and the message names the file. Skipping it would understate the inventory and make it look safer than it is.