Red Hat Product Security has long provided various bits of machine-consumable information to customers and users via our Security 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 our CVE database since August 2009. If you wanted to get information on CVE-2016-0800, for instance, you would visit the CVE page: https://access.redhat.com/security/cve/CVE-2016-0800. 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 and JSON. 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 https://access.redhat.com/labs/securitydataapi/cve.json?severity=critical&cvss_score=8.0 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 https://access.redhat.com/labs/securitydataapi/cve.json?after=2016-05-24 and if you further wanted to get only those that affected the firefox package, you would use https://access.redhat.com/labs/securitydataapi/cve.json?after=2016-05-24&package=firefox.

Perhaps you only want information on the CVEs that were addressed in RHSA-2016:1217. You could use https://access.redhat.com/labs/securitydataapi/cve.json?advisory=RHSA-2016:1217 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, please contact us and let us know.