How to Fix a CVE Vulnerability

Read the CVE record and vendor advisory to learn the affected product, version ranges, and conditions. Use your software bill of materials, dependency lock files, container image scans, and asset inventory to find where that component runs. Include transitive dependencies, which are often where vulnerable libraries hide.

Scanners match versions; they cannot always tell whether the vulnerable code path is used or reachable. Check whether the affected feature is enabled, whether the service is internet-facing, and whether attackers could reach the vulnerable function. Document why a finding is or is not exploitable in your environment.

Combine severity, such as the CVSS score, with exploitation evidence, such as inclusion in CISA's Known Exploited Vulnerabilities catalogue or public exploit reports, and with your exposure. An actively exploited, internet-facing issue outranks a higher-scored bug in an isolated internal tool. Some teams also use exploit prediction scores.

Upgrade the affected component to a fixed version. For libraries, update the dependency and any parent dependencies that pin it. For operating system packages, apply vendor updates. For container images, rebuild from an updated base image. Prefer the smallest upgrade that includes the fix to reduce regression risk, then plan larger upgrades separately.

If a fixed version is not available or cannot be deployed quickly, apply vendor mitigations: disable the vulnerable feature, restrict network access, add web application firewall rules, or change configuration. Record the mitigation, its owner, and a deadline to patch, because mitigations are easy to forget.

Run tests to catch regressions from the upgrade. Deploy through your normal change process, with expedited paths for critical, actively exploited issues. Communicate with stakeholders if downtime or behaviour changes are expected.

Rescan the deployed artefact, not just the source repository, to confirm the vulnerable version is gone. Check every environment and every service that used the component. Stale images in registries and long-running instances are common places where old versions survive.

Update the ticket with the fixed version, deployment date, verification evidence, and any accepted residual risk. Consistent records make audits easier and stop the same finding from being reopened by the next scan.

Scanners sometimes flag components that are not present, backported fixes in distribution packages, or code paths that are unreachable. Document these with evidence and use your scanner's suppression or exception features, with expiry dates, so they are reviewed rather than ignored forever.

Exploitation of high-profile vulnerabilities can begin within hours or days of disclosure. Define response targets by risk level, rehearse the fast path, and keep dependency upgrades routine so emergency patches are not your first upgrade in years.

An SBOM lists the components inside each build. With SBOMs stored for every release, answering are we affected becomes a query rather than an investigation. Generate them in CI, store them alongside artefacts, and keep them current.

For high-profile vulnerabilities, customers and leadership will ask whether you are affected before you finish investigating. Prepare a short status: affected or not, evidence, actions taken, and timeline. Update it as facts change, and avoid speculating.

Critical, actively exploited vulnerabilities often deserve incident handling: an owner, a timeline, a communication cadence, and a record of actions. Treating them as ordinary backlog items slows response when speed matters most.

Many CVEs live in base images rather than application code. Use minimal base images, rebuild images regularly even without code changes, pin image digests, and remove unused packages. Image scanning in CI catches vulnerable layers before deployment.

Write down how quickly each risk tier must be fixed, who can approve exceptions, and how long exceptions last. Clear, published targets turn vulnerability work from negotiation into routine.

After a significant vulnerability response, review how long each step took: discovery, confirmation, patching, deployment, and verification. The slowest step is where tooling or process investment will pay off most the next time.

Dependency update bots that open small, regular upgrade pull requests keep components current, so emergency fixes are minor version bumps rather than risky leaps.