Vulnerabilities

Assets → Vulnerabilities collects the findings your connected scanners report, plus findings you add by hand. It shows them grouped by vulnerability and by asset, tracks each one against a remediation deadline, and keeps a record of what was fixed and when.

​

Where Findings Come From

These integrations import findings: Each scanner’s page explains which of its findings are imported. To record a finding by hand, click Add Vulnerability.

​

Severity Levels

Every finding has the severity its scanner gave it: How long each severity has to be fixed is set by your remediation SLAs.

​

The Vulnerabilities Page

The page has four tabs. The header has Refresh, which asks your connected scanners to sync now and shows when they last did. It also has Download, which saves the current tab as a CSV with its filters (up to 50,000 rows), and Add Vulnerability.

​

Findings by vulnerability

One row per vulnerability (a CVE or a scanner rule) across all your assets. For example, CVE-2024-1234 in lodash on 12 assets is one row.

• The summary cards at the top show findings by severity and by SLA status. Click a part of a card to filter the list.
• Filter by Source, Severity, Fixability, SLA status and Scan type, search by title, CVE, package or asset, and sort the columns. In-scope assets only hides findings on assets that are out of scope.
• Click a row to open its panel. It shows the vulnerability’s facts once (severity, CVSS, available fix, first and last seen), its description and advisory link, and then every finding of it, one line per asset.
• Click Full details on a line to open that finding.

​

Findings by asset

One row per asset a scanner reports: a repository, image, cloud account, host and so on. Each row shows the asset’s status, scan types, findings by severity, overdue count, last scan time and scope. You can change an asset’s scope from its row. Click an asset to open its page. Findings there are grouped by package, rule or file, on the Dependencies, Code & config and Configuration tabs. From the asset page you can deactivate groups, download its findings and open the asset in Inventory. A finding that also affects other assets says Also on N other assets. Click it to see the vulnerability across all of them.

​

Deactivated

Findings whose monitoring you deactivated, grouped by vulnerability, with the reason, the end date and who deactivated them. Select findings and click Reopen to track them again.

​

History

Fixed findings, with when the SLA clock started, the deadline, when the finding was fixed and whether it was fixed on time or late. Choose a period (last 30 days, last 90 days, last 12 months or all time) and filter by result, scan type and severity. The On-time rate is the share of fixed findings that were fixed by their deadline. For example, 45 of 50 fixed on time is 90%. Findings fixed without an SLA, or fixed while deactivated, are listed but not counted in the rate. Use this tab as audit evidence of your remediation performance.

​

Finding details

A finding’s details show where it is, its source scanner, its class and every SLA date. SLA Clock Started is when its clock started, and SLA Based On is where its deadline came from. The details also say whether the finding counts in compliance tests. Findings from a scanner also show the scanner’s own triage and a link that opens them in the scanner’s console.

​

SLA Status

Each row in Findings by vulnerability shows the most urgent status of its findings: Each finding also has an SLA status: Overdue, Within SLA, Resolved on time or Resolved late.

​

Remediation SLAs

Set your SLA policy in Assets → Settings → Remediation SLAs and click Save SLAs. It has two rows, each with a Critical, High, Medium and Low window:

• Vulnerabilities: CVEs, dependencies (SCA), code (SAST), web apps (DAST) and leaked secrets
• Security alerts: misconfigurations and detections. Leave a value blank to use the vulnerability SLA.

Each window is a whole number of days, from 1 to 365. Leave a window blank to set none. Turn on Count business days only to count every window in business days instead of calendar days. The switch applies to both rows. Select Use recommended to fill the vulnerability row with 15 / 30 / 90 / 180. Owners and admins can change the SLAs. Auditors and read-only users can see them but not edit them. Which findings use the policy. Findings from TigerGate get their deadline from this policy, or from TigerGate’s own SLA when you set no window. Findings you add by hand use the due date you enter. Findings from other scanners have no deadline and show No SLA. How a deadline is calculated

• The clock starts at the exact time LowerPlane first imports the finding.
• The deadline keeps the time of day. A finding detected at 1:07 PM with a 30-day SLA is due at 1:07 PM, 30 days later.
• With Count business days only on, the count skips Saturday and Sunday, counted in UTC. A finding detected at 1:24 AM on a Friday with a 1-day SLA is due at 1:24 AM the next Monday. Public holidays aren’t skipped.

Deadlines never change once set. Changing the policy affects only findings detected after the change. Open and fixed findings keep the deadline they got when they were first detected, and a scanner’s deadline can’t be edited by hand. A finding that comes back gets a new deadline. If a fixed finding is reported again later, it counts as a new detection: its clock restarts, using the current policy.

​

SLA Notifications

SLA notifications are summaries for your whole organization, never one per finding. Deactivated findings, and findings a scanner doesn’t track, are left out.

• SLA alert (in the app): checked every hour, sent at most once every 4 hours. It counts findings that went past their deadline, or came within 72 hours of it, since the last alert. Findings that arrive already overdue, or already due within 72 hours, are counted once too. For example: 3 findings went past their SLA (1 critical, 2 high). 5 are due within 72 hours.
• Weekly SLA summary (Mondays at 08:00 UTC): findings that are overdue and findings due in the next 7 days. It appears in the app for your organization. It is also emailed to owners and admins who keep email notifications on, when Settings → Notifications → Enable notification emails is turned on.

​

Deactivating Findings

Deactivate monitoring when a finding should not count against your SLA for now, for example because no fix exists yet or the risk is accepted. Choose Deactivate monitoring from any of these places:

• Findings by vulnerability: tick one or more rows.
• A vulnerability’s panel: deactivate all of its findings, or tick some of them first.
• An asset page: tick the packages, rules or files.

Then pick all assets where the vulnerability appears or specific ones, and a reason:

• Fix is not yet available. You can also choose to reactivate it when a fix becomes available.
• Risk accepted
• False positive
• Compensating control in place
• Other

Add an explanation and choose how long: indefinitely, or until a date. One action can cover at most 1,000 findings. Deactivated findings move to the Deactivated tab, with the reason, the person and the date. They leave the lists, counts and tests. Their SLA deadline doesn’t change. They come back when:

• you Reopen them on the Deactivated tab;
• the end date passes;
• a fix becomes available, if you chose that;
• the finding is fixed and later detected again.

LowerPlane checks end dates and fix availability every 15 minutes. Deactivating doesn’t change anything in the scanner.

​

Accepting Risk and False Positives

Not every finding needs a fix right away. When the risk is acceptable, or the finding is wrong:

• Findings from a scanner that owns their status, such as TigerGate: deactivate monitoring with the reason Risk accepted or False positive. Their status can’t be changed by hand, because the next sync would set it back. You can also suppress the finding in the scanner, if it supports that.
• Findings you added by hand, and findings from other scanners: deactivate them the same way, or open the finding’s details and set its status to Accepted or False Positive.

Always write down why, who approved it and which compensating controls are in place.

​

Scope and Tracking

Out-of-scope assets. You can mark an asset out of scope, or as non-production, in Inventory, Repositories or Findings by asset. A reason is required. Its findings stay visible but don’t count in compliance tests. Turn on In-scope assets only to hide them. Findings a scanner doesn’t track. Some scanners leave certain findings out on purpose. For example, TigerGate doesn’t track findings suppressed in TigerGate, or code findings outside a repository’s production branch. Those findings are left out of every list, count and test, and asset pages show how many were left out and why. See TigerGate’s rules.

​

Compliance Impact

Vulnerability management is a core requirement across the frameworks LowerPlane supports, for example SOC 2 CC7.1, ISO 27001 A.8.8, HIPAA §164.308(a)(8) and PCI DSS 6.3.3 and 11.3.1. Your scanner integrations create the tests that check it, mapped to those controls. For example, TigerGate’s tests check that critical, high, medium and low vulnerabilities, leaked secrets and misconfigurations are fixed within your SLA, and that monitored assets are scanned on schedule. When a failing finding is fixed and the scanner stops reporting it, its remediation task closes automatically.

​

Best Practices

• Scan continuously, not periodically. Connect scanners that sync regularly; hourly works well.
• Set realistic SLAs. SLAs that are too aggressive lead to overuse of deactivation. SLAs that are too lenient leave you exposed.
• Track every severity, not just critical. Auditors look at your whole vulnerability management process.
• Review deactivated findings quarterly. Conditions change. A risk that was acceptable six months ago may no longer be.
• Use the History tab as evidence. Its on-time rate shows auditors how well you meet your SLAs.