Skip to content

Vulnerability Management Hub

NodeZero's Vulnerability Management Hub is a powerful set of tools designed to help security teams seamlessly Fix and Verify weaknesses uncovered during autonomous pentests. As part of the FFV (Find, Fix, Verify) 2.0 initiative, the Remediations Hub simplifies workflows, improves clarity, and supports automation across vulnerability lifecycle management.

Overview

The Vulnerability Management Hub introduces capabilities specifically built for Fixers and Verifiers to:

  • Prioritize and take action on high-risk weaknesses.
  • Track remediation and verification progress.
  • Integrate with existing ticketing and workflow systems (e.g., ServiceNow, Jira).
  • Provide audit-ready evidence of mitigation or remediation.
  • Maintain an operational backlog that distinguishes between system observations and user decisions.

Key Features

Vulnerability Management Page

A centralized view that organizes all discovered weaknesses and their current fix/verify status. This serves as the main workspace for Fixers and Verifiers.

  • System status versus user status: In separate, dedicated columns, view what NodeZero observed (the STATUS column) alongside what your team decided (the MARKED AS column).
  • Filter and sort by severity, asset, status, or remediation type.
  • See grouped weaknesses tied to common fixes (e.g., 1-Click Verify).
  • Inline actions: add notes, dispatch tickets, mark as verified, or close items.

Vulnerability Management Hub dashboard, showing bar graphs and columns for system status, user status, and severity score

Vulnerability Management Hub dashboard, with system versus user status indicators

Weakness State Definitions

NodeZero tracks the lifecycle of vulnerabilities across pentests using standardized states. These help your team understand whether issues are actively present, have been resolved, or have re-emerged due to configuration drift.

System Status (Observation-Based)

NodeZero automatically assigns system statuses based on what it observes during a pentest.

  • Open: A weakness that is present as of the most recent pentest. This includes newly discovered vulnerabilities and unresolved issues from previous tests.
  • Mitigated: A weakness that was previously open but is no longer detected, while the associated asset is still present. This indicates the issue was resolved (e.g., patched or hardened) without removing the host.

  • No Longer Found: An explicit status for weaknesses previously detected but no longer observed. This applies when the asset (or root asset) is found, but the weakness is not.

    Tip

    This means "not observed," not necessarily "proven fixed." It allows for a clean workflow without overstating confidence.

  • Regressed: A weakness that was previously mitigated but has reappeared in a later pentest.

    Important

    For a weakness to be marked as "Regressed," it must have appeared in at least three pentests:
    1. Initially discovered.
    2. Marked as mitigated in a later test.
    3. Detected again in a subsequent test on the same asset.

The determination is not limited to the same pentest template. What matters is that the weakness reappears in scope (e.g., same host and port) in a future test.

User Status (Workflow-Based)

User statuses allow customers to manage their backlog based on internal decisions.

  • Compensating Control The user has mitigated the risk through alternative controls rather than fixing the underlying issue directly.
  • Verify Compensating Control The user has declared a compensating control and is awaiting verification that it sufficiently mitigates the risk.
  • Fixed The user has remediated the issue and believes the underlying weakness is no longer present.
  • Mute The user has chosen to hide the issue from active views without resolving or accepting the risk.
  • Potential False Positive The user believes the finding may not be valid and is investigating whether the issue actually exists.
  • Risk Accepted The user has reviewed the issue and explicitly accepted the risk without taking remediation action.
  • To Do The user has acknowledged the issue and plans to address it, but has not yet taken action.
  • Closed: A user-applied status to remove items from the active queue. This is intended for cases where NodeZero cannot confidently assign "No Longer Found," such as:
    • Assets decommissioned or permanently out of scope.
    • Network or attack configuration changes that prevent re-testing.
    • Programmatic closure decisions based on internal policy.

Why Status Separation Matters

By maintaining System Status and User Status as separate columns, NodeZero prevents the conflation of attacker observations with workflow decisions.

  1. Operational Focus: The VMH behaves like a real operational backlog, keeping focus on what still needs action.
  2. Observation Honesty: We maintain transparency about what was actually seen versus what was manually moved through the workflow.
  3. Audit Integrity: Even if a weakness is "Closed" or "No Longer Found," NodeZero preserves the full history and reporting access for compliance and traceability.

Asset Detail Modal

Clicking on an asset opens a modal view with:

  • Associated weaknesses by risk level.
  • Status of remediation/verification.
  • Related notes or actions.

Asset Detail modal, showing 2 of 25 pentests that discovered a given weakness

Asset Detail modal

Weakness Detail Modal

Dive deeper into a specific weakness with:

  • Exploitation evidence and contextual attack path details.
  • Clear remediation guidance (e.g., patch, config, mitigation).
  • Verification status and fix history.

Impact Detail Modal

Understand the broader impact of unresolved weaknesses:

  • What could happen if the issue isn't addressed.
  • Which assets or business units are affected.

Add Notes

Leave internal context for team collaboration:

  • Note types: remediation notes, verification status, assumptions, blockers.
  • Notes persist across assets and weaknesses for traceability.

Add Note modal, with Status drop-down and Note free-text field

Add Note modal

Bulk 1-Click Verify

Group related weaknesses with a single common fix:

  • Apply fix or verification to all grouped weaknesses at once.
  • Helps speed up MTTR and improve clarity on shared vulnerabilities.

1-Click Verify Pentest modal, showing "accept the risk" confirmation check box, with alternative "Run Pentest" and "Close" buttons

1-Click Verify Pentest modal

How to Use Ticketing in NodeZero

The Ticketing feature allows you to seamlessly create and manage issues in external platforms like ServiceNow or Jira directly from the NodeZero Vulnerability Management Hub. You can dispatch tickets from NodeZero to your integrated ticketing system, and each ticket will include details such as the weakness name, description, assets affected, fix actions, and any additional notes.

Prerequisites

Before using Ticketing, ensure the following are in place:

  • Your organization has integrated Jira or ServiceNow with NodeZero.
  • You have the correct permissions in both NodeZero and the external system.
  • (Optional) Configure the webhook integration so that ticket status changes automatically sync back to NodeZero.

For setup instructions, see:

Creating a ticket

You control exactly which weaknesses are turned into tickets. To create one:

  1. In the VMH table, select a weakness that you want to track.
  2. Open the actions menu (three dots ⋮).
  3. Choose "Create Ticket."
  4. A modal will appear, allowing you to edit the Ticket Name and add notes.
  5. Click "Dispatch Ticket."

Create Ticket modal, showing Weakness Description, Assets Affected, Fix Actions, References, Additional Notes field, and Dispatch Ticket button

Create Ticket modal

Viewing and Managing Tickets

Once tickets are created, navigate to the Ticketing sub-tab inside VMH to see:

  • Ticket ID and link to the external system.
  • Current ticket status (e.g., Open, In Progress, Closed).
  • The weakness associated with the ticket.

Ticketing page, showing the columns listed above, along with columns for Ticket Name, Date Created, and Date Synced

Ticketing page

Keeping Status Updated

  • With Webhooks: Status changes in Jira/ServiceNow are automatically synced back into NodeZero.
  • Without Webhooks: You'll need to open the actions menu (three dots ⋮) and click "Sync Ticket Status."

Common Use Cases

  • Per-finding tickets: Create tickets only for high-priority weaknesses (no auto-creation).
  • Tracking remediation progress: Monitor open/closed status from NodeZero without switching between tools.
  • Audit trail: Maintain a single place where vulnerabilities and their associated tickets are visible.

Best Practices

  • Use ticketing selectively: Focus on high-severity issues rather than every weakness.
  • Configure webhooks: This ensures the smoothest synchronization between tools.
  • Audit your backlog: Regularly review the "Closed" and "No Longer Found" items to ensure no security gaps have reappeared due to environment changes.