> ## Documentation Index
> Fetch the complete documentation index at: https://help.dsalta.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Vulnerabilities
> Track, assess, and remediate security vulnerabilities across your infrastructure and code.
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:
| Column | Description |
| ----------------------- | --------------------------------------------------------------------------------- |
| **CVE / ID** | CVE number or reference ID from the source tool, with a link out where one exists |
| **Title** | Name or description of the vulnerability |
| **Affected asset** | Which system or component is vulnerable |
| **Severity (CVSS)** | Critical, High, Medium, Low, or Info, with the CVSS score underneath |
| **Status** | Open, In progress, Resolved, False positive, or Accepted |
| **Source** | Integration name, or the label you set on a manual finding |
| **Package / component** | The affected package or component |
| **SLA** | Remediation deadline as a progress bar, with the due date underneath |
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:
| Severity | Remediate within |
| ------------ | ---------------- |
| **Critical** | 7 days |
| **High** | 14 days |
| **Medium** | 30 days |
| **Low** | 60 days |
| **Info** | 90 days |
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:
| Integration | What syncs |
| ---------------------- | ---------------------------------------------------------------- |
| **AWS** | AWS Security Hub findings. Requires Security Hub to be enabled. |
| **Azure** | Microsoft Defender for Cloud security assessments. |
| **GCP** | Security Command Center findings. |
| **GitHub** | Dependabot dependency alerts, per repository. |
| **GitLab** | Project vulnerability findings from GitLab's security dashboard. |
| **Microsoft Defender** | Defender vulnerability findings. |
| **SentinelOne** | Application risks with their CVE identifiers. |
| **Wiz** | Cloud vulnerability and misconfiguration findings. |
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](/integrations/github/code-scanning-alerts-should-be-resolved) and [Secret scanning alerts should be resolved](/integrations/github/secret-scanning-alerts-should-be-resolved).
Findings from a scanner you connect elsewhere can be recorded against the relevant control as manual evidence.
## Related pages
* [Inventory](/guides/assets/inventory)
* [Incidents](/guides/risk/incidents)
* [Integrations](/integrations/overview)
## 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](/troubleshooting/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.