Finding Lifecycle & Deduplication

Proofarc tracks every security finding through a complete lifecycle — from discovery to resolution. Findings are deduplicated across tools, tracked over time, and automatically synced with Jira.

How Findings Work

Deduplication

Every finding gets a unique fingerprint:

signature = SHA256(type + title + target + cweId + sourceFile)

When two different scanners find the same vulnerability, it's one finding, not two.

Example:

1. ZAP finds "SQL Injection" on /login.php (CWE-89) → Finding created
2. Nuclei finds the same thing → Same signature → occurrenceCount incremented, lastSeenAt updated
3. No duplicate — one finding, two tools confirmed it

The finding belongs to the project, not to any single tool. The platform tracks:

• firstSeenAt — when any tool first discovered it
• lastSeenAt — when any tool last confirmed it
• occurrenceCount — how many times it's been found across all scans
• toolName — which tool originally discovered it

Lifecycle States

Each finding moves through 8 states. Some transitions are automatic (driven by scans and Jira sync), others are manual (team decisions).

Status	Score Multiplier	Assignment	Meaning
OPEN	1.0x	Auto	New finding discovered by a scan
TRIAGED	0.9x	Auto (Jira)	Team acknowledged — Jira ticket in "To Do"
IN_PROGRESS	0.7x	Auto (Jira)	Developer working on it — Jira ticket "In Progress"
REOPENED	1.2x	Auto	Scan found it again after it was marked FIXED
WONT_FIX	0.25x	Manual	Team accepts the risk — Jira "Won't Do" also triggers this
FALSE_POSITIVE	0x	Manual	Not a real vulnerability — platform-only decision
FIXED	0x	Auto (Jira)	Developer resolved it — Jira ticket moved to "Done"
VERIFIED	0x	Auto (Jira)	Confirmed resolved — Jira ticket "Closed"

State Flow Diagram

Scan discovers vulnerability
        │
        ▼
      OPEN ──────────────────────────┐
        │                            │
        │ (Jira: To Do)              │ (Manual)
        ▼                            ▼
     TRIAGED                   FALSE_POSITIVE
        │                        (score: 0x)
        │ (Jira: In Progress)
        ▼
   IN_PROGRESS ──────────────────────┐
        │                            │
        │ (Jira: Done)               │ (Manual / Jira: Won't Do)
        ▼                            ▼
      FIXED                      WONT_FIX
        │                        (score: 0.25x)
        │ (Jira: Closed)
        ▼
     VERIFIED
        │
        │ (Next scan finds it again)
        ▼
     REOPENED ──► (1.2x penalty — worse than new)
        │
        └──► Back to IN_PROGRESS (dev fixes again)

Jira Integration

Automatic Ticket Creation

When a scan discovers a CRITICAL or HIGH finding:

1. Proofarc automatically creates a Jira ticket
2. Ticket includes: title, severity, CWE, target URL, description, remediation
3. Ticket is created in the configured Jira project

Bidirectional Sync

Every 30 minutes, Proofarc syncs with Jira:

Jira Status	→ Finding Status
To Do / Open	TRIAGED
In Progress	IN_PROGRESS
Done / Resolved	FIXED
Closed	VERIFIED
Won't Do	WONT_FIX

The team works in Jira — they never need to open Proofarc to manage finding status. They move Jira tickets through their normal workflow. Proofarc picks it up automatically.

Reopening Flow

When a finding that was FIXED or VERIFIED reappears in a new scan:

1. Status automatically changes to REOPENED
2. reopenedCount increments
3. A comment is added to the existing Jira ticket (not a new ticket)
4. The finding gets a 1.2x score penalty — regressions are treated more seriously than new findings

What Jira Can't Override

FALSE_POSITIVE is a platform-only decision. If a team marks a finding as false positive in Proofarc, Jira sync will never reopen it. This prevents external status changes from overriding security team decisions.

Configuration

Jira integration is configured per environment:

• Jira URL and project key
• Auto-create threshold (CRITICAL only, or CRITICAL + HIGH)
• Sync interval (default: 30 minutes)

Impact on Readiness Score

Each finding's lifecycle state directly affects the release readiness score:

• OPEN findings reduce the score at full weight
• IN_PROGRESS findings reduce it at 70% (team is working on it)
• REOPENED findings reduce it at 120% (regressions are penalized)
• FIXED/VERIFIED/FALSE_POSITIVE don't affect the score at all
• WONT_FIX carries 25% weight (acknowledged but accepted risk)

Example

A project has:

• 2 CRITICAL findings (OPEN) → 2 × 1.0 = 2.0 effective
• 3 HIGH findings (IN_PROGRESS) → 3 × 0.7 = 2.1 effective
• 1 HIGH finding (REOPENED) → 1 × 1.2 = 1.2 effective
• 5 MEDIUM findings (TRIAGED) → 5 × 0.9 = 4.5 effective
• 2 HIGH findings (FALSE_POSITIVE) → 2 × 0.0 = 0 effective

The score calculation uses effective counts, not raw counts. This rewards teams that actively triage and fix findings.

Fix Velocity Metrics

Proofarc tracks how fast your team resolves findings:

• Mean Time To Fix (MTTF) per severity level
  • CRITICAL: target 7 days
  • HIGH: target 30 days
  • MEDIUM: target 90 days
  • LOW: target 180 days
• Age penalties — findings past their target window get increasing penalties
• Recurrence rate — percentage of fixed findings that reopen
• Velocity trend — IMPROVING, STABLE, or DECLINING based on recent vs historical fix rates

These metrics help teams understand not just what vulnerabilities exist, but how effectively they're being addressed.