We have received many requests to change our HTML report in some way. In this post I will try to summarize what it is people want to change and try to come up with a proposal for our new HTML report.
I started with the HTML report but the plan is to update both report and guide generators. They share a lot of code even today, it makes sense to update them both.
Problems with the current approach
openscap uses docbook as an intermediary format. This means that when generating guides or reports, the XCCDF is transformed into docbook using XSLT, that docbook is then transformed into XHTML. This causes several problems.
XCCDF allows XHTML in description, front-matter, rear-matter and others. We have to convert XHTML to pseudo-docbook and then back to XHTML. Data is inevitably lost during this transformation because docbook cannot possibly support all of XHTML.
Furthermore, the maintenance costs of such an arrangement are enormous. The XSLTs are big and hard to navigate through.
I believe benefits gained from using docbook are very small if there are any at all. There are serious issues when trying to generate PDF from our docbook guide/report which leads me to believe that nobody is using alternative output formats.
Our users have requested several features and changes. I tried to gather some of them and list them here. If you have other suggestions please leave a comment!
- Rule filtering – for example to hide all passed rules
- Rule sorting – for example by severity, to form a remediation priority queue
- Rule full-text search – type CVEs, CCEs, titles, parts of descriptions, filter rules by them
- Custom branding – allow downstreams to insert their own logo
- Generate guide just for the chosen profile – as opposed to generating guide for the default profile
- Online XSLT used on demand for XCCDFs – could be hosted on open-scap.org and can be used to create reports on demand, OVAL details will be omitted if this arrangement is used
- Provide all info we currently provide in our HTML report – especially OVAL details in failed rules
- “media: print” support
- Proper XHTML passthrough for description, front-matter, rear-matter and other XCCDF elements that allow XHTML
In my opinion we should base the new HTML guide and report on HTML5 and either Pattern Fly or Bootstrap, the project it’s based on. This should give us a starting point for visuals and usability. The new XSLT will no longer generate any docbook. Users that want PDF reports can generate them from the resulting HTML5.
What follows is a preliminary prototype. Not all planned functionality has been implemented.
I have used jQuery dataTables for search and sorting functionality. It supports pagination but I am unsure whether we want to use that or not.
Screenshots for the impatient:
Full archive of all the code for the rest:
I would like to get some feedback from the community before I continue with this research. If the feedback is positive I plan to start an experimental branch in the openscap upstream repository with the actual XSLTs.
I can make no promises but the ambitious plan is to have a new HTML report and guide in openscap 1.1.0.
See part 2.