Triage & Ignoring

Learn how to triage findings, mark false positives, and manage suppressions.

Not every finding requires immediate action. Some may be false positives, accepted risks, or low-priority issues. PrismSec provides tools to triage findings, ignore false positives, and suppress specific checks — all while maintaining an audit trail for compliance and review.

Triaging Findings

Triage is the process of evaluating findings to determine which require action and which can be ignored or deferred.

Recommended Triage Workflow

  1. Review the finding — Read the description, evidence, and suggested fix
  2. Validate the issue — Is this a real vulnerability or a false positive?
  3. Assess risk — Does the severity align with the actual risk in your context?
  4. Decide on action:
    • Fix immediately — For Critical and High findings
    • Plan to fix — For Medium findings, schedule remediation
    • Ignore — For false positives or accepted risks
    • Defer — For Low findings that can wait

PrismSec's dashboard provides a triage view where you can filter findings by severity, assign them to team members, and track remediation progress.

Ignoring Findings

If a finding is a false positive or an accepted risk, you can mark it as Ignored. Ignored findings:

  • No longer appear in the PR comments
  • Do not contribute to the risk score
  • Are excluded from CI status checks
  • Remain visible in the dashboard (for audit purposes)

How to Ignore a Finding

Option 1: Dashboard

  1. Go to the PrismSec dashboard
  2. Navigate to the Findings tab for your repository
  3. Click on the finding you want to ignore
  4. Click Ignore and provide a justification (required)

Example justification:

False positive: This code path is only reachable by authenticated admin users,
and input is validated earlier in the request handler.

Option 2: Inline Comment

Ignore a finding directly in your code using a special comment:

Python:

# prismsec-ignore: sql-injection
query = f"SELECT * FROM users WHERE id = {user_id}"

JavaScript/TypeScript:

// prismsec-ignore: xss
element.innerHTML = userInput;

YAML (IaC):

# prismsec-ignore: public-s3-bucket
resource "aws_s3_bucket" "public_assets" {
  acl = "public-read"
}

The prismsec-ignore comment must include the finding ID (shown in the PR comment or dashboard).

Inline ignores are permanent until the comment is removed. Use them sparingly and document why the finding is safe to ignore.

Justification Requirement

When ignoring a finding, you must provide a justification. This creates an audit trail for security reviews and compliance:

  • False positive — Explain why the tool misidentified the issue
  • Accepted risk — Explain why the risk is acceptable (e.g., internal-only code, mitigated by other controls)
  • Will fix later — Explain when and why remediation is deferred

Justifications are stored in the PrismSec database and visible in the dashboard.

Suppressions (Global Ignores)

For recurring false positives or specific checks you want to disable project-wide, use suppressions in the config file.

Suppress by Rule ID

Disable specific vulnerability checks:

# prismsec.yml
suppressions:
  - rule_id: hardcoded-secret-placeholder
    reason: "Our test fixtures use placeholder secrets that are never deployed"
  
  - rule_id: missing-csrf-token
    reason: "API endpoints use OAuth2 bearer tokens, not session cookies"

Suppress by Path

Ignore findings in specific files or directories:

suppressions:
  - paths:
      - "test/**"
      - "examples/**"
    reason: "Test and example code do not require production-level security"

Suppress by Severity

Exclude Low or Medium findings from CI checks (but still report them in the dashboard):

suppressions:
  - severity: low
    reason: "Low-severity findings are tracked but do not block merges"

Reviewing Ignored Findings

Ignored findings are not deleted — they remain in the dashboard for audit and review:

  1. Go to the Findings tab
  2. Filter by Status: Ignored
  3. Review the justifications

You can un-ignore a finding if the context changes (e.g., a previously accepted risk is no longer acceptable).

False Positive Feedback

If you encounter a false positive, you can report it to the PrismSec team:

  1. Click Report False Positive in the finding detail view
  2. Provide context on why the finding is incorrect
  3. PrismSec's security team will review and improve the detection rules

Your feedback helps improve PrismSec's accuracy for all users.

Best Practices

Do Ignore

  • False positives — When the tool misidentifies a safe pattern as vulnerable
  • Test code — When test fixtures or mocks trigger findings
  • Legacy code — When fixing would introduce more risk than leaving it (document the decision)
  • Third-party code — When you don't control the vulnerable code (but plan an upgrade path)

Don't Ignore

  • Critical findings — Unless there is a documented, strong justification
  • Secrets in production code — Even if they're "not sensitive" (they should be in environment variables)
  • Known CVEs — Unless the vulnerable function is provably unreachable in your code

Over-ignoring findings defeats the purpose of security scanning. If you find yourself ignoring many findings, consider adjusting your scan configuration or addressing root causes (e.g., refactoring insecure patterns).

Compliance and Audit Trails

PrismSec maintains a full audit trail of all ignore actions:

  • Who ignored the finding
  • When it was ignored
  • Why (the justification)
  • Current status (still ignored, un-ignored, or resolved)

This audit trail is accessible via the dashboard and can be exported for compliance reporting.

Next Steps