Saltar al contenido principal

Finding Triage

Triage is the process of reviewing, prioritizing, and categorizing security findings. This guide covers the finding lifecycle, severity levels, and triage actions available in Plexicus.

Finding Lifecycle​

Each security finding progresses through these stages:

Discovered → Reviewed → Enriched → Triaged → Remediation → Verified

1. Discovered​

  • A scanner (SAST, SCA, container, etc.) detects a potential vulnerability
  • Plexicus records the finding with:
    • Severity (from scanner)
    • Location (file, line, function)
    • Reference (CVE, CWE, etc.)
    • First occurrence timestamp

2. Reviewed​

  • A user or AI enrichment process validates the finding
  • AI enrichment may lower or raise severity based on code context

3. Enriched (Optional)​

  • AI enrichment analyzes the vulnerable code path to determine:
    • Exploitability: Can this vulnerability actually be exploited?
    • Business Impact: What systems could be affected?
    • Confidence: How certain is the analysis?
  • Enrichment results augment the finding with additional metadata

4. Triaged​

  • Team member marks the finding as:
    • Valid — Acknowledged and requiring remediation
    • False Positive — Not a real vulnerability
    • Accepted Risk — Known risk, intentionally not fixed
    • Duplicate — Same vulnerability already tracked elsewhere

5. Remediation​

  • Remediation PR is created (manual or AI-assisted)
  • Code change addresses the vulnerability

6. Verified​

  • Verification scan confirms the fix resolves the vulnerability
  • Finding is marked as Resolved

Accessing Findings​

  1. Navigate to Applications or Findings
  2. You'll see a list of all findings across your repositories
  3. Use filters to focus on specific categories (see Filtering below)

Understanding Severity Levels​

Plexicus uses a five-level severity scale:

SeveritySymbolColorMeaningSLA
Critical🔴RedExploitable vulnerability with high impact; requires immediate action24 hours
High🟠OrangeSignificant vulnerability; should be fixed within sprint1 week
Medium🟡YellowModerate risk; plan fix in next quarter30 days
Low🔵BlueMinor issue; fix when convenient90 days
Info⚪GrayInformational finding; no security impactN/A

SLA — Target time to remediate before escalation (configurable per plan).

nota

Severity is assigned by the scanner. AI enrichment may suggest a different severity based on code analysis; consider the enrichment recommendation when triaging.

Filtering Findings​

Use filter controls to focus your review:

By Severity​

  • Show only Critical and High findings for urgent action
  • Example: Hide Low and Info to reduce noise

By Tool​

  • Filter by scanner type: SAST, SCA, Container, Secrets, IaC, etc.
  • Useful for delegating tool-specific reviews to experts

By Status​

  • Discovered — Unreviewed findings
  • Enriched — AI analysis complete
  • Triaged — Categorized (Valid, False Positive, Accepted Risk, Duplicate)
  • Remediated — Fix PR created
  • Verified — Fix confirmed

By Repository​

  • Filter findings for a specific repo or application
  • Useful for single-project reviews

By Date Range​

  • Focus on findings from the past week, month, or custom range
  • Good for identifying new issues introduced recently

By Type​

  • Vulnerability type: SQL Injection, XSS, Dependency, Hardcoded Secret, etc.
  • Example: Show all "Hardcoded Password" findings

By Assignment​

  • Filter by assigned team member
  • Useful for workload distribution

Triage Actions​

Mark as Valid​

Indicates: This is a real vulnerability that should be fixed.

When to use:

  • You've confirmed the vulnerability in code
  • The issue is exploitable under real-world conditions
  • Remediation is planned or in progress

Effect: Finding moves to Valid status. A remediation request can be created.

Mark as False Positive​

Indicates: This is not a real vulnerability. The scanner raised a false alarm.

When to use:

  • Code is safe despite scanner warning (e.g., SQL query is parameterized, but scanner didn't detect it)
  • Finding is in non-production code (test, docs, example)
  • Vulnerability is not applicable to your codebase

Effect: Finding is archived and hidden by default. Include a comment explaining why (helps retrain AI models).

tip

When marking false positives, add a comment like "SQL is parameterized using prepared statement" to help Plexicus improve detection.

Mark as Accepted Risk​

Indicates: This vulnerability is known and intentionally not fixed (due to constraints, external factor, or accepted business risk).

When to use:

  • You have a valid reason not to fix (legacy system, end-of-life code, etc.)
  • Risk is documented and approved by leadership
  • Remediation effort is not justified by business impact

Effect: Finding is tracked as Accepted Risk. Audit logs record who accepted and when.

Required fields:

  • Risk Owner — Person responsible for the risk
  • Acceptance Date — When risk was accepted
  • Justification — Why remediation is deferred (required for compliance audits)
  • Expiration Date (optional) — When to re-evaluate the risk

Mark as Duplicate​

Indicates: This finding is a duplicate of another already tracked.

When to use:

  • Same vulnerability found in multiple branches or by different scanners
  • Same root cause appears in multiple codebases
  • You want to consolidate findings into a single remediation effort

Effect: Finding is linked to the primary issue. Metadata is merged (e.g., all affected locations listed).

Assign to Team Member​

Assigns responsibility for triage or remediation to a specific person.

  1. Click Assign
  2. Select team member from dropdown
  3. (Optional) Add a comment for context
  4. Assign

The assignee will see the finding in their dashboard and can receive notifications.

AI Enrichment​

If your plan includes AI enrichment, Plexicus can automatically analyze findings to:

Exploit Path Analysis​

  • Traces whether the vulnerable code is actually reachable from user input
  • Highlights if a vulnerability is in dead code or unreachable function
  • Reduces false positives

Severity Reassessment​

  • Considers business context: Is this API external-facing? Is the vulnerable data sensitive?
  • May raise severity if exploitation is likely, or lower if impact is contained
  • Shows confidence score (0–100%)

Code Context​

  • Provides snippet showing the vulnerability and surrounding code
  • Suggests fix patterns based on code analysis
  • Indicates if similar patterns exist elsewhere in the codebase

SBOM Integration​

If the finding relates to a dependency, enrichment may:

  • Check if the component is actually used (or dead dependency)
  • Propose SBOMupdate or dependency upgrade
  • Cross-reference VEX statements

Enrichment Confidence:

  • High (80–100%) — Actionable. Trust the recommendation.
  • Medium (50–80%) — Review manually; enrichment may have missed context.
  • Low (<50%) — Treat as informational; do your own analysis.

Bulk Triage Actions​

To triage multiple findings at once:

  1. Select findings using checkboxes in the list (or "Select All")
  2. Click Bulk Actions
  3. Choose:
    • Mark as Valid
    • Mark as False Positive
    • Mark as Accepted Risk
    • Assign to
  4. Confirm

Bulk actions are useful for:

  • Marking a batch of false positives from a known tool limitation
  • Accepting risk for end-of-life code
  • Assigning all High findings to the security team

False Positive Feedback Loop​

When you mark a finding as false positive, provide feedback:

  1. Reason — Select from preset list or custom explanation
  2. Code context — Why the code is safe
    • Example: "Query uses parameterized prepared statement"
    • Example: "Field is validated client-side and backend enforces length limits"
  3. Suggested fix — How the scanner could improve detection

This feedback helps Plexicus and scanner vendors improve accuracy for future scans.

Triage Best Practices​

1. Prioritize by Severity + Exploitability​

  • Review Critical findings first, even if AI confidence is low
  • Skip Info findings unless you have bandwidth

2. Leverage AI Enrichment​

  • Trust AI exploit path analysis to identify unreachable code
  • Use enrichment confidence to decide if manual review is needed
  • Use AI suggestions to speed up fix creation

3. Document Accepted Risks​

  • Include business justification (compliance, legacy system, etc.)
  • Set expiration dates for re-evaluation
  • Track approval chain in comments

4. Assign Consistently​

  • Assign to subject matter expert for that tech stack
  • Set expectations: "Review by EOW"
  • Track assignment in Sprint planning

5. Track Metrics​

  • How many findings per sprint? (velocity)
  • What's the false positive rate? (tool accuracy)
  • How long from discovery to remediation? (MTTR)