Practical Guidance for Prioritizing and Remediating Vulnerabilities
Summary
The guide explains how to prioritize and fix vulnerabilities across code, dependencies, containers, cloud and secrets, with advice on backports, retesting and remediation workflows. It cites the 2026 DBIR's 31% exploitation figure and a 43-day median KEV patch time.
Key points
- The guide cites the 2026 Verizon DBIR finding that vulnerability exploitation accounted for 31% of breaches, and says only 26% of vulnerabilities on CISA's KEV catalog were fully remediated in 2025, with a 43-day median patch time.
- Prioritize findings by exploitability and exposure, set remediation deadlines by risk, and keep scanning dependencies because new vulnerabilities can affect unchanged versions.
- For dependencies that cannot be upgraded safely, consider backporting the fix or using a maintained patched build; major-version changes and transitive dependencies can complicate remediation.
- Fix cloud misconfigurations in infrastructure-as-code templates where possible, and bring console-only changes back under code review to prevent drift.
- For exposed secrets, rotate the credential and check access logs; deleting it from the current code does not remove it from Git history.
- The guide recommends rerunning the relevant checks against the fixed version and verifying deployed applications before closing findings.
- As a layered-defense example, the article says enforcing IMDSv2 would likely have blocked credential theft in the described MLflow SSRF scenario, while restrictive IAM roles could limit access.
Article Details
- Defense Focus
- Find, prioritize, remediate, and verify vulnerabilities across application code, open-source dependencies, container images, infrastructure as code, live cloud configuration, and secrets.
- Detection Methods
- Run deterministic SAST on commits to identify recognizable code patterns associated with vulnerabilities.
- Use AI code review or application testing to identify logic flaws; probe running applications to test whether a flaw is exploitable.
- Analyze lockfiles and dependency trees against vulnerability data, and assess whether vulnerable functions are reachable from application code.
- Scan container images for vulnerable operating-system packages.
- Run IaC checks in CI/CD and surface findings in pull requests before deployment.
- Use CSPM to inspect live cloud accounts for configuration changes not represented in IaC.
- Scan new commits, Git history, and container images for exposed secrets.
- Re-run the relevant checks against fixed code or the deployed application before closing a finding.
- Data Sources
- Source code and commits
- Lockfiles, dependency trees, and package versions
- Public CVE databases and vulnerability threat-intelligence feeds
- Container images and their operating-system packages
- Terraform and CloudFormation templates, Helm charts, and Kubernetes manifests
- Live cloud account configuration
- Git history and access logs
- Running application behavior and deployed versions
- Rule Types
- Pattern-based SAST rules
- Software composition analysis checks
- Container vulnerability checks
- Infrastructure-as-code checks
- Cloud security posture checks
- Secrets detection checks
- Platforms
- CI/CD pipelines
- Developer IDEs and pull request workflows
- Live cloud accounts
- Running application environments
- Defensive Actions
- Prioritize findings by exploitability and exposure, and set remediation deadlines appropriate to each risk tier.
- Upgrade vulnerable dependencies when practical; consider backporting fixes when upgrades are blocked by breaking changes or unavailable releases.
- Remove unused packages from container images and rebuild and redeploy images to apply fixes.
- Enforce IMDSv2 to reduce the risk of SSRF-based access to cloud instance credentials, and review IAM roles for excessive permissions.
- Fix cloud misconfigurations in IaC and bring manually created resources under IaC management to prevent configuration drift.
- Rotate exposed credentials and review access logs for use of the old credentials.
- Re-test fixes, including in the deployed environment, before closing findings.
- Surface findings in developer workflows and automate low-risk changes that do not alter application behavior.
MITRE ATT&CK
CVE
CVE-2026-48937CVE-2026-48937 in Node.js shows how this plays out. The fix shipped alongside a semver-major update to nghttp2 that removed HTTP/2 priority signaling entirely, because the vulnerable behavior and the removed featureCVE-2026-64849Some of the most serious findings span layers, and the MLflow SSRF flaw (CVE-2026-64849) shows how. Within hours of it being assigned a CVE in August 2026, attackers were exploiting it to make MLflow servers ask the
Vendors
Aikidothough you then own that fork, or use a patched build from a vendor that maintains backports, which Aikido Security offers for open-source packages and container images. You can close the CVE and upgrade when yourAmazon Web ServicesAn EC2 instance still using IMDSv1, the older version of AWS's metadata service that SSRF attacks rely on to steal credentials
Products
Aikido Imagesthe CVE closes without a version bump or an API change, even when no patched release exists upstream. Aikido Images does the same at the container layer, with 2,000+ drop-in replacement images that clear high andAikido Intelbeing assigned, which is why some SCA tools, Aikido's included, draw on threat intelligence feeds like Aikido Intel.Aikido Librariesfindings, AutoFix writes the change itself. For dependencies and containers, the fix is a backport. Aikido Libraries produces patched builds of the package versions you already run across npm, PyPI, Maven, and Go, soAutofixFixes arrive as AutoFix pull requests. For code and IaC findings, AutoFix writes the change itself. For dependencies and containers, the fix is a backport. Aikido Libraries produces patched builds of the packageAutoShipstill has to be tested and deployed before the vulnerability is actually gone, and that's the step AutoShip handles. Add a label to an AutoFix pull request and AutoShip carries it from CI through staging toCVE Exploitability Analysiswhich clears out CVEs in packages you pull in but never exercise. What's left goes to CVE Exploitability Analysis, an agent that reasons about how your code actually uses the package and then acts on eachMLflowSome of the most serious findings span layers, and the MLflow SSRF flaw (CVE-2026-64849) shows how. Within hours of it being assigned a CVE in August 2026, attackers were exploiting it to make MLflow servers ask theNode.jsCVE-2026-48937 in Node.js shows how this plays out. The fix shipped alongside a semver-major update to nghttp2 that removed HTTP/2 priority signaling entirely, because the vulnerable behavior and the removed feature