Skip to content

vulnerability-management.md

Latest commit

 

History

History
129 lines (96 loc) · 9.67 KB

vulnerability-management.md

File metadata and controls

129 lines (96 loc) · 9.67 KB
name vulnerability-management
description Use when deployed or release-bound vulnerabilities need exploitability triage, patch SLAs, rollout, or exceptions

Vulnerability Management And Patch SLA

Iron Law

NO VULNERABILITY ACCEPTANCE WITHOUT EXPOSURE ANALYSIS, DEADLINE, MITIGATION, AND VERIFICATION

If a vulnerable artifact remains deployed, the reason and recheck date must be explicit.

Overview

Vulnerability management is exposure reduction with deadlines, rollout safety, and verification. Compensating-control vocabulary follows the shared compensating-control format; exception lifecycle follows the shared risk-register format and risk-acceptance lifecycle.

Core principle: prioritize by exploitability, exposure, reachability, asset criticality, and compensating controls per the shared compensating-control format, not by severity score alone.

When To Use

  • The user is deciding vulnerability/advisory triage, patch SLAs, exploitability signals, remediation exceptions, time-to-fix, rollout, or live-fix verification for deployed or release-bound code.
  • A vulnerable artifact is deployed or about to be promoted and needs exposure, exploitability, exception, patch-order, or verification decisions.
  • A scanner finds a vulnerability in a deployed service, image, dependency, runtime, or infrastructure component.
  • You need risk-based prioritization or exception rules.
  • A vulnerability fix needs rollout and verification results.

When Not To Use

  • The work is routine dependency updates with no urgent deployed risk; use dependency-and-code-hygiene instead.
  • The main gap is build provenance, dependency inventory, or artifact trust; use software-supply-chain-security instead.
  • The question is secure design of a new feature; use secure-sdlc-and-threat-modeling instead.
  • The request is legal disclosure strategy; out of scope unless framed as engineering remediation details.

Info To Gather

  • Vulnerability or advisory ID, affected package/component, fixed versions, exploit status, exploitability signals, severity, and advisory details.
  • Deployed assets, versions, exposure, network reachability, privileges, data access, and asset criticality.
  • Runtime reachability, feature usage, compensating controls per the shared compensating-control format, tenant/customer impact, and exploit preconditions.
  • Patch path, test coverage, rollout plan, rollback risk, maintenance window, and user decision deadline.
  • Existing exceptions, business constraints, and verification method.

Workflow

  1. Identify deployed exposure. Determine whether the vulnerable component is present, inventoried, reachable, exploitable, and customer-impacting in production.
  2. Prioritize by risk. Combine known exploitation (authoritative known-exploited-vulnerability catalogs), exploit-probability scores, external exposure, runtime reachability, privilege, sensitive data, asset criticality, and compensating controls. Active exploitation or externally reachable sensitive paths override nominal severity score.
  3. Use a default SLA ladder. Emergency means active exploitation or externally reachable critical path: mitigate immediately and patch inside days. High means reachable production path with sensitive data, privilege, or high-impact service: patch inside one to two weeks. Medium means reachable internal or bounded path: patch in the next planned release window. Low means not reachable or strongly compensated: track with expiry and recheck.
  4. Set deadline and SLA. Set remediation deadline based on risk class and active exploitation, not severity score alone.
  5. Choose remediation. Patch, upgrade, remove, disable feature, isolate, constrain inputs, or add compensating controls until patch is safe.
  6. Handle no-patch cases. When no fix exists, define workaround, isolation, feature disablement, input filtering, monitoring, and next recheck trigger.
  7. Roll out safely. Use tests, canary, rollback, and compatibility checks for risky base/runtime/dependency changes.
  8. Verify fixed state. Check that the vulnerable artifact is no longer deployed or the exploit path is mitigated.
  9. Record exceptions. Use expiry, compensating control, recheck trigger, and residual risk using the shared risk-register, risk-acceptance, and compensating-control formats.
  10. Feed upstream gaps. Missing inventory/provenance goes to supply-chain security; routine update backlog goes to dependency hygiene.

Synthesized Default

Use risk-based triage with exploitation signals, exposure, reachability, privilege, asset criticality, sensitive data, dependency inventory, and compensating controls per the shared compensating-control format. Patch active exploitation and internet-exposed critical paths aggressively, then verify deployed fixed state.

Phase Behavior

  • Ideation: identify risks, defaults, unknowns, options, and the next decision before code exists.
  • Design: shape the target artifact, tradeoffs, checks, and details to gather.
  • Development: guide sequencing, code boundaries, checks, and acceptance criteria.
  • Testing: define release-blocking tests, evals, fixtures, and failure probes.
  • Release: define rollout, observability, abort, rollback, and readiness details.
  • Maintenance: define owners, drift checks, cleanup triggers, and refresh cadence.
  • Existing artifact: use current code, docs, telemetry, incidents, or diffs as context for the next engineering decision; do not wait for a finished artifact before guiding design, build, release, or operation.
  • Missing details: state assumptions and say what to check next instead of blocking lifecycle guidance.

Exceptions

  • Active exploitation can justify emergency rollout outside normal cadence if mitigation risk is lower than exposure risk.
  • Non-reachable vulnerable code may receive lower priority, but reachability details must be documented.
  • Patches with high regression risk may require compensating controls and staged rollout before full remediation.
  • Upstream-unfixed vulnerabilities need mitigation, monitoring, expiry, and recheck cadence; do not wait on an upstream fix when a local compensating control per the shared compensating-control format is available.

Response Quality Bar

  • Lead with the triage decision, patch SLA, remediation plan, exception, or verification gap requested.
  • Cover exposure, reachability, exploitation signals, asset criticality, sensitive data, compensating controls per the shared compensating-control format, rollout risk, SLA, and fixed-state verification before optional vulnerability topics.
  • Make recommendations actionable with deadlines, fallback paths, deploy batches, rollback plans, mitigation steps, and recheck cadence where relevant.
  • Name the details to inspect, such as affected assets, deployed artifact versions, scanner findings, exploitability signals, reachability checks, exploit status, patch availability, and production verification; do not state details you have not seen.
  • Stay technology-agnostic by default: do not introduce provider, product, framework, database, protocol, or command names unless the user supplied them or explicitly requested tool-specific guidance.
  • Stay inside vulnerability remediation. Route routine dependency hygiene or supply-chain provenance only when those are the central unresolved risk.
  • Be concise: avoid generic severity-score explanations and prefer compact triage and remediation tables.

Required Outputs

  • Output shape: render the matching shared template headings or tables in the reply, or use the same shape.
  • Vulnerability triage table.
  • Exposure and reachability assessment.
  • Patch SLA, deadline, and risk class.
  • Risk decision record showing exploitation, exposure, reachability, privilege, sensitive data, asset criticality, and compensating controls using the shared risk-register and compensating-control formats.
  • Remediation and rollout plan.
  • Exception record when remediation cannot meet SLA.
  • Verification details that vulnerable deployed state is removed or mitigated.
  • Metrics for aging, SLA breach, and time to fix, with the start event defined as detection in deployed scope or fix availability when no fix existed at detection time.

Checks Before Moving On

  • exposure_check: affected deployed assets, reachability, privilege, and data sensitivity are assessed.
  • risk_classification: exploitability, exposure, asset criticality, and compensating controls per the shared compensating-control format are considered.
  • remediation_sla: every remediation has deadline, and fallback path.
  • rollout_check: risky fixes have test, rollout, and rollback plan.
  • verification_check: fixed or mitigated production state is verified.

Red Flags - Stop And Rework

  • Severity score alone determines urgency.
  • Vulnerabilities are marked accepted with no expiry or compensating control under the shared risk-acceptance lifecycle and compensating-control format.
  • Scanner "fixed" status is trusted without verifying deployed artifacts.
  • Patch rollout risk is ignored for critical services.
  • Missing inventory prevents triage and is not surfaced as a blocker.
  • No-patch vulnerabilities sit idle without workaround, monitoring, and recheck date.

Common Mistakes

Mistake Correction
Treating all highs alike Prioritize by exploitation, exposure, reachability, and asset criticality.
Prioritizing by severity score alone Combine known-exploited catalogs and exploit-probability scoring with reachability and exposure.
Closing tickets on merge Verify the fixed artifact is deployed or mitigated.
Exception sprawl Require expiry, compensating control, and recheck using the shared risk-register and compensating-control formats.
Ignoring rollout risk Use safe-change practices for risky patches.