---
name: vulnerability-management
description: Coordinate vulnerability triage and recurring patch work across scanners,
  dependencies, base images, and infrastructure through deadline tracking, production
  rollout, and verified closure.
metadata:
  scope: generic
  invocation: both
  version: '2.0'
  role: task
---

# Vulnerability management

Track remediation to the deployed artifact, not just a merged dependency update.

## Execution modes and standards

In interactive work, explain prioritized risks and resolve remediation tradeoffs. For setup establish asset/software inventory, scanner coverage, ownership, patch policy and automation. During feature work assess introduced dependencies, base images, runtimes and infrastructure. In recurring runs reconcile current findings with previous records, prioritize exploitation/exposure, prepare compatible patches, and retain original deadlines. Execute rollout/status/risk mutations only within the job's explicit authority; never auto-accept risk to clear a dashboard.

Consult [references/patch-management.md](references/patch-management.md) for NIST-grounded preventive patch management and scanner-agnostic verification for deeper implementation details when needed.

## Scope and policy

Discover application/infrastructure ownership, deployed versions, scanners, dependency update automation, supported release lines, and applicable remediation policy. Obtain severity/exposure deadlines and exception authority locally; do not import another project's deadline table.

Use available scanner/API/CLI exports. Record data timestamp, scanned revision, and pagination/coverage limits. A stale development scan does not establish production risk.

## Triage

1. Aggregate relevant SCA, code, container, infrastructure, and manually reported findings. Keep routine version updates distinguishable from vulnerability fixes.
2. Deduplicate the same component/version/vulnerability while preserving every affected service and deployed environment.
3. Assign an accountable owner. Record first discovery, exposure, severity, affected deployed artifacts, deadline source, fix availability, and evidence.
4. Prioritize using applicable policy plus exploitation evidence (including CISA KEV), reachability, exposure, privileges, compensating controls and business impact. Severity alone is insufficient. Low visibility or a failed scan is not evidence of no risk.
5. Preserve the original deadline when work rolls into the next cycle or ticket.

Consult [references/remediation-record.md](references/remediation-record.md) for tracking and closure criteria for deeper implementation details when needed.

## Select and validate a fix

- Verify the target version exists under the correct package/artifact coordinates and is suitable for the supported release line.
- Review official release notes across the version range, breaking changes, configuration changes, and required migrations.
- Prefer a compatible curated parent/BOM/platform update when it resolves the affected dependency family. Assess its actual scope before choosing it.
- Use surgical overrides when necessary; record why, finding reference, current managed version, and a condition for removal.
- Group tightly coupled versions in one coherent change; keep independent changes independently reviewable/revertible.
- Treat major updates and failed CI as investigation work, not automatic merges. A retry is useful for a suspected transient failure, not a substitute for examining repeat failures.

## Deliver and close the loop

Build/test the changed resolved dependency set and scan the resulting artifact. Release through the project's patch/hotfix process before the deadline, using `delivery-pipelines` for execution and verification.

Confirm the fixed artifact/configuration is deployed to every affected target and rescan or obtain equivalent scanner evidence for that identity. Distinguish source-fixed, artifact-verified, deployed, and closed.

On every parent/platform update, remove redundant overrides only when tests and scans show the finding stays resolved. A passing build alone is insufficient.

## No fix or missed deadline

Record vendor status, workarounds, mitigation evidence, owner, review date, and applicable risk/exception process. Escalate deadlines that cannot be met. Do not mark a finding not affected or accepted solely to clear a dashboard; provide evidence and follow local authority requirements.

Keep unresolved findings visible across cycles without resetting their age. Scanner/tool errors are unknowns, not “no fix available.”

## Deliver

Report prioritized findings, remediation groups, migration/testing evidence, deployment state, overdue/blocked work, and residual risk with owners. Use the selected scanner's current API/export semantics; no specific product or MCP server is required.