Vulnerability Scanning

Every package published to DepAegis is automatically scanned for known vulnerabilities using industry-standard databases. This page explains how scanning works, how results are reported, and how to manage exceptions.

How Scanning Works

When a package is published, DepAegis extracts its dependency manifest (package-lock.json, packages.lock.json, or container image layers) and checks every component against two databases:

• Open Source Vulnerabilities (OSV)— an aggregated, open database that merges data from GitHub Security Advisories, npm audit advisories, RustSec, and more.
• National Vulnerability Database (NVD)— the U.S. government’s authoritative CVE repository maintained by NIST.

DepAegis matches on package name, version range, and ecosystem. Results are available within seconds of publish.

Automatic Scanning on Publish

Scanning is enabled by default for all organizations. When a package is pushed to DepAegis:

1. The package tarball is unpacked and the dependency tree is resolved.
2. Each direct and transitive dependency is checked against OSV and NVD.
3. Severity ratings are assigned based on CVSS scores.
4. Results are attached to the package version as a scan report.

Severity Ratings

Each vulnerability is classified into one of four severity levels:

Quarantine Behavior

When a package version is found to have vulnerabilities at or above the configured threshold, it is placed in quarantine. Quarantined packages:

• Cannot be installed through the registry.
• Are flagged with a red banner in the dashboard.
• Trigger a notification to organization admins and the package publisher.
• Can be released from quarantine only by an admin or by publishing a fixed version.

# Attempting to install a quarantined package
$ npm install @myorg/vulnerable-pkg
npm ERR! 403 Forbidden - Package is quararantined:
  CVE-2025-1234 (Critical) - Remote Code Execution

Viewing Scan Results

Scan results are available in the DepAegis dashboard under the Security tab for each package version. The report shows:

• CVE ID — e.g. CVE-2025-1234
• Severity — Critical, High, Medium, or Low
• Affected versions — the version range impacted
• Summary — a short description of the vulnerability
• Patched versions — the version(s) that fix the issue (if available)
• Advisory URL — link to the full advisory

Notification Configuration

DepAegis can notify your team when vulnerabilities are detected. Configure notifications under Organization → Settings → Notifications.

Webhook Notifications

{
  "event": "vulnerability.found",
  "package": "@myorg/ui-components",
  "version": "1.2.3",
  "cve": "CVE-2025-1234",
  "severity": "Critical",
  "action": "quarantined"
}

Email Notifications

Enable email alerts for Critical and High severity findings. Recipients are configurable per organization. Emails include the CVE ID, severity, affected package, and a direct link to the scan report.

Manual Re-scan

The vulnerability landscape changes constantly. To re-scan a package version against the latest databases:

1. Navigate to the package version in the dashboard.
2. Click Security → Re-scan.
3. The scan runs against the current OSV and NVD snapshots.

You can also trigger a re-scan programmatically:

curl -X POST \
  -H "Authorization: Bearer $DEPAEGIS_TOKEN" \
  "https://app.depaegis.com/api/v1/packages/@myorg%2Fui-components/versions/1.2.3/rescan"

SBOM-Based Scanning for Transitive Dependencies

DepAegis uses the generated SBOM to scan not just the direct package, but its full transitive dependency tree. This means vulnerabilities in deeply nested dependencies are caught even when they are not declared directly.

The SBOM lists every component with its name, version, and hash. DepAegis resolves each component against the vulnerability databases and reports findings per-component with a clear dependency path.

False Positive Handling

Not every CVE match is a real threat. DepAegis provides tools to assess and dismiss false positives:

• Context review — check if the vulnerable code path is actually reachable in your usage.
• Version-specific analysis — some CVEs apply only to specific build configurations or platforms.
• Dismiss with reason — mark a finding as a false positive with an explanation and expiry date.

# Dismiss a false positive via the API
curl -X POST \
  -H "Authorization: Bearer $DEPAEGIS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Vulnerable code path not reachable", "expiresAt": "2026-12-31"}' \
  "https://app.depaegis.com/api/v1/vulnerabilities/CVE-2025-1234/dismiss"

Ignoring Specific CVEs

For CVEs that have been assessed and accepted, you can create ignore rules at the organization or package level:

# Ignore a CVE for a specific package
curl -X PUT \
  -H "Authorization: Bearer $DEPAEGIS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"cve": "CVE-2025-5678", "scope": "package", "package": "@myorg/legacy-lib", "reason": "Legacy package, migration planned Q3 2026"}' \
  "https://app.depaegis.com/api/v1/organizations/myorg/ignore-rules"

Ignored CVEs do not trigger quarantine or notifications. They are still listed in scan reports with an Ignored badge and the provided reason.