Finding Continuity

The Problem Continuity Solves

When you run a pentest once, you get a snapshot of your security posture. When you run pentests repeatedly - monthly, quarterly, or after major releases - you generate a series of snapshots. Without continuity tracking, each report stands alone. You would have to manually compare reports side by side to determine which vulnerabilities are new, which are still present from previous scans, and which have been resolved. For organizations with hundreds of findings across dozens of scans, this manual comparison is impractical.

Finding continuity automates this comparison. It uses cryptographic fingerprints to uniquely identify each vulnerability, then matches findings across scans to assign each a continuityStatus of new, confirmed, or retest_confirmed. A prior finding that a live retest oracle cannot reproduce is marked not_confirmed (treated as resolved) and dropped from the active findings. This transforms individual pentest reports into a security posture timeline.

How Fingerprinting Works

Each finding receives a cryptographic fingerprint derived from its vulnerability characteristics. The fingerprint is computed from the vulnerability type, the affected endpoint, and the exploit signature - the stable properties that identify a specific vulnerability regardless of when it was discovered.

The fingerprint is deliberately independent of fields that change between scans, such as timestamps, CVSS scores (which may be adjusted by severity precedent), or exact response content. This stability ensures that the same underlying vulnerability produces the same fingerprint whether discovered today or six months from now.

Fingerprints are stored in the finding's fingerprint field and indexed in the database for fast matching across scans.

The Continuity States

When a repeat pentest runs on a target that has been scanned before, TurboPentest compares the new findings' fingerprints against all previous findings for that target and assigns each a continuityStatus of new, confirmed, or retest_confirmed:

New

A finding with status new has a fingerprint that does not match any finding from previous scans of this target. This vulnerability was not present (or not detected) in earlier pentests. New findings deserve immediate attention because they may represent:

• Recently introduced vulnerabilities from new code deployments
• Vulnerabilities that were always present but previously missed (agents use different strategies each run)
• Issues introduced by infrastructure or configuration changes

Confirmed

A finding with status confirmed has a fingerprint that matches a finding from a previous scan and is still present. This vulnerability was found before and has not been remediated. Confirmed findings are tracked with the carriedFromScanId field, which records which earlier scan first discovered the vulnerability.

Confirmed findings are a signal for action. A vulnerability that stays confirmed across three pentests is not going to fix itself. The continuity data helps security managers prioritize remediation conversations: "This critical SQL injection has been present for four months across three consecutive pentests."

Retest_confirmed

A finding with status retest_confirmed is a prior finding that the current pentest's live retest oracle actively re-verified as still present. Rather than relying on a stored result from an earlier scan, the oracle re-checks the finding against the live target during Phase 2 and confirms it remains exploitable. Re-exploited findings receive fresh screenshots captured during the current pentest.

The Live Retest Oracle

Retesting is a live, fresh-oracle pass that runs inside Phase 2 - it re-checks each prior finding against the current target rather than replaying a stored verdict from a previous scan. For every previous finding, the oracle returns one of three verdicts, which map to a continuity outcome:

• still_present → confirmed. The oracle reproduces the finding, so it is carried forward as confirmed (or retest_confirmed when the retest pass itself re-exploits it with fresh evidence).
• fixed → not_confirmed. The oracle cannot reproduce the finding. It is marked not_confirmed, treated as resolved, and is not carried forward into the active findings.
• unsure → unsure. The oracle can neither confirm nor disprove the finding. It is carried forward as unsure rather than silently reported as resolved - a failed or ambiguous re-verification is never treated as evidence of remediation.

This live-oracle step prevents false "resolved" classifications caused by pentest variation - sometimes a tool or agent does not re-surface a finding due to network conditions, timing, or depth, not because it was actually fixed.

Screenshots Across Scans

Screenshots follow the same evidence-first principle. When a prior finding was supported only by tool-generated screenshots, those images are carried forward but hard-captioned "Captured <date>, prior pentest" so it is always clear they are not fresh. When a finding is re-exploited in the current pentest, it gets brand-new screenshots captured during this run.

Severity Precedent

The finding continuity system includes a severity precedent mechanism. When a fingerprint is seen for the first time, its severity, CVSS score, and CVSS vector are recorded as the precedent. On subsequent scans, if the same fingerprint is assigned a different severity, the precedent provides context for review.

This is valuable because AI agents may assess severity slightly differently between scans based on context. The precedent system ensures consistency: once a vulnerability has been classified as critical, subsequent scans maintain awareness of that classification even if the agent's current assessment differs slightly.

Severity precedents are stored globally, not per-user or per-scan. When the same vulnerability type appears on a different target, the global precedent informs the severity assessment, creating cross-target learning.

Previous Finding Context

When Paladin begins Phase 2 on a repeat pentest, it receives previous finding context - a summary of what was found in earlier scans of the same target. This context includes the fingerprints, titles, severities, and statuses of previously discovered vulnerabilities.

This context serves two purposes:

Efficiency - Agents can prioritize re-checking known vulnerabilities to confirm whether they are still present or resolved, rather than spending time rediscovering them from scratch.

Depth - Knowing what was found before, agents can focus additional effort on discovering new vulnerabilities rather than re-treading the same ground. If the previous scan found 12 findings, the agent allocates more time to exploring unexplored attack surfaces.

Reading the Continuity Dashboard

The scan detail page presents continuity data in a clear visual format:

New findings are highlighted with a distinct indicator, drawing attention to vulnerabilities that were not present in previous scans. These are your highest-priority triage items.

Confirmed findings show their history: when they were first discovered, how many consecutive scans they have appeared in, and whether their severity has changed. A finding confirmed across five scans carries more urgency than one appearing for the second time.

Resolved findings (marked not_confirmed by the retest oracle) appear in a resolved section, showing what was previously found and could no longer be reproduced. This is your remediation success story - concrete evidence that your security work is having an effect.

Tracking Security Posture Over Time

The real power of finding continuity emerges across multiple pentests. Over time, you can observe:

• Overall trend - Is the total number of findings increasing, decreasing, or stable?
• Severity distribution shift - Are critical findings being resolved while mediums accumulate?
• Remediation velocity - How quickly are findings moving from new to resolved (not_confirmed)?
• Regression detection - Do resolved findings reappear, indicating fixes that were reverted or incomplete?
• Coverage expansion - Are new findings being discovered in previously untested areas?

This data transforms pentesting from a point-in-time exercise into a continuous security improvement program. Instead of asking "Are we secure?" you can ask "Are we getting more secure?" - and have the data to answer.