# Cve Remediation

> Dependency vulnerability remediation workflow for this repository. Use when fixing CVE, BDSA, GHSA, OSV, npm, PyPI, Dependabot, Black Duck, Snyk, or other package vulnerability findings, especially when the user asks for minimal package-only updates, validation, commits, branches, or pull requests.

- Skill: `nvidia-ai-blueprints/cve-remediation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nvidia-ai-blueprints/cve-remediation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nvidia-ai-blueprints/cve-remediation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: NVIDIA-AI-Blueprints (https://skillmd.com/u/nvidia-ai-blueprints)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nvidia-ai-blueprints/cve-remediation

---


# CVE Remediation

Use this skill to remediate dependency vulnerabilities with minimal, evidence-backed package changes.

## Operating Rules

1. Read `AGENTS.md` and relevant repo Codex skills before editing.
2. Read scoped `AGENTS.md` and required docs for affected components, especially `src/apps_sdk/AGENTS.md` for Apps SDK widget work.
3. Start from `git status -sb`; do not mix remediation into an unrelated dirty worktree or stale branch.
4. Prefer package manifest and lockfile changes only. Do not change source code unless no compatible package-only fix exists.
5. Keep the affected-library scope tight. Do not opportunistically upgrade unrelated dependencies.
6. Never hand-edit generated lockfiles. Regenerate them with the package manager.

## Identify Scope

Map the finding to the owning workspace and package manager:

- Root backend: `pyproject.toml`, `uv.lock`
- Agents: `src/agents/pyproject.toml`, `src/agents/uv.lock`
- Demo UI: `src/ui/package.json`, `src/ui/pnpm-lock.yaml`
- Apps SDK widget: `src/apps_sdk/web/package.json`, `src/apps_sdk/web/pnpm-lock.yaml`

Use `rg`, `pnpm list`, `pnpm why`, `uv tree`, and lockfile searches to find all resolved copies of the vulnerable package.

## Verify Advisory Data

Treat scanner output as the starting signal, not the complete fix plan.

1. Verify affected and fixed versions using public or primary sources where possible:
   - OSV API
   - GitHub Security Advisories
   - npm or PyPI registry metadata
   - official release notes or changelogs
2. Query exact candidate versions before introducing them.
3. Do not assume "newest" is safe; newer versions can have different advisories or compatibility issues.
4. If BDSA or commercial scanner details are not public, say that explicitly and use public advisory plus registry evidence.
5. Avoid full `pnpm audit` or equivalent external audit uploads unless the user explicitly approves sharing the workspace dependency graph. Prefer per-package OSV queries for exact packages and versions.

Example OSV querybatch pattern:

```bash
curl -sS -X POST https://api.osv.dev/v1/querybatch \
  -H 'Content-Type: application/json' \
  -d '{"queries":[{"version":"VERSION","package":{"name":"PACKAGE","ecosystem":"npm"}}]}'
```

## Choose the Fix

1. Choose the smallest safe compatible version that clears the finding.
2. For direct dependencies, update the manifest range and regenerate the lockfile.
3. For transitive dependencies, prefer the parent package's compatible update when an override causes build or runtime failures.
4. Use overrides only when they are compatible, tested, and clearly scoped.
5. If a candidate fails validation, try the next safe package-only path and document why the failed candidate was rejected.
6. If no safe package-only path exists, stop and explain the tradeoff before changing source code.

## Apply Package Updates

For pnpm workspaces:

```bash
pnpm install --lockfile-only
pnpm install --frozen-lockfile
```

For uv workspaces:

```bash
uv lock --upgrade-package PACKAGE
```

Use the repo's existing dependency style: keep existing overrides, package managers, and version range conventions unless the advisory requires a different approach.

## Prove the Vulnerable Version Is Gone

After regenerating locks, verify both absence and final resolution:

```bash
rg -n 'VULNERABLE_VERSION|package@VULNERABLE_VERSION|package: VULNERABLE_VERSION' <changed package and lock files>
pnpm list PACKAGE --depth 10
pnpm why PACKAGE
uv tree | rg 'PACKAGE|VULNERABLE_VERSION'
```

For pnpm, remember `pnpm why` may return no output when a package is only an optional peer or no longer installed. Pair it with lockfile scans and `pnpm list`.

## Validate

Run affected CI parity checks. Broaden when shared tooling or lockfiles affect multiple areas.

Frontend UI (`src/ui`):

```bash
pnpm lint
pnpm format:check
pnpm typecheck
pnpm test:run
```

Apps SDK widget (`src/apps_sdk/web`):

```bash
pnpm lint
pnpm typecheck
pnpm test:run
pnpm build
```

Backend:

```bash
uv run ruff check src/merchant/ src/payment/ src/apps_sdk/ tests/
uv run ruff format --check src/merchant/ src/payment/ src/apps_sdk/ tests/
uv run pyright src/merchant/ src/payment/ src/apps_sdk/
uv run pytest tests/ -v --tb=short
```

Always run:

```bash
git diff --check
```

Browser or runtime verification is only required when runtime behavior, API behavior, UI behavior, or integration flow changes. Package-only build tool changes still need build and test evidence.

## Git and PR

1. Create or switch to a `codex/` branch based on current `origin/main` unless the user directs otherwise.
2. Stage only intended package manifests and lockfiles.
3. Commit with a dependency-focused message.
4. Push and open a PR when requested.
5. PR body must include:
   - summary of package changes
   - advisory/version evidence
   - exact tests and outcomes
   - any skipped checks and why
   - scanner identifier when available

Before final response, run `git status -sb` and report the branch, commit, PR URL, tests, and any residual warnings.