TL;DR
TL;DR: I cannot show real runs from my ISMS, because they contain internal names. Invented sample files show no history. So my real chain ran for seven nights for a made-up Example GmbH, with findings that appear, stay for a while and go away again. The screenshots show the tool exactly as it works.
How the screenshots came about
What the viewer shows
I keep my ISMS in OSCAL. That is an open NIST format for security evidence, machine-readable and stored as JSON. The scripts from grundschutz-worksheets use it to produce four documents: the profile with the requirements that apply, the security plan, the assessment results and the plan of action. I call this sequence the chain.
Every measurement produces a run, a set of these documents at one point in time. grundschutz-viewer reads several runs and turns them into one HTML page. For every requirement it shows the current state and its history: which run measured what, and when a measurement changed.
Why not the real data
The chain runs in my ISMS with every measurement. Its documents, though, contain names of projects, hosts and services. They do not belong in a public README.
Redacting does not help much. A redacted screenshot shows mostly black bars, and every name I overlooked would be published.
Why not simply invented files
A few invented JSON files would have filled the interface. But they would have shown a single state only. The history is exactly what the viewer is meant to show, and for that it needs several runs. With just one run, that view stays empty.
Seven nights for Example GmbH
Example GmbH exists only as a scenario. It describes seven nights, from 7 to 13 October 2026. Normally the five checks from grundschutz-checks supply the measurements. Here a stand-in takes their place. For every night it writes a result that looks just like one from the real checks.
The checks look at made-up projects such as example/api, example/infra, example/shop and example/website, plus the TLS endpoints www.example.org and shop.example.org. Findings appear one night, stay for a few nights and then get fixed.
Two more files belong in every ISMS. In the assessment by hand, the owners rate some requirements as implemented or partly implemented. The plan of action has deadlines, and one of them is overdue.
The same chain, just another day
Everything else is no mock-up. The same scripts that run in my ISMS build the four documents from the scenario, night by night. Two switches are all it takes. --store dir: puts the results into a local folder instead of the locked storage of my operations. --day sets the date a run counts for. It is all wired together in a template repository that is not public yet.
At the end there are seven folders, one per night. The viewer reads them as seven runs and builds one page with a history from them.
Screenshots from the browser
A Chrome without a window, the so-called headless mode, takes the pictures. An anchor in the address selects which requirement is shown:
chrome --headless=new --window-size=1440,900 --screenshot "explorer.html#KONF.14.1.1"
That gives two views. The overview shows the state of the newest run and every run before it underneath. The record, the detail view of one requirement, shows the night its measurement changed.
The lesson
A demo has to run through the same code as operations. Only the inputs may be made up. Otherwise the screenshot shows a tool that does not exist like that, and the first real installation starts with a disappointment.
Frequently asked questions
Why not redact your own data?+
A redacted screenshot shows mostly black bars. And every name I overlooked would be published, in a README that gets mirrored and cached.
Do you use the viewer yourself?+
Not yet. grundschutz-viewer is built and released as v0.2.0. It does not run in my ISMS so far. The chain from grundschutz-worksheets, whose documents it reads, is in use there.
Where can I find the screenshots?+
In the README on GitHub and on the grundschutz-viewer page. Both show the same Example GmbH: the overview with its history, the record of one requirement and the register.
Conclusion
The screenshots show a company that does not exist, but a tool that exists exactly like that. That mattered more to me than a pretty interface. What you see in the README comes about the same way as in my ISMS, only with made-up inputs.
The pictures are in the README on GitHub and on the grundschutz-viewer page.
I show your ISMS tooling without showing your ISMS.
Together we build a scenario that runs through the same code as your operations, only with made-up inputs. That gives you screenshots and demos that give nothing away and still show what the tool looks like day to day.
Rather than advice on paper, I set the scenario up in your pipeline so that it runs along with every new version.
About the author
Kai Ole Hartwig
Programming since 2002 – self-taught, set up my own business with KO-Web in 2012. Over 100 projects, with a focus on security, performance, automation and quality. Today freelance: DevSecOps consulting, training and software development.