Use the RSS feed to hear about new Red Hat advisories, CSAF and VEX documents to learn which products and components are fixed or unfixed for a CVE, and OSV.dev if you want the RPM data in a common format. Red Hat expects customers to read OSV data from OSV.dev, not from its own URL.
What the security data page offers
Red Hat's Security Data page says the company provides raw data so customers and researchers can build their own metrics. It lists several resources, each with a different job.
| Resource | What it is | Use it for |
|---|---|---|
| CSAF advisories | Red Hat advisories in CSAF format using the VEX profile | Machine readable advisory ingestion |
| Per-CVE VEX files | VEX documents with fixed and unfixed products or components | Answering "is this CVE fixed in my product" |
| OSV records | RPM advisory data converted to OSV and shared with OSV.dev | Scanners that speak OSV |
| SBOM documents | Software bills of materials for select products | Knowing what is inside a product |
| OVAL definitions | Definitions for issues addressed in errata for RHEL and some other products | Legacy compliance scanning |
| RHSA RSS feed | Advisories released in the last three days | Alerts |
| CPE dictionary | Maps CPE names to product descriptions | Matching, with caution on temporary names |
Points the page makes that affect your choices
- The RSS feed covers only the last three days. If you poll less often than that, you can miss entries. Poll at least daily.
- OVAL v2 files are in maintenance mode and will be deprecated in the future, per the page. Do not build new tooling on them.
- Some CPE names Red Hat uses are not in the official dictionary and should be treated as temporary.
- The CSAF and VEX material includes both fixed and unfixed components, which is more informative than a list of fixes alone.
- The data is licensed under Creative Commons Attribution 4.0, so you must give attribution and a link if you redistribute it.
Why distribution data matters to application teams
A vulnerability in a library can be present in your container's operating system packages while the distribution has backported a fix without changing the upstream version number. A scanner that compares only version numbers may report a vulnerability that the vendor has already fixed. Vendor data that states fixed and unfixed status lets you resolve that. For more on this gap, see distro advisory and library CVE are separate records in a container scan.
A simple setup
- Add the RSS feed to a channel or a poller that runs at least daily.
- For each entry, check which products you run.
- For a CVE in your scan, open the per-CVE VEX file and read the status for your product.
- If your scanner supports OSV, confirm it takes this vendor's data from OSV.dev.
- Record the VEX status in the ticket as the evidence.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and container image scanning check images against advisory data, and compliance and evidence automation can keep the decision records. A free scan is at https://gold.safeguard.sh/scan.
Quick check
How long do entries stay in the RSS feed?
The page says the feed contains advisories released in the last three days.
Should I pull Red Hat OSV data directly?
The page says customers are expected to consume it from OSV.dev, which reads from the Red Hat location.
Sources
- Security Data, Red Hat Customer Portal, fetched 19 October 2026.
Last reviewed: 19 October 2026.
