Vulnerabilities
The lifecycle of a finding — states, severity and SLAs, evidence, assignment, comments and audit history — plus quality gates for CI.
What a vulnerability is
A vulnerability is a finding the AI agents surface during a pentest. Each one has a full lifecycle, closer to a Jira ticket than a static scan result: it can be worked on, resolved, disputed, assigned, commented on and reopened, with every change recorded.
States and lifecycle
A vulnerability is always in exactly one of five states:
| State | Meaning |
|---|---|
open | Newly detected, not yet triaged |
in_progress | Someone is actively working on it |
resolved | Fixed and closed |
false_positive | Determined not to be a real issue (requires a reason) |
accepted_risk | Acknowledged but intentionally not fixed |
The allowed transitions are:
| From | To |
|---|---|
open | in_progress, resolved, false_positive, accepted_risk |
in_progress | open, resolved, false_positive, accepted_risk |
resolved | open (reopen) |
false_positive | open (reopen) |
accepted_risk | open (reopen) |
Resolving a finding can be done with evidence (evidenced, which requires at least one uploaded file) or without evidence (without_evidence). Marking something a false positive requires a written reason.
Severity and priority
Every vulnerability carries a severity — critical, high, medium, low or info — set from the impact of the finding. Independently, it has a priority (urgent, high, normal, low) that you control to manage your own work queue.
SLAs and due dates
A due date is computed automatically from the severity when the vulnerability is detected (and recomputed if it’s reopened):
| Severity | Default SLA |
|---|---|
| Critical | 24 hours |
| High | 7 days |
| Medium | 30 days |
| Low | 90 days |
| Info | No SLA |
Findings past their due date count as overdue, which surfaces in the pentest’s vulnerability summary and can be enforced in quality gates.
Evidence
Files that prove a finding has been mitigated can be attached as evidence. Supported formats include images, PDF, TXT and CSV; each file is validated by extension, declared MIME type and actual content. Evidence is what backs an evidenced resolution.
Assignment
When a pentest belongs to a team, vulnerabilities can be assigned to a team member (the assignee must belong to that team). Assigning a finding that is open automatically moves it to in_progress. The assignee is notified by email on assignment, resolution and other key events.
Comments and history
- Comments — any member with access can add comments, which appear in a combined activity feed alongside automatic system entries (status changes, assignments, evidence uploads).
- History — every status change is recorded in an immutable audit trail, capturing who changed what, when, and why.
Quality gates
For CI/CD, a quality gate evaluates rules against a pentest’s current findings and returns pass/fail — for example “no open criticals”, a minimum resolution rate, or “no overdue findings”. A failing gate can block a deploy. This pairs with bulk status updates and CSV/JSON export for pipeline automation.
{
"rules": [
{"severity": "critical", "max_open": 0},
{"min_resolution_rate": 0.8},
{"max_overdue": 0}
]
}