Skip to content

Dependency Vulnerability Management

Waldur uses automated dependency vulnerability scanning across all repositories to detect known CVEs in third-party packages. This approach is informed by the ENISA Technical Advisory for Secure Use of Package Managers (March 2026).

How it works

Every CI pipeline runs osv-scanner against the repository's lock file (uv.lock for Python, yarn.lock for JavaScript). The scanner checks all direct and transitive dependencies against the OSV.dev vulnerability database, which aggregates data from GitHub Advisories, PyPI, npm, NVD, and other sources.

The shared CI template lives in waldur-pipelines at /templates/test/vulnerability-scan.yml and is included by each repository.

Scanning scope

Repository Lock file Ecosystem
waldur-mastermind uv.lock PyPI
waldur-homeport yarn.lock npm
waldur-site-agent uv.lock PyPI
waldur-docs uv.lock PyPI

When scans run

  • On every merge request pipeline
  • On every push to the default branch (develop, main, or master)
  • On every tagged release

Interpreting results

The scan job is configured with allow_failure: true, meaning it reports findings without blocking the pipeline. Vulnerabilities appear as an orange warning icon on the scan job in GitLab CI.

The scanner outputs a table with:

  • OSV URL — link to the vulnerability details
  • CVSS — severity score (0-10)
  • Package — affected package name
  • Version — currently installed version
  • Fixed version — minimum version that resolves the issue

Note

Not all reported vulnerabilities are exploitable. A vulnerability in a transitive dependency may not be reachable from Waldur's code. Triage before acting — check whether the affected function is actually used.

Fixing vulnerabilities

Python repositories (uv)

1
2
3
4
5
# Upgrade a specific package
uv lock --upgrade-package <package-name>

# Verify the lock file is consistent
uv lock --check

If pyproject.toml has a version constraint that blocks the upgrade, update the constraint first, then re-lock.

JavaScript repositories (yarn)

1
2
3
4
5
6
7
8
# Upgrade a direct dependency
yarn upgrade <package-name>@<fixed-version>

# For transitive-only dependencies, add a resolution
# in package.json to force a specific version:
"resolutions": {
  "<package-name>": ">=<fixed-version>"
}

After adding resolutions, run yarn install to update yarn.lock.

Suppressing false positives

If a reported vulnerability is not applicable (e.g., the affected function is not reachable, or the package is only used in tests), add a suppression to .osv-scanner.toml in the repository root:

1
2
3
4
[[IgnoredVulns]]
id = "GHSA-xxxx-xxxx-xxxx"
reason = "Function is not reachable — we only use the parsing module"
ignoreUntil = "2026-10-01"  # Re-evaluate after this date

Warning

Always set an ignoreUntil date so suppressions are periodically re-evaluated. Do not suppress vulnerabilities indefinitely.

Triage process

When the scan finds new vulnerabilities:

  1. Assess severity — focus on High and Critical (CVSS >= 7.0) first.
  2. Check reachability — is the vulnerable function actually called in Waldur? Use grep or code search to determine if the affected module/function is imported.
  3. Check fix availability — if a fixed version exists, upgrade. If not, evaluate workarounds or suppress with justification.
  4. Prioritize production dependencies — vulnerabilities in dev-only or test-only dependencies are lower priority.
  5. Create a fix — upgrade the package and verify tests pass. For breaking changes (e.g., major version bumps), create a dedicated MR.
  6. Document exceptions — if a vulnerability cannot be fixed immediately, add it to .osv-scanner.toml with a clear reason and re-evaluation date.

Lock file hygiene

Lock files are the foundation of reproducible and secure builds:

  • Always commit lock files — uv.lock, yarn.lock, and package-lock.json must be in version control.
  • Enforce frozen installs in CI — uv sync --frozen and yarn install --frozen-lockfile ensure CI uses exactly what was committed.
  • Review lock file changes in MRs — unexpected dependency additions or version changes in lock files may indicate supply chain issues.
  • Keep dependencies up to date — outdated dependencies accumulate vulnerabilities over time. Regularly run upgrades and review changelogs.

References