OpenParable
Skip to content
← Back to skills

Fix Cve

DevOps & Security
fix-cve

Fix Cve is an Agent Skill for devops & security published in the Giskard-AI/giskard-oss repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.

Use when pip-audit (or a CVE/GHSA advisory, Dependabot, or security scan) flags a vulnerable Python dependency in giskard-oss and it needs upgrading to a fixed version in the uv lockfile.

View on GitHub ↗
QUICK START

How to use this skill

Bring this guide into your coding agent with a prompt tailored to the tool you use.

  1. Open your project in Codex.
  2. Copy and paste the prompt below.
  3. Review files and risks before approving any action.
Prompt to paste
Inspect the Agent Skill at https://github.com/Giskard-AI/giskard-oss/blob/HEAD/.claude/skills/fix-cve/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/fix-cve, but wait for my approval before writing files or running scripts.

Copying this prompt does not install or run the skill. Review third-party files before use.

fix-cve

Remediate a vulnerable dependency flagged by pip-audit (or any CVE/GHSA advisory) by upgrading it in the uv lockfile, then verify with the repo gate.

pip-audit runs as part of make check (the security target). The advisory looks like:

Name    Version ID                  Fix Versions
------- ------- ------------------- ------------
msgpack 1.1.2   GHSA-6v7p-g79w-8964 1.2.1

You need: the package name and a fix version.

Procedure

# 1. Upgrade the package in the lockfile (works for direct AND transitive deps).
uv lock --upgrade-package <package>

# 2. Apply to the environment.
uv sync

# 3. Verify the advisory is gone — re-run the exact audit command.
uv run pip-audit --skip-editable

Then run the full repo gate (it re-runs pip-audit via the security target, plus format/lint/types/tests):

make format && make check && make test-unit

Or invoke /check (the project verification-gate skill).

Key facts

  • Always upgrade in the lockfile, not the environment. Use uv lock --upgrade-package <package>, NOT pip install / uv pip install. The lockfile is the source of truth; a pip install fix is lost on the next uv sync.
  • Transitive deps are fixed the same way. Most flagged packages (e.g. msgpack, pulled in by cachecontrol) are not in any pyproject.toml. You still upgrade them by name with uv lock --upgrade-package <package> — no pyproject.toml edit needed. Do NOT add a direct dependency just to pin it.
  • uv lock --upgrade-package <package> takes the newest version the constraints allow. Check the resulting uv.lock entry to confirm the version actually moved to the fix version — a cap may have held it below.

When a constraint caps the version below the fix

If another dependency caps the package below the fix version, the bare upgrade silently stays on the old version, and forcing it with uv lock --upgrade-package "<package>>=<fix-version>" fails with a resolution error (No solution found...) — uv constraints can only narrow the version set, never expand past a cap. Escalate in this order:

  1. Upgrade the capping parent. Find who imposes the cap (uv tree --invert --package <package>), then uv lock --upgrade-package <parent>. A newer parent often relaxes the cap. Preferred — keeps the dependency graph honest.
  2. Override the transitive dep if no parent upgrade resolves it. Add to pyproject.toml:
    [tool.uv]
    override-dependencies = ["<package>>=<fix-version>"]
    
    Overrides expand the allowed set (the only escape hatch a cap can't block), then re-run uv lock. Use sparingly — it ignores the parent's declared constraint, so re-verify nothing breaks with the full gate.
  • Lockfile-only changes have no "affected lib". Run the full make test-unit (all packages), not a single PACKAGE=<lib> scope — the dep could affect any lib.

Verifying the fix

Do not assert "fixed" — show evidence:

  1. uv run pip-audit --skip-editable prints "No known vulnerabilities found" (editable giskard-* libs in the skip list are expected and harmless).
  2. The uv.lock diff shows the package moved to the fix version (Updated <pkg> vX -> vY from uv lock).
  3. make check passes (its security target re-runs the audit).

Common mistakes

MistakeFix
pip install <pkg>==<ver> to fix itUse uv lock --upgrade-package <pkg>; pip changes don't persist in the lockfile
Editing pyproject.toml for a transitive depNot needed — uv lock --upgrade-package handles transitive deps by name
Skipping re-audit, assuming the upgrade workedRe-run uv run pip-audit --skip-editable; a constraint may have silently capped the version below the fix
Force-pinning past a cap with "<pkg>>=<fix>" and hitting No solution foundConstraints can't expand past a cap — upgrade the capping parent, or use [tool.uv] override-dependencies
Guessing the verification commandRun /check or make format && make check && make test-unit; make check includes pip-audit
Scoping tests to one PACKAGE=A lockfile change has no single affected lib; run all unit tests