Auditors don't ask if you fixed everything. They ask why you didn't fix the rest
Every Konvu verdict carries the evidence behind it and the moment it was made, exported into Jira and the scanner you already run. An unexplained backlog is a red flag. A backlog with a reason attached to every item is a record an auditor can work with.
Evidence deep enough to defend
Each decision is stored with the code Konvu read, the conditions it tested, and the one that settled the call, whether the finding was fixed or dismissed. Enough for an auditor to follow the reasoning rather than take it on trust.
Retrievable long after the fact
Auditors don't ask on your schedule. Pull the full record for any finding, any time, with the evidence intact rather than reconstructed from Slack threads or someone's memory.
Exported into Jira and your scanner
The verdict and its evidence land as a comment on the ticket and a justification in the scanner. No separate compliance dashboard to maintain.
Evidence for the frameworks you're held to
SOC 2, ISO 27001, PCI DSS, and the EU Cyber Resilience Act all ask for documented vulnerability handling. Konvu produces the record. Your auditor still makes the call.
Every verdict leaves the same trail behind
A suppressed finding and a fixed one look identical from a distance: both are closed. What an auditor wants is what happened in between, what the investigation found, what the finding turned out to be, and when someone, or something, made that call. Konvu writes it down for every finding that gets a verdict, ticket or no ticket.
Reachable from two request handlers, call graph confirms that much. But traced data flow shows the keys passed to _.zipObjectDeep come from a fixed list in code, never from request bodies, so the attacker-controlled input the exploit needs never reaches the vulnerable argument.
call graph: 2 routes reach the function (necessary, not sufficient)
data flow: zipObjectDeep keys never populated from request bodies (decisive)
retained: with the finding, until your policy says otherwise
Same record whether the verdict is fix or dismiss. Pull it the day it's made, or long after.
What an audit runs into today
Manual triage
- ✗A suppression checkbox in the scanner, no explanation attached
- ✗Reasoning lives in a Slack thread or an analyst who has since left
- ✗Six months later, nobody can reconstruct why a finding closed
- ✗The evidence packet gets assembled the week before the review
With Konvu
- ✓Every verdict stores what was checked and why, at the moment it ran
- ✓The record lives with the finding, not with whoever reviewed it
- ✓Any verdict pulls up complete, whether it's a day or a year old
- ✓The export is ready before the audit gets scheduled
Pull the record, not the current status
A scanner shows you the current state: open, suppressed, resolved. It doesn't show you why a finding was suppressed eight months ago, who signed off, or what they checked. Konvu keeps that record next to the finding, so pulling up a year-old verdict reads the same as pulling up this morning's.
Consistency is a control, not a nice-to-have
SOC 2 and ISO 27001 audits check whether your vulnerability handling process runs the same way every time, not whether any one call was right. Every finding gets the same investigation whether it lands on a quiet Tuesday or the Friday before a release, so what you hand an auditor reads as one process instead of a patchwork of individual judgment calls.
Frameworks ask for evidence. Konvu produces it.
None of these let Konvu decide whether you're compliant, and neither do we. What they require is documented proof that a vulnerability was evaluated and the decision was reasoned. That's the record every verdict leaves behind.
EU Cyber Resilience Act (CRA)
Article 14 requires reporting an actively exploited vulnerability within 24 hours, with a record of how you reached that call. Konvu's exploitability verdict is that assessment, timestamped and ready to attach. See the CRA readiness checklist for the requirements around it.
SOC 2
Auditors sample your vulnerability management process and ask for evidence it runs consistently. Konvu's record shows what ran, when, and what it found for any finding they pick.
ISO 27001
Technical vulnerability management needs a documented process an auditor can review, not a recollection of what happened. Konvu's export is that documentation, generated per finding rather than assembled after the fact.
PCI DSS
Requirements 6 and 11 mandate vulnerability management with documented evidence and remediation timelines. Konvu attaches that evidence directly to the finding it concerns.