SCAP Workbench redesign

What is SCAP Workbench?

A GUI tool that allows user to perform scans and limited XCCDF editing. Its role is to flatten the learning curve and make entry into the SCAP world easier for newcomers.
I do not believe that it is the only essential tool in the quiver of an SCAP auditor. The main use case is scanning single machines and refining the policy. After everything is set up I expect auditors and admins to scan periodically via the command line oscap tool or a system management tool (e.g. Spacewalk) instead. So workbench should in my opinion avoid feature creep and avoid becoming an all-in-one essential tool.
The old workbench scanning a local machine

Why the rewrite? The workbench is perfect!

No, it really isn’t. The codebase is very large, on the brink of not being maintainable and big portions of it are completely unused. The scanning code is more or less a port of oscap tool code from C to Python. And while the oscap tool from the openscap project is gradually improved, workbench scanning stays the same.
Generally I think we have come to a point when it’s worth it to take learned lessons from the past and rewrite from scratch. Also, openscap is now featuring a high level API that can do most of the heavy lifting for us. Thus the new version can have a very lean codebase.

Working prototype

So far I have created a prototype to prove that the new major features can be done. It is residing (most likely just temporarily) in a github repository at


  • cmake
  • Qt4
  • QtWebKit
  • openscap from git

Notable changes

Using the oscap tool for all scanning

Previously, we used the openscap library’s API to perform the scan. That is done using the oscap scanner in the new version. There are several reasons why this is a good idea. For one we can have just one heavily tested code that does evaluation and rely on it for both tools. Also if the oscap scanner gets certified the workbench ends up using a certified scanner which may be valuable for users. [5]

High level API from openscap

This is done for the workbench to be less likely to break with openscap API changes. The old workbench used to suffer very frequently from this.

Remote scanning

Old workbench can only scan the machine it was running on. The new workbench allows users to scan any remote machine with accessible ssh. It will ssh into a remote machine and run oscap there. oscap scanner must be installed on that machine in order to do that.

Results are fetched back to the machine with workbench for analysis.

Datastream support

SCAP Workbench used to only support XCCDF. The prototype allows you to open a source datastream and select any checklist inside. Going forward, datastreams are the preferred way of exchanging SCAP content so it is essential that workbench supports them.


Workbench did not enable users to fix a system so that a rule passes. Since support for remediation has been added to openscap recently, we can simply use the oscap tool to perform it.

So far only online remediation is implemented for both local and remote scans.

The new workflow

I am trying to emphasize straight forward usage for the most common use case. Any special use cases should be hidden behind menus.

When opened, the application immediately pops a file open window and will close itself if user cancels. A file has to be opened at all times in the new workbench. Majority of the work is done in the main window of the application.

Datastream opened in the new workbench


New workbench scanning

Results are shown in a separate modal dialog, as is the option to save them in one of the 3 formats.

SCAP Workbench and its result viewer (uses WebKit)

Future plans

Proper tailoring

Currently, SCAP Workbench doesn’t follow the specification when it comes to XCCDF profile tailoring. It changes profiles directly instead of tailoring them even though the feature is called Tailoring in the tool. The new workbench will work with tailoring files and will correctly inherit the profile to tailor it.
This has been enabled by improvements in openscap that allows profile inheritance and name shadowing.

Offline remediation

Online remediation is not applicable to all use cases. Very often users want additional control over what to remedy. In the future I plan to implement selective remediation that can be applied after scan finishes. User will be able to select or deselect failed rules that should be remedied.

I need some help

At this point I only have a very crude GUI prototype. I am looking at polishing and improving the workflow. As I am not experienced in developing GUI applications I appreciate any help regarding that. Feedback and ideas are very welcome.

References, further reading