OpenSCAP - feedback from the real world

Latest response

I wanted to get a feeler of whether folks are using OpenSCAP. I also was curious if people were using it with their Satellite/Spacewalk infrastructure, or stand-alone.

Was it worth implementing (i.e. would you do it again)?
Did you use it with Satellite, and would you implement it stand-alone if given the option to do it over)?
How much customization of the pre-canned audit files did you need?
What particular skills did you find helpful (i.e. did you find yourself using Python quite often)?
Were there any blatant issues you had to work through that you would advise researching in advance?


Did you end up altering your build standard to pass the standard audit? (i.e. separate /var/log and /var/log/audit)
What kind of issues did you run in to that were not anticipated?

Any idea whether OpenSCAP will continue to be integrated with Satellite 6.x? Will it be more tightly-coupled?



I am also very interested in this topic. We are involved with early stage testing. So far pre-canned vanilla.

Any further information would be greatly appreciated.

Just updated my Satellite to 5.6 and a couple of dev boxes to RHEL 6.5. Installed all of the scap packages. If I run the oscap on the local machine it works fine, if I run it from the satellite I am seeing unicode errors in /var/log/up2date. Will be contacting support.

Found out that I needed -- for my options, not just a single dash. Working now. We are looking to see if we can find a CIS audit xccdf file for testing this as well.

Thanks for the update. The more I learn about this stack, the more excited I am about it.

We are planning to implement it in our Satellite to replace Qualys VM (vulnerability management) scans.

It is required to comply with PCI DSS requirements and SCAP would save us money.

also it would be easier to have access to XML profiles.

Any additional benefits in Satellite 5.6 over 5.5 in regards to OpenSCAP implementation?

Hello David,

Here's a few highlights from Satellite 5.6 Release Notes [1]:

" Improved SCAP auditing features and support for XCCDF 1.2 to provide capturing of detailed HTML reports.


Satellite 5.6 has the ability to aggregate full SCAP results, collecting OVAL and XCCDF results into a fully downloadable HTML report for each scan. The extended information available in the report can help administrators investigate the possible causes of audit failure.

The organization administrator can configure this feature, setting up file size limits for individual SCAP files. This feature is turned off by default for each organization. It requires the latest spacewalk-oscap packages on the client systems in order to work properly.

New API Methods:



Hopefully this makes sense to others currently using OSCAP. For your own implmementation, did you create your own XCCDF, OVAL and CDE files? Or did you utilize the pre-canned ones (such as provided by scap-security-guide [from EPEL]) and then write your own profiles?

I am finding there are TONS of excellent analysis being done. However, they do not all apply to our environment.
Does the following approach make sense?
Create my own XCCDF file with Profiles that are relevant to our environment which would then utilize the eap5 or rhel6 CDE and OVAL files.

oscap eval --profile xyzco-rhel6-server --cpe /usr/share/xml/scap/ssg/content/ssg-rhel6-cpe-dictionary.xml /usr/share/xml/scap/ssg/content/xyzco-rhel6-xccdf.xml

I also found this:

It appears Red Hat is one of the Linux distributors to actually contribute and publish an OVAL standard. Now, I just need to learn how to best utilize it ;-)

I've been looking for a discussion like this - thanks for all the input, looking forward to researching this.

If you want to look upstream and contribute to the security policy and scan content community, is a great place to start.

James, Remmele, had I known about this thread I would have pinged you about it @ Summit!

Andrew's suggestion for SSG is the way to go. You can build XCCDF from scratch with something like scap-workbench (, but the SSG community is the upstream for orgs like DISA and has a solid set of starting points. I believe that the content will be available directly starting in RHEL 6.6 without need for EPEL.

The basic skillset needed is XML. Reading, tracing, connecting XML. And if you're looking at SSG, then a bit of make so you can see how they are doing some of the XML transformations to build the final XML from the snippets.

I've worked on a CIS policy, it wasn't very hard to get started but the upstream community has since formed around building something that worked as well. I started with the STIG profile (a DoD profile) and got the basic mapping of what existed and what didn't against the CIS benchmark in an afternoon. Working on the missing controls wasn't very hard either.

SCAP is on the roadmap (and loudly shouted for) in Sat 6, but won't be there on GA from what I've been led to understand. (not an employee no special inside track ;) ).