Vulnerability Details and Triage

Overview

The vulnerability detail view is where you inspect, triage, and act on individual security findings. It presents all the information Fencer has collected about a vulnerability — its severity, location, affected asset, scan history, and code context — alongside the controls you need to change its status, assign an owner, or escalate it to an external ticketing system. This is the primary screen for day-to-day vulnerability triage work.

Prerequisites

• Any built-in role can view vulnerabilities (Read Only and above).
• To triage (ignore, defer, assign, set priority, or create tickets) you need the vulnerabilities:edit ability, which Administrator and Team Member hold.
• The Vulnerability Management list view is the typical entry point.

How it works

Every vulnerability in Fencer is identified by a unique slug (e.g., VULN-1234). When you open a vulnerability, Fencer loads its latest data from the most recent scan run, along with metadata from the first scan that originally detected it. The detail view combines this data into a single page: the actions and properties on one side, and cards for the overview, triage, remediation, location, comments, and more information on the other.

Vulnerabilities can also be grouped into buckets — collections of related vulnerabilities that share the same title or location. Bucket detail views provide the same triage controls, applied in bulk to every vulnerability in the group.

Usage / Configuration

Reading the vulnerability detail view

1. Navigate to the vulnerability list and click on any vulnerability row, or open a vulnerability directly via its slug URL (/a/<org-slug>/vulnerabilities/<slug>/).
2. The header shows the vulnerability’s title and slug. Below the actions, the properties panel shows:
   • Status — Open, Ready for verification, or Resolved.
   • Severity — one of Critical, High, Medium, Low, or Info.
   • Priority — the priority level; see Setting priority.
   • Upstream Fix — whether a patch exists upstream (All fixable, Partially fixable, No upstream fix, or Unknown).
   • First Seen, Resolved At, and Last Scan.
   • SLA — the remediation deadline and status (On track, Approaching, or Breached) when an SLA policy applies. Findings without a day-based target show N/A or Best effort.
   • Assignee and Tracking (linked Jira or Linear issues).
3. The Overview card has the Description and, when available, the Risk tab (Impact for penetration test findings). The Remediation card has fix guidance.
4. The Asset and Location card shows the repository or asset, the branch, and the location. If the vulnerability has a code location, Fencer displays a code snippet with the file path and lines, and links to the source file in your repository.
5. The More Info card lists References (CVE, CWE, and OWASP links when available), the Scanner Rule that produced the finding, CWE details, and the vulnerability’s History.

Viewing vulnerability history

The History timeline in the More Info card shows the key lifecycle events Fencer has recorded for the vulnerability:

• Discovered — the scan that first found it.
• Discovered on default branch / Reached default branch — for code vulnerabilities, when it first appeared on a non-default branch versus when it merged into the default branch.
• Resolved — when it stopped appearing in scan results.
• Rediscovered — when a previously resolved vulnerability reappears.

Each event shows when it happened and, where applicable, which scan, commit, and branch it’s tied to — useful for understanding how long a vulnerability has been live or how it moved through your branches before landing on main.

Fencer triage

For code vulnerabilities where Fencer can trace how data flows to the issue, Fencer triage reviews each new live finding after the scan that found it. The Fencer triage card shows its verdict and a short explanation:

• True positive — the finding looks real and should be fixed.
• False positive — Fencer triage is confident the finding is not a real issue.
• Uncertain — the evidence is not conclusive either way.
• Error — the review could not complete.

Use the thumbs up (Helpful) or thumbs down (Not helpful) buttons next to Was this helpful? to rate the verdict. Not helpful opens Help us improve Fencer triage, where you pick What should the verdict have been?, add optional notes, and click Submit feedback.

To keep confirmed false positives out of your queue, turn on Ignore confirmed false positives in the Fencer triage card under Settings > Organization. Fencer then ignores each vulnerability that triage confirms as a false positive, with the reason False Positive and the note “Auto-ignored by Fencer triage”. Uncertain and true-positive results are never ignored. A repository can override the organization default under its Settings > Automation (Auto-ignore false positives for this repository). Filter the vulnerability list by Fencer triage to review verdicts in bulk.

Changing vulnerability status

Scans set the status of most vulnerabilities: a vulnerability that a later scan no longer finds is resolved automatically. Status buttons appear only on penetration test findings:

• Mark Open — returns a resolved or ready-for-verification finding to the open state.
• Ready for Verification — signals that a fix has been applied and the finding is awaiting confirmation. On an AI penetration test, an AI agent then re-checks the finding and updates its status (AI Verification).
• Mark Resolved — marks the finding as fixed.

Note

On a manual penetration test, only the assigned tester can mark a finding resolved or reopen it. You mark a finding Ready for Verification once you have fixed it.

Ignoring a vulnerability

1. Click Ignore to open the ignore form.
2. Under Reason for ignoring, select False Positive, Will Not Fix, Acceptable Risk, Duplicate, Superseded, Third Party Code, or No Fix Available.
3. Optionally add Notes explaining your decision, then click Ignore.
4. To reverse the action, open the Ignored button’s menu and choose Unignore.

Deferring a vulnerability

1. Click Defer to open the deferral form.
2. Select a Reason for deferring and, under Defer for, choose 7 days, 14 days, 30 days, or 90 days. With No Fix Available on a vulnerability that has no upstream patch, you can choose Until a patch is available instead.
3. The vulnerability is suppressed until the deferral period expires, at which point it reappears as actionable.
4. To cancel a deferral early, open the Deferred button’s menu and choose Undefer.

Assigning a vulnerability

1. Click the Assignee field on the detail page.
2. Select a team member from the list of organization users.
3. The assignee receives a Task assigned notification with a direct link to the vulnerability.
4. To unassign, choose No assignee.

Adding comments

1. Scroll to the Comments card on the detail view.
2. Type your comment in Add a comment… and click Comment.
3. Each comment shows its author name and timestamp. Click Load older to see earlier comments.
4. You can Edit or Delete your own comments from a comment’s menu.

Linking to ticketing systems

Fencer supports creating linked issues in Jira and Linear directly from the vulnerability detail page:

1. Ensure your organization has an active Jira or Linear connection.
2. On the vulnerability detail view, the Tracking field shows a control for each connected tracker. Without a connection, it shows Setup integration instead.
3. Once you create a ticket, Fencer stores the issue key (e.g., LIN-42 or PROJ-100) on the vulnerability and displays it as a link.
4. Status changes flow back from the tracker — when a linked issue moves to its done status, Fencer marks the vulnerability Ready for verification. If the issue is cancelled, Fencer ignores the vulnerability with a “Will Not Fix” reason. For Linear, Fencer also updates the issue when a scan resolves or reopens the vulnerability.

Re-running a scan

1. If the vulnerability is eligible for rescanning, a Rerun Scan button appears on the detail page (it needs vulnerabilities:edit and an active subscription).
2. Click the button to trigger a new scan of the same asset and scan type.
3. Manual re-runs are throttled — you must wait several minutes between consecutive re-runs. The button is also disabled for an unverified domain until you verify it.

Automated remediation

For vulnerabilities that support automatic fixing (e.g., dependency updates):

1. If an open vulnerability is fixable, a fix card appears with two options: Launch Agent to Fix (an AI agent proposes the change) or Show Instructions (step-by-step manual fix instructions).
2. After you launch the agent, the card shows its state — Fix Queued, Fixing…, Fix Available, or Fix Failed — and the agent’s progress. Click View full agent details for the whole run, or Review & Re-Run Fix to try again.
3. Review the proposed change and its pull request. See Automated Remediation for when Fencer opens the pull request for you.

Caution

Automated remediation is a paid feature. Your organization must have a valid subscription with the automatic fixers entitlement enabled.

Examples

Triaging a critical code vulnerability:

You receive a notification about a new Critical severity secret detected in a repository. You navigate to the vulnerability detail view and see it is an exposed AWS access key in a configuration file. You:

1. Review the code snippet showing the exact file and line.
2. Assign the vulnerability to the repository owner.
3. Add a comment noting that the key needs to be rotated immediately.
4. Create a Linear ticket for tracking.
5. Once the developer rotates the key and removes it from code, the next scan marks the vulnerability as Resolved automatically.

Ignoring a false positive:

A dependency scan flags a vulnerability in a package you use, but you have confirmed the vulnerable code path is not reachable in your application. You:

1. Open the vulnerability detail view.
2. Click Ignore and select False Positive as the reason.
3. Add a note explaining that the vulnerable function is never called.
4. Fencer removes the vulnerability from your active count but keeps it accessible via filters.

Troubleshooting

• No status buttons — Status buttons appear only on penetration test findings. Other vulnerabilities resolve automatically when a scan no longer finds them.
• Rerun button is disabled — Manual re-runs are throttled. Hover the button to see how many minutes to wait before trying again.
• No ticket creation controls visible — Verify that your organization has an active Jira or Linear integration under Admin > Integrations, and that your role has vulnerabilities:edit.
• No Fencer triage card — Triage runs only on code vulnerabilities with traced data flow, after the scan that finds them.

Related pages

• Vulnerability Management
• Monthly Vulnerability Reviews
• Threat Intelligence
• Jira Integration
• Linear Integration
• Automated Remediation
• Roles and Permissions