Secure Nova.
Vulnerability translation for people who are not security specialists.
Approved in a competitive public call by the Santa Catarina State Research Foundation (FAPESC), Brazil, and built against a work plan with numeric acceptance criteria.
The problem
A security scanner produces a report only a specialist can read. SonarQube, OWASP ZAP, Dependency Track, Nessus and OpenVAS all output technical findings, and then somebody who is not a security engineer has to decide what gets fixed first.
Public money came with rules. Four defined stages, acceptance criteria expressed as numbers, and accountability to the agency that funded it. That was the hardest constraint in the project, not background context.
What was mine: the four project stages and their acceptance criteria, the success metrics, supplier selection and contracting against compared quotes, and the product decisions below. Product management was shared with Millena. I also worked hands-on across design, frontend and marketing, alongside the supplier's implementation work.
The product call
The person deciding what gets fixed is rarely a security engineer. So every finding opens with what it means in short, then an everyday analogy, then how to fix it. The technical detail is one click away, and not the first thing on the screen.
The model call
The system enriches every vulnerability with a language model. Nine models were evaluated across three providers, on cost per four-thousand-token request, response time and answer quality.
We chose Claude Haiku 4.5, at roughly US$ 0.02 per request, and not the more capable models. Opus 4.1 cost US$ 0.12 and GPT-4o US$ 0.10, six and five times more. In a product that processes reports in batches, depth that does not change the reader's decision does not pay for itself.
The criterion came from Gabriel, our CTO. I modelled the cost alongside our pricing, and argued that the model could not be a one-time decision. So the provider and the model live in environment variables, and not in the request body. We have replaced the model twice since. Every enrichment is cached against a SHA-256 hash of the payload, and not re-requested.
What we built
Vulnerabilities Crawler. Three independent sources, one API. It ingests CVEs from the NVD, CWEs from MITRE and rules from SonarSource, correlates them, and generates a standardised explanation for each finding: impact, description, a code example, a fix and references. The output is contracted before it is implemented: named fields, a published OpenAPI specification, a versioned repository. Fifty commits between February and June 2026.
What went wrong, and what it cost
During validation, an engineer found our scanners running on an external VPS, with the scanner code outside the repository and no clarity on who could reach client data. In a product whose purpose is to make vulnerability legible, that is our own problem, in our own house.
We ran Secure Nova against Secure Nova, fixed our own findings with our own product, and brought the BFF onto our own infrastructure. It cost three days. We found it in validation, and not in production with client data moving through somebody else's machine.
What stayed after
Three governance artefacts outlive the project: a contractual QA dashboard reconciling the contract, the public call and the supplier budget item by item; a meeting log recording the evidence for every decision; and a final technical report showing adherence to the work plan. Agilizer, a client, contributed feedback throughout validation.