Vulnerability Lifecycle is the record-keeping core of SITEY. It gives every finding a single identity that survives repeated scans, moves it through a defined set of states, and keeps a permanent history of who changed what and why, from the first time a scanner reported it to the retest that proves it is actually gone.
The problem
Most teams do not have a vulnerability problem. They have a bookkeeping problem.
The same missing patch is reported by three scanners under three different names, so one host with one flaw becomes fourteen rows in a spreadsheet. Someone marks a finding “fixed” in a ticket, but nobody rescans the host, so nobody knows whether it is fixed. Six weeks later an auditor asks when a critical finding was first seen and who approved closing it, and the honest answer is that the information is spread across a scanner console, a ticketing system, and a Slack thread that has since scrolled away.
The second cost is quieter. When an analyst decides a finding is a false positive, that judgement usually disappears into a spreadsheet cell. The same false positive comes back on the next scan, and a different analyst spends the same twenty minutes deciding the same thing again. Nothing in the process gets smarter.
How it works
- One identity per finding, not one row per scan
When findings arrive, from a scanner import, an agent, or a manual entry, SITEY resolves each one against a deduplication key built from name, risk, target IP, port, and scanner. If the finding already exists, the original record is updated instead of duplicated: its detection counter increments, the timestamp is appended to a detection history list, and its last-seen date moves forward. A database-level unique index enforces this on active records, including case normalization, so case variants of the same finding name do not become two separate vulnerabilities. Re-detections are linked back to the original record, so the detail page can show you which import campaign and which file each sighting came from.
- State changes are validated and logged
A finding’s status is restricted to a defined set: open, in progress, awaiting retest, resolved, closed, false positive, and risk accepted. The API rejects anything outside that list, so the pipeline cannot be polluted with ad-hoc states. Every status change made through the status endpoint or the interface writes a revision record capturing the old status, the new status, the user who made the change, and the timestamp. Automated transitions, such as the move to awaiting retest after a patch job or the verdict a retest produces, are recorded on the finding’s comment timeline and in its retest history instead. Marking a finding as a false positive also archives it automatically; moving it back out of false positive brings it back into the active list.
- Every human correction becomes a record
When a person overrides a status, most often marking something a false positive that AI triage flagged as real, or the reverse, SITEY writes a correction record that stores the AI verdict alongside the human verdict, the previous status, and a signature of the finding (CVE, name, risk, port, service, scanner). The matching AI triage record is updated with the human’s final decision. Instead of evaporating, disagreements between the system and your analysts accumulate as structured data.
- Patch success hands the finding to retest
When a patch job completes successfully, the linked finding is automatically moved to “awaiting retest” and a system comment is added to its timeline noting the job that ran. Failed jobs add a failure comment with the error detail. The finding does not jump to “resolved” because a patch reported success, the lifecycle treats a successful patch as a claim that still needs verification.
- Closure is verified, not asserted
Retest re-runs the original scanner against the same target host. If the finding is still detected, the status returns to open. If it is not found, the status becomes resolved. Retests are executed against these scanner APIs.
NessusAcunetixOpenVASBurpLimitationFindings from other sources fall back to an agent-based path that checks for completed remediation evidence on that host, and flags the finding for manual confirmation when no agent covers the target IP.
Each retest is stored with its own logs, start and end times, and the matching result, so the closure evidence stays attached to the finding.
What you can do
See how many times a finding has been detected, when it was first seen, and when it was last seen, instead of guessing from a scan date.
Open a single detail view that assembles the finding, its comments, its full revision history, its retest history, its AI triage records, its patch and remediation jobs, and its autonomous decision trail in one response.
Filter and page through large finding sets server-side by status, risk, asset category (domain, Windows, Linux, other), assignee, free-text search, and date range, with risk and category distributions calculated across the entire filtered set, not just the visible page.
Mark findings as false positive individually or in bulk, with each action writing its own revision and correction record.
Accept risk explicitly as a status, so a deliberate decision not to fix something is visible rather than an open ticket nobody touches.
Archive completed findings and restore them later; restore is blocked when an identical active finding already exists, so unarchiving cannot recreate duplicates.
Discuss findings in place with threaded comments, file attachments, @mentions that raise notifications, and reactions, with system and AI-generated comments carrying a comment type that separates them from human ones.
Trigger a retest from the finding itself and watch the status, logs, and match result.
Read dedicated views for in-progress, resolved, and false-positive findings, each with its own severity breakdown and assignee filters.
Track aggregate health on the vulnerability dashboard: risk and status distribution, monthly new-versus-resolved trend, and critical findings opened and resolved in the last 30 days.
Who it is for
SOC and security analysts work the queue here: triaging, correcting AI verdicts, commenting, and deciding what is real. System and network administrators use it to see which findings on their hosts are genuinely waiting on them versus already patched and awaiting verification. Security managers and CISOs read the aggregate view. What is open, what is aging, and how the resolved count is moving. Compliance officers and auditors use the revision and retest history as the evidence trail: who changed a status, when, and what proof exists that a finding was closed.
Why it matters
Deduplication changes the size of the problem. A scan that reports the same finding across repeated runs produces one tracked record with a detection count, not a growing pile of rows. Which means your open-vulnerability number reflects distinct security problems rather than scanner volume.
Verified closure changes the meaning of “resolved.” A status that only moves to resolved after a scanner confirms the finding is gone is a number you can put in front of an auditor or a board. A status that moves because someone clicked “done” is not.
And the audit trail removes an entire category of work. When someone asks why a critical finding was closed in March, the answer is on the finding: the revision that changed the status, the user who made the change, the patch job that ran, and the retest that confirmed it.
Works with
Produces the priority scores, false-positive probabilities, and recommendations attached to each finding, and consumes the human corrections this module records.
Runs the fixes and hands findings back with an awaiting-retest status.
Performs the verification scans that decide whether a finding reopens or resolves.
Holds the assignment and workflow state linked to each finding.
Frequently asked questions
What happens when the same vulnerability appears in two different scanners?
The deduplication key includes the scanner name, so a Nessus finding and a Burp finding on the same host are tracked as separate records. Deduplication collapses repeated detections of the same finding by the same scanner. Separately, AI triage can group findings that look like the same issue across scanners, using CVE, name, port, and risk similarity, and stores that grouping on the triage record. The lifecycle identity key itself stays scanner-specific.
Can I reopen a finding that was closed by mistake?
Yes. Status changes are reversible through the API and the interface, and each reversal writes its own revision record. So the correction is visible in the history rather than overwriting it. A finding archived as a false positive returns to the active list when its status is moved back to open, in progress, or awaiting retest.
Does closing a finding require a retest?
The automated path routes patched findings into awaiting-retest and only marks them resolved when a retest confirms the finding is gone. Analysts with the right role can also set a status directly, for example to accept a risk. Both paths are recorded, so you can always tell whether a closure was verified by a scan or decided by a person.
Who can change a finding’s status?
Access is role-scoped. External pentesters are restricted to the manual findings they created themselves, on single and bulk operations alike, and users without vulnerability-view permission see nothing. Update permissions on a finding’s content are limited to its creator, managers, and administrators.
SITEY is installed on your own servers, so findings, comments, correction records, and audit history are stored in your own database. AI triage and assistant features call the model endpoint you configure, so that traffic goes wherever you point it.
See pricing for the full platform, or read how the lifecycle connects to AI Triage and Patch Management.