Skip to main content
The Vulnerabilities page tracks every security vulnerability identified across your environment — from cloud infrastructure misconfigurations to code dependency CVEs. Each vulnerability includes severity scoring, affected assets, remediation guidance, and SLA tracking.

​
What vulnerabilities are for

Your auditor needs to see that you identify, prioritize, and fix security vulnerabilities within defined timelines. The Vulnerabilities module centralizes all findings from connected security tools and lets you track remediation progress with full audit history.

​
How vulnerabilities are collected

Vulnerabilities flow into DSALTA from two sources:
  • Integration-sourced — Eight integrations sync findings automatically — Wiz, SentinelOne, AWS (Security Hub findings), Azure (Microsoft Defender for Cloud assessments), GCP (Security Command Center findings), Microsoft Defender for Endpoint, GitHub (Dependabot alerts) and GitLab (project vulnerability findings); the table under Integrations that feed Vulnerabilities below has the detail. Each vulnerability shows the integration name as its source.
  • Manual — Log a finding yourself with Add Manual Finding, supplying the CVE or finding ID, affected asset, severity, status, source label, package or component, CVSS score, and an optional SLA due date.

​
Viewing your vulnerabilities

Each vulnerability displays: Click any vulnerability to open its detail panel, which has two tabs:
  • Summary — the Description, Remediation, CVSS vector, and package and scoring sections, plus the Status dropdown you use to move the finding through its workflow.
  • Impacted Assets — every asset the finding applies to.

​
Working with vulnerabilities

When a new vulnerability appears:
  1. Review the severity and CVSS score to understand the risk.
  2. Identify the affected asset(s) and their classification level.
  3. Update the status from the Status dropdown in the detail panel as work progresses: Open → In progress → Resolved.
  4. If the finding is not a real issue, set it to False positive. If you are knowingly living with it, set it to Accepted. There is no “on hold” status.
Prioritize Critical and High severity vulnerabilities first. Unless an explicit SLA due date is set on the finding, DSALTA calculates the deadline from the detection date using the severity: The SLA column flags a finding as due soon three days before that deadline, and as overdue once it passes. Findings in Resolved, False positive, or Accepted are excluded from SLA tracking.

​
Integrations that feed Vulnerabilities

Eight integrations sync findings into DSALTA. Each row names the integration you connect, and the feed DSALTA reads from it: To connect an integration, go to Integrations in the DSALTA sidebar.
GitHub code-scanning and secret-scanning alerts are tracked by their own compliance checks: Code scanning alerts should be resolved and Secret scanning alerts should be resolved.Findings from a scanner you connect elsewhere can be recorded against the relevant control as manual evidence.

​
GitHub reconnect banner

If you see an amber Action Required banner asking you to disconnect and reconnect your GitHub account, your GitHub connection was made before DSALTA needed the additional read permissions this page depends on. The Go to Integrations button takes you to the right place.Reconnecting means disconnecting first, which permanently deletes the data and tests already collected from GitHub — read Integration errors before you start.The banner clears itself after about a week per browser, whether or not you acted on it. Its disappearance is not confirmation that the reconnect happened.