Posted on 2023-02-23 by Matt Strahan in Volkis News
When we started Volkis, Alexei and I had a big ranty discussion on how reports should be done. The next day I hacked together a PoC. We looked at it and went “damn, we already like this better than what’s already out there!”
Fast forward three years and Volkis is now more than just Alexei and I. That PoC ended up as Report Ranger and we’re still using it internally. Each time I ask “is Report Ranger still working for us” the answer seems to be “yes”. I follow that up with “are you sure?”, worried that they might just be trying to be nice and not hurt the feelings of the Managing Director and they still say “actually yes, I really like it!”
Part of the advantage of using our own internal tool for reporting has been the flexibility. Much of the functionality that Report Ranger has now was put in for a specific use case. We need a report that has charts, so let’s just put charts into Report Ranger. Wouldn’t it be good to have it read a spreadsheet and automatically generate our compliance report? Report Ranger can now do just that. Recently we had a report that needed two sections with separate groups of vulnerabilities and so now that change has been put together. All these breaking changes were fine - we just posted a message on our company Slack channel to give everyone a heads up and that was that.
There’s a big issue that has now cropped up though. Report Ranger is an open source project is now being used outside of Volkis. Ah well, there goes our fun. We have to start doing stuff properly!
Doing stuff properly
In doing stuff properly we will now be putting together a formal roadmap and doing proper versioning for Report Ranger. We will have proper releases through pip, Poetry, and Docker.
As Report Ranger is public and open source, our communication and processes need to be more public and transparent as well. That should be easy enough for us - one of our company’s values is transparency! That said, no more simple Slack messages talking about breaking changes. Instead we have to provide notice and have more deliberation.
We have had a bit more deliberation of what we want Report Ranger to be. When discussing this we went over the current guiding principles and we believe these still apply now. They are:
- Beautiful, professional reports
- Works offline
- Strongly templated
- Unrestricted output
- Dynamic and reusable content
- Flat files only
- Active assistance through automation
Overall we would like to keep Report Ranger simple. We don’t want it to turn into another Microsoft Word. We also don’t want it to turn into Ghostwriter, with any centralised web interfaces or additional project management. It should be self contained and simple. (Nothing wrong with using either of those, if they work for you!)
No longer just pentest reports
As we have moved on as an organisation, so has Report Ranger moved on as a tool for us. We no longer just use Report Ranger for penetration tests, we use them also for compliance reports, security reviews, recommendations reports, retesting reports. Even letters on our company letterhead get published through Report Ranger!
In the original PoC pentest reports was all it was used and useful for. Slowly these functions became abstracted away into options rather than mandatory components. This has enabled Report Ranger to be a more useful tool.
Our roadmap continues down this path. We’ve brought vulnerabilities themselves right out into an optional import, allowing Report Ranger to be a reporting engine first and a penetration testing reporting engine second. This opens Report Ranger up to a bunch of new potential use cases. You could even write a book in Report Ranger if you wanted!
Let’s get to specifics
We will be making the following changes to Report Ranger:
Formal release process: Breaking changes will be tagged with a major version release. Each release will be accompanied by a changelog. The latest release will be pushed to PIP.
Unit tests and better internal testing: As part of the release process we need a way to catch regressions and potential issues. This would include unit tests and test documents.
Moving vulnerabilities and appendices to the report itself: Originally the template had vulnerabilities and appendicies in-built and vulnerabilities will automatically be processed and included. This is all being brought into the report file itself by default. Although it will still be possible to have a template with content in it, this will no longer be default or by design.
Soft coded importing of vulnerabilities: The vulnerabilities will be moved into an import in the following format:
import:
vulnerabilities:
jumpbox_vulnerabilities:
directory: jumpbox_vulnerabilities
This means that vulnerabilities will no longer be hardcoded in a report in any way.
Improved documentation: A full function reference will be documented in the Wiki. This will include all functions as well as a descriptions of the functions themselves and their parameters.
Additional changes:
- Include better cross referencing
- Simplify the default latex template
- Have a more formal way of using macros and default content included in the template
- Soft code a template mapper so that you can just include a single file which references all potential templates
About the author
Matthew Strahan is Co-Founder and Managing Director at Volkis. He has over a decade of dedicated cyber security experience, including penetration testing, governance, compliance, incident response, technical security and risk management. You can catch him on Twitter and LinkedIn.
If you need help with your security,
get in touch with Volkis.
Follow us on Twitter and
LinkedIn