Vulnerability Management

Overview

Vulnerability Management is the central hub for tracking, triaging, and resolving security findings across your entire organization. Every scanner in Fencer — code, cloud, domain, application, container, endpoint, network, and SaaS — feeds its results into this unified view, giving you a single place to prioritize and manage your security posture.

Each vulnerability is identified by a unique slug (e.g., VULN-A1B2C) and is always tied to the asset and scan that produced it. Fencer automatically groups related vulnerabilities into buckets so you can triage at scale rather than one finding at a time.

Prerequisites

• An active Fencer organization with at least one connected integration or asset.
• Appropriate role permissions — every built-in role can view vulnerabilities; ignoring, deferring, assigning, and setting priority require the vulnerabilities:edit ability, which Administrator and Team Member hold.

How it works

When a scan completes, Fencer creates or updates vulnerability records based on fingerprinting. New findings are marked Open, and findings that no longer appear in subsequent scans are automatically marked Resolved. Vulnerabilities that already exist are updated with the latest scan context while preserving their triage state.

Vulnerabilities are grouped into buckets by title (default) or by location. Buckets aggregate severity, status, and priority from their member vulnerabilities, letting you perform triage actions once and have them cascade to every related finding.

Usage / Configuration

Viewing vulnerabilities

1. Navigate to Main > Vulnerabilities.
2. By default you see the Grouped tab (vulnerability buckets). Use Group by to group by Title or Location. Switch to the flat vulnerability list with the All tab.
3. Use the search box to find vulnerabilities by title, slug, or asset name.
4. Apply advanced filters to narrow results by severity, priority, status (including Ignored and Deferred, optionally by reason), category, assignee, asset, location, SLA status, Fencer triage verdict, and more.

The page also has a Reviews tab for monthly reviews (shown to roles with vulnerabilities:edit) and a Rules tab for the scanner rules behind your findings.

The location filter matches against whichever location a vulnerability has — a code file path, a URL, a domain, or a resource identifier — depending on its category. Choose whether to match vulnerabilities whose location starts with, or contains, the text you enter (with “does not” variants to exclude a prefix or substring instead). For example, filter code vulnerabilities to a single package by entering its path prefix (e.g., packages/api/).

Understanding severity levels

Fencer uses five severity levels, ordered from most to least critical:

Level	Description
Critical	Exploitable issues requiring immediate action
High	Serious issues that should be prioritized
Medium	Moderate-risk findings
Low	Minor issues with limited impact
Info	Informational findings, no direct risk

Severity comes from the scan that found the vulnerability. Use priority, below, to rank vulnerabilities beyond their severity.

Understanding statuses

Each vulnerability has one of three statuses:

• Open — The vulnerability is active and requires attention.
• Ready for verification — A fix has been applied and the vulnerability is awaiting verification. Penetration test findings use it, and so do vulnerabilities whose linked Jira or Linear issue is completed.
• Resolved — The vulnerability is no longer present or has been confirmed as fixed.

Scans set the status of most vulnerabilities: a vulnerability that a later scan no longer finds is resolved, and one that comes back is reopened. Status buttons (Mark Resolved, Mark Open, Ready for Verification) appear only on penetration test findings. The History timeline under More Info on a vulnerability shows when it was discovered, resolved, or rediscovered.

Setting priority

Priority provides a separate triage dimension from severity. Five priority levels are available:

Priority	Score range
Urgent	80–100
High	60–79
Moderate	40–59
Low	20–39
Minimal	0–19

Fencer calculates a priority score for each vulnerability from its severity, whether it is live (on the default branch or in production), and whether it has a known CVE, an exploited CVE, a CWE, or an OWASP classification. Vulnerabilities that are not live get the lowest scores.

You can set priority on individual vulnerabilities or on buckets (which cascades to all vulnerabilities in the bucket).

Asset criticality

Each asset has a Criticality from Low (0) to High (100), which scales the priority of its vulnerabilities: a vulnerability’s calculated score is multiplied by the asset’s criticality divided by 100. At 100, the default, priority is unchanged; at 50, an Urgent score of 90 drops to 45 (Moderate). Lower criticality for development, test, or sandbox assets so their vulnerabilities rank below production ones.

Set criticality on a repository under its Settings (the Criticality section), or on any resource in Main > Assets > Inventory (the Criticality card in its details). Changing it recalculates the priority of that asset’s existing vulnerabilities.

Ignoring vulnerabilities

To suppress a vulnerability from active views, mark it as ignored with one of these reasons:

• False Positive — The finding is incorrect.
• Will Not Fix — You accept the finding but choose not to remediate.
• Acceptable Risk — The risk is understood and accepted.
• Duplicate — The finding duplicates another tracked issue.
• Superseded — A newer finding or fix replaces this one.
• Third Party Code — The issue is in code you do not control.
• No Fix Available — No fix exists yet for the issue.

A vulnerability ignored because its scanner rule was disabled shows Rule Disabled. You can optionally add notes explaining the decision. Ignored vulnerabilities can be unignored at any time.

Note

You can also defer a vulnerability, with a reason, for 7 days, 14 days, 30 days, or 90 days (or Until a patch is available when no fix exists upstream). Deferred vulnerabilities are temporarily suppressed and automatically return to active views when the deferral period expires.

Assigning vulnerabilities

1. Open a vulnerability or bucket.
2. Select an Assignee from the list of organization members.
3. The assignee receives a Task assigned notification (in line with their notification rules) with a direct link to the vulnerability.

Unassign by choosing No assignee.

Bulk operations

Select multiple vulnerabilities or buckets in the datagrid to perform bulk actions:

• Ignore / Unignore — Apply or remove an ignore reason across all selected items.
• Defer / Undefer — Temporarily suppress or restore selected items.
• Assign — Assign or unassign a team member to all selected items.
• Priority — Set a priority level across all selected items.
• Fix — Start an AI fix for each selected vulnerability that can be fixed automatically (not offered on buckets).
• Linear / Jira — Create, link, or unlink a tracker issue for the selection, when that tracker is connected.
• Start Review — Start a vulnerability review of the selected vulnerabilities (not offered on buckets).

To act on every item that matches the current filters, not only the visible page, open the selection menu and choose All (N).

Commenting

Use the Comments card on a vulnerability to discuss findings with your team. Comments support creating, editing, and deleting — each comment is attributed to the author and timestamped.

Ticket integration

Vulnerabilities can be linked to external issue trackers from the Tracking field on a vulnerability or with the bulk Linear and Jira actions:

• Jira — When a linked issue moves to the status you mapped as done, its open vulnerabilities move to Ready for verification; when it moves to the cancelled status, they are ignored.
• Linear — The same issue-to-vulnerability updates as Jira, and in the other direction, when a scan resolves or reopens a linked vulnerability, Fencer updates the Linear issue’s status.

See Jira Integration and Linear Integration for the status mapping.

Examples

Triaging a new critical finding

1. Navigate to Main > Vulnerabilities and filter by Severity: Critical and Status: Open.
2. Click a vulnerability bucket to open its vulnerabilities.
3. Review the description, affected asset, and code location.
4. Assign the bucket to the responsible engineer.
5. Set priority to Urgent.
6. Optionally create a Jira issue for tracking with the bulk Jira action.

Bulk-ignoring third-party findings

1. In the vulnerabilities view, filter by Category: Dependency (or the relevant category).
2. Select the vulnerabilities you want to suppress.
3. Choose Ignore and select Third Party Code as the reason.
4. Add a note such as “Upstream library — tracked via vendor advisory.”

Troubleshooting

• Vulnerability not appearing after a scan — Only vulnerabilities from the default branch (for code scans) are marked as “live” and shown in the default view. Check that the scan ran against the correct branch.
• Cannot change the status of a vulnerability — Only penetration test findings have status buttons: on a manual engagement the assigned tester resolves or reopens findings, and you mark a finding Ready for Verification once you have fixed it. Other vulnerabilities are resolved automatically when a scan no longer finds them.
• Bucket counts seem incorrect — Bucket data is recalculated after triage actions. If counts appear stale, re-trigger a scan or contact support.

Related pages

• Platform Overview
• Vulnerability Details and Triage
• Monthly Vulnerability Reviews
• Threat Intelligence
• Asset Scope Management
• Jira Integration
• Linear Integration
• Search and Advanced Filters