Redefining how we share our security data.

综合技术 2016-06-23

Red Hat Product Security has long provided various bits of machine-consumable information to customers and users via ourSecurity Data page. Today we are pleased to announce that we have made it even easier to access and parse this data through our new Security Data API service.

While we have provided this information since January 2005, it required end users to download the content from the site, which meant you either downloaded many files and kept a local copy, or you were downloading large files on a regular basis. It also meant that, as part of writing the parser, if you were looking for certain criteria, you had to account for that criteria in your parser, which could make it more complex and difficult to write.

Although the Security Data API doesn’t remove the need for a parser (you need something to handle the provided data), it does offer a lot of search options so that you can leverage the API to obtain real time data.

So what information can you obtain via the API? Currently it provides CVE information for flaws that affected components we ship in supported products, as well as CVRF (Common Vulnerability Reporting Framework) documents and OVAL (Open Vulnerability Assessment Language) definitions. While CVRF documents and OVAL definitions are provided in their native XML format, the API also provides that information in JSON format for easier parsing. This means that you can use any CVRF or OVAL parser with the feed, and you can also write your own JSON parser to get the representative data for them as well.

Most users will be interested in the CVE data, which we have been providing as part of ourCVE database since August 2009. If you wanted to get information on CVE-2016-0800, for instance, you would visit the CVE page:
. If you were using this information for some vulnerability assessment or reporting, you would have had to do some web scraping and involve other documents on our Security Data page.

With the Security Data API you can view the information for this CVE in two ways:XML andJSON. This uses our own markup to describe the flaw, and from this view you can see the CVSSv2 score and metrics (or CVSSv3 score and metrics), as well as impact rating, links to Bugzilla, the date it went public, and other details of the flaw.

While this is interesting, and we think it will be incredibly useful, the really compelling part of the API is the search queries you can perform. For instance, if you wanted to find all Critical impact flaws with a CVSSv2 score of 8 or greater, you would visit
and get a nice JSON output of CVEs that meet this criteria.

If you wanted to find all CVEs that were public a week ago (assuming today is June 1st 2016), you would use
and if you further wanted to get only those that affected the firefox package, you would use

Perhaps you only want information on the CVEs that were addressed in RHSA-2016:1217. You could use
to get the list of CVEs and some of their details and then iterate through the CVEs to get further details of each.

The same search parameters are available for CVRF documents and OVAL definitions. You have the flexibility to obtain the details via XML or JSON. The ability to get the data in multiple formats allows you to write parsers for any of these formats and also allows you to write the parsers in any language you choose. These parsers can further take arguments such as severity, date ranges, CVSS scores, CWE identifiers, package names and more, which are in turn used as search criteria when using the API.

Red Hat Product Security strives to be as transparent as possible when it comes to how we handle security flaws, and the Security Data page has been the primary source of this information, as far as machine-consumable content is concerned. With the availability of the Security Data API, we think this is the best and most user-friendly way to consume this content and are pleased to provide it. Being able to programmatically obtain this information on-the-fly will now allow Red Hat customers and users to generate all kinds of interesting reports, or enhance existing reports, all in real-time.

We are also pleased to say that the beta API does not require any kind of authentication or login to access and it is available for anyone to use.

There is one last thing to note, however. The API, at this time, is in beta and the structure of the content, including how it is searched, may change at any time without any prior notification. We will be only supporting this one version of the API for now, however if we make any changes we will note that in the documentation.

For further information and instructions on how to use the API, please visit the Security Data API documentation
. If you encounter an error in any of the data, pleasecontact us and let us know.


Training Courses for Aspiring Cybercriminals Put S... BLACK HAT USA 2017 -- Reasonably priced, module-based training courses and helpful forums will train a beginner in all the tools and techniques of the...
4 steps for hardening your Cloud Storage buckets: ... This post is the second in a new “taking charge of your security” series, providing advice and best practices for ensuring security in the cloud. Che...
Most Android Security Scares Are Bullshit Android offers a more open and customizable experience than Apple’s comparatively locked down iOS platform. However, that also means Android user...
Gartner Security & Risk Management Summit 2017 Dates:August 21-22, 2017 | Register here starting from AUD 2,525,- Location:Sydney, Austra...
Execs Underestimate Risks to Oracle EBS It's another sign that ERP keeps getting short shrift on the security front. A new survey out today shows that C-level executives are underestimatin...