VULNRΞPO: Client-Side Encrypted Vulnerability Reports, With No Server Key Recovery

The report-writing gap VULNRΞPO targets

Pentest reporting has a recurring shape. A Burp XML file, a Nessus export, an Nmap scan and a Trivy JSON all describe findings in different schemas. Someone then retypes them into a Word template, adds severity, CVSS, CVE references and screenshots, and produces a document that a client will read once. VULNRΞPO takes that retyping step and replaces it with an import dialog plus a template library. The README describes it as a "client-side, privacy-first vulnerability report manager for security professionals", and the feature list is organised around that workflow: issue templates pulled from CVE, CWE, MITRE ATT&CK and PCI DSS, a changelog that versions significant report changes automatically, issue merge for duplicates, and an advanced filter across severity, status, tags, CVE and CVSS. The audience is narrow and identifiable. It is the consultant or bug bounty hunter who owns the report end to end, not a security operations team that needs a shared, queryable findings database with role-based access. The repository topics list bugbounty, pentest-report, burpsuite, nessus, openvas, zaproxy and trivy, which is a fair summary of who this is built for.

Browser-native cryptography and the KeyVaultService auto-lock

The security model is the part worth reading closely, because it determines what the tool can and cannot do. Encryption happens in the browser. The README's table specifies PBKDF2-SHA-256 with 600,000 iterations for key derivation, AES-256-GCM for encryption, a 16-byte random salt and a 12-byte random IV per encryption. Ciphertext goes into IndexedDB on the local machine. The decryption password lives in an in-memory vault, named in the README as KeyVaultService, and the README states it is never written to sessionStorage, localStorage, cookies or any other persistent medium. That vault is cleared on three triggers: the tab becoming hidden through the visibilitychange event, the tab closing or the page reloading through pagehide and beforeunload, and 15 minutes of keyboard, mouse or touch inactivity. The practical consequence is that switching to another window to copy a CVE identifier can lock the report, and re-opening it prompts for the password again. That is a deliberate trade of convenience for a smaller key-exposure window. The README also notes that reports encrypted with older app versions in the legacy CryptoJS AES format are detected and decrypted for backward compatibility, which matters if you have archives from earlier releases. There is one sentence that should govern any deployment decision: "There is no server-side key recovery." That is not a bug report, it is the design.

Sixteen import formats and where the parsing risk sits

The import table is the most concrete evidence of scope in the README. It covers VULNRΞPO's own .VULNR encrypted format and decrypted .JSON issues, Burp Suite .XML, Bugcrowd .CSV, Nmap .XML, OpenVAS 9 .XML, Tenable Nessus .NESSUS and .CSV, Trivy .JSON, Atlassian Jira .XML, NPM Audit .JSON, Semgrep .JSON, PHP Composer Audit .JSON, WIZ Issues .CSV, OWASP ZAP .JSON, BlackDuck Code Sight .JSON, and SARIF 2.1.0 in .SARIF or .JSON form. The SARIF row is the widest, because the README names CodeQL, Semgrep, Trivy, ESLint, Bandit and Checkov as producers of that format. Two things follow. First, the import layer is doing real normalisation work, mapping each tool's severity vocabulary and field names onto a common issue model, and the README does not document that mapping anywhere. Second, version drift is the obvious failure mode. Burp, Nessus and ZAP all change their XML and JSON output between releases, and the README lists no supported version ranges for any importer except OpenVAS 9, which is pinned by name. If your scanner writes a slightly different tree, you will discover it when the dialog returns nothing useful. Treat the import list as a set of starting points to verify against your own exports, not as a guarantee.

Export formats, the print-to-PDF route, and the LaTeX detour

Export is where the tool meets client expectations, and here the README is honest about a gap. HTML export is fully self-contained with an editable template and CSS, and there is a second HTML mode encrypted with AES that can be sent by email or file transfer. DOCX and TXT are direct exports. PDF is not: the README instructs you to use browser Print to PDF with Ctrl+P on the HTML export, or to use a separate project, vulnrepo-json-to-latex-pdf, for full customisation. That means your PDF pipeline depends on browser print rendering, which handles page breaks, headers and footers differently across engines, and the README's browser support section is the place to check before promising a client a specific layout. The LaTeX generator is a separate repository, so it carries its own maintenance and version-compatibility questions that this README does not answer. Issue-level export is more interesting than report-level export: issues can go out as SARIF 2.1.0, into Atlassian Jira, or as a portable encrypted file. Sending findings into Jira as tickets is a different workflow from sending a report, and having both in one tool is a genuine convenience. File attachments are supported and the README states a SHA-256 checksum is computed automatically, which gives you a way to show that a screenshot has not changed since it was attached.

Running it: dev server, production build, Docker and the Ollama origin flag

The README's Getting Started section lists prerequisites, a development server, a production build and Docker, and the Docker image is published as kac89/vulnrepo on Docker Hub. The project is Angular 22 according to its badge, so the development server and build commands are the standard Angular CLI ones, and the README does not deviate from that. The AI integration is the one place with a non-obvious configuration step. VULNRΞPO connects to a locally hosted Ollama instance, and the README's setup is four steps: install Ollama, run a model with "ollama run llama3.2:latest", start Ollama with the environment variable OLLAMA_ORIGINS=https://vulnrepo.com if you are using the hosted app, then open AI Settings from the robot icon in the report toolbar, enter the Ollama URL (http://localhost:11434 by default), pick a model and save. The origin variable is the step people will miss. Without it, the browser blocks the request from the hosted app to your local Ollama and the integration appears broken when it is only misconfigured. Note also that the README describes AI-assisted report writing, not AI-assisted finding discovery, and that the model runs locally so no report text goes to a cloud service. The optional backend is the other configuration surface: the README says encrypted reports can be stored on your own server through a REST API, and that this is the only path by which data leaves the browser.

The key-loss boundary and the wrong-tool cases

The central limitation is stated in one line of the README and it is not negotiable: lose the security key and the report data cannot be recovered. For a solo consultant that is an acceptable risk with a password manager and an offline backup of the key. For a team, it creates a real operational question that the README does not answer, because there is no documented shared-vault or escrow mechanism. Report sharing exists, and full encrypted reports can be shared with collaborators, but the README does not describe how the recipient obtains the key, so that is something to establish before you rely on it. There are other cases where VULNRΞPO is the wrong tool. If you need a findings database that multiple people query and update concurrently with audit logging, browser IndexedDB per workstation is the wrong storage layer. If your deliverable is a tightly branded PDF with fixed pagination, a print-to-PDF step introduces variability you may not want. If you need the AI features but cannot install Ollama on the reporting machine, the local model path is unavailable and the README offers no cloud alternative. And if your workflow depends on a scanner whose export format has changed since the importer was written, you will be doing manual entry anyway.

How it differs from Dradis and Faraday

The obvious comparison is with server-based collaboration platforms such as Dradis or Faraday. Those tools centralise findings in a database that a team connects to, which gives you shared state, concurrent editing and a single source of truth across an engagement. VULNRΞPO inverts that. Its default mode has no backend at all, data sits in the browser's IndexedDB encrypted with a key derived from a passphrase only the user holds, and the optional REST backend stores already-encrypted reports rather than readable ones. The difference is not a feature checklist, it is where trust is placed. A centralised platform trusts the server and its operators, and in exchange gives you recovery, access control and reporting across many assessments. VULNRΞPO trusts the workstation and the human holding the passphrase, and in exchange gives up recovery entirely. That makes it a better fit for a single researcher handling sensitive findings under a disclosure agreement than for a team that needs a shared engagement record. It also means the two approaches are not really substitutes, and picking between them is a question about who is allowed to read the raw findings.

Licence, maintenance and what to check before adopting

VULNRΞPO is licensed under Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved and any modified files carry prominent change notices. That is a permissive licence with an explicit patent grant, and it is compatible with the kind of internal consulting use this tool targets. It is not legal advice, and if you plan to redistribute a modified build, read the licence text rather than this summary. On maintenance, the repository's last push is dated 2026-09-07 and it is not archived, but no recent releases were retrieved, so there is no version history to reason about here. The README documents a legacy CryptoJS decryption path for older reports, which implies the storage format has changed at least once, and that is the thing to watch on upgrade: confirm that reports written by your current build still open after you move to a newer one, before you migrate an active engagement onto it. The repository also points to a separate vulnrepo-json-to-latex-pdf project for custom PDF output, so a full reporting pipeline means tracking two codebases with independent release cadences. Start with one real engagement, import your actual Burp or Nessus export, and check the HTML export in the browser you will use for print.

Editorial conclusion

Adopt VULNRΞPO if you write pentest or bug bounty reports and want the report data to stay on the workstation, particularly if you already produce Burp, Nessus, Nmap, Trivy or SARIF output. Do not adopt it if you need server-side key recovery, a supported LaTeX or DOCX pipeline without a browser, or an audit trail that survives a lost passphrase. Before committing, verify three things yourself: that your scanner's export variant parses in the import dialog, that Ctrl+P on the HTML export produces a PDF your client accepts, and that your team can store the security key somewhere it will not be lost, because the README states plainly that no recovery exists.

Official sources

1. Issues
2. kac89/vulnrepo on GitHub
3. License: Apache-2.0
4. Project website
5. README