Yes. The OSV schema is open, and it requires only an id and a modified timestamp. To be useful to scanners, add affected packages with version ranges using introduced and fixed events. Choose your ID prefix carefully and register it through a pull request if you want it recognized.
Required and useful fields
According to the OSV schema page, id and modified are always required, and schema_version is required above 1.0.0. Everything else is optional, but an advisory with no affected data tells a scanner nothing.
| Field | Why vendors care |
|---|---|
| id | Format is a database prefix, a dash, then an entry ID, using letters, digits, colon, underscore, dot and dash |
| modified | RFC 3339 UTC time. For the same id, the later modified value wins |
| affected | Package with ecosystem and name, plus ranges or an explicit versions list |
| events | Each has exactly one of introduced, fixed, last_affected or limit |
Writing the range
Each events list must contain at least one introduced entry. The value "0" means before any other version. The page says fixed is strongly preferred over last_affected, which can cause false negatives. A range may use one or the other, not both.
For a product that is not a package, you may use a git range, which needs a repository and lists commits. The schema asks that fixed list cherry picked fixes on every branch to avoid false positives, which matters for you if you backport fixes to several support branches. A strict ranges type for semantic versions requires strict ordering and no overlap. For other schemes use the ecosystem type, where versions are uninterpreted strings, and give an explicit versions list.
IDs and prefixes
The page says publishers should work within their reasonable scope. Use your own prefix. Local databases that are not aggregated use an x_ prefix. New IDs should be semantically neutral: no vulnerability type, package name or severity inside the ID. To derive an ID from a CVE, add your prefix, such as the example DEBIAN-CVE-2000-0001. To register a new prefix or ecosystem, the page directs contributors to submit a pull request.
Steps
- Pick the ID prefix and the ecosystem naming.
- Write one record per vulnerability, listing every affected product line.
- Use fixed events with the first corrected version on each supported branch.
- Update modified whenever you change the record, and keep the same id.
- Host the files at a stable URL and link them from your advisory page, as described for your own advisory template.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how affected and fixed versions drive what a customer sees.
If you want a second look at what you ship, Safeguard can generate and scan an SBOM and run dependency scanning with reachability analysis, and you can try the free scan.
Quick check
Do I need both ranges and a versions list?
The schema generally recommends a versions list even when ranges are present, and requires one for ecosystem and git style ranges.
Should I use last_affected?
Prefer fixed. The schema page warns last_affected can cause false negatives.
Sources
Last reviewed: 19 October 2026.
