Autoremediator
[!WARNING] Automated dependency remediation is a controversial practice. It can reduce exposure windows, but it can also introduce operational and supply-chain risk if used without policy controls. Autoremediator is designed for automation-first teams, and should be paired with explicit policy, CI safeguards, and repository protection rules.
Autoremediator is an automation-first Node.js CVE remediation platform.
It is built for teams that want dependency remediation to run as part of delivery infrastructure, not as ad hoc manual activity.
It supports direct CVE remediation, scanner-driven batch remediation, deterministic CI gating, and service/agent integrations (SDK, MCP, OpenAPI).
It also supports non-mutating remediation planning and run-correlation metadata for orchestration-first platforms.
See the documentation to get started.
Why Teams Use It
- Continuous remediation in CI and scheduled GitHub workflows
- Scanner-to-fix pipelines from npm audit, yarn audit, and SARIF inputs
- Policy-aware upgrade behavior for controlled automation at scale
- Structured evidence and summary outputs for security operations
- Multiple integration surfaces for platform engineering and automation agents
How It Works
Autoremediator follows a deterministic remediation flow:
- lookup CVE intelligence
- inspect installed dependency inventory
- match vulnerable installed versions
- attempt safe version bump
- if no safe bump exists, attempt controlled patch fallback
Safety gates are applied throughout the flow, including policy enforcement, dry-run controls, and validation requirements.
Trust and Advisory Sources
Autoremediator is built around verifiable vulnerability intelligence from public advisory sources.
Primary sources used by the remediation pipeline:
- OSV: ecosystem-first vulnerability records and affected/fixed range data
- GitHub Advisory Database: package advisories with ecosystem metadata
- NVD: NIST-backed CVE reference data and severity context
Supplemental enrichment and prioritization sources:
- CISA KEV: known exploited vulnerability signal
- FIRST EPSS: exploit probability and percentile scoring
- CVE Services: additional CVE record references and descriptions
- GitLab Advisory Database: supplemental advisory matching and references
- CERT/CC Vulnerability Notes: additional analyst context for selected CVEs
- deps.dev: package metadata coverage checks
- OpenSSF Scorecard: package trust and repository security posture signals
- Optional vendor and commercial feeds via environment-configured connectors
Trust model principles:
- use multiple sources for CVE enrichment and correlation
- preserve evidence output so remediation decisions can be audited
- apply policy and validation gates before marking outcomes resolved
- treat unresolved or low-confidence outcomes as explicit escalation paths
Primary Use Cases
- GitHub workflow automation: nightly or hourly remediation runs that open PRs automatically
- CI enforcement: fail builds when unresolved vulnerabilities remain after remediation attempts
- Security operations acceleration: convert scanner outputs into actionable remediation changes
- Platform integration: embed remediation in internal bots and security assistants via SDK, MCP, or OpenAPI
- Portfolio remediation: standardize CVE handling across many Node.js services
Security and Automation Principles
- keep automation policy-driven (
.autoremediator.json) - use dry-run first in new repositories
- retain summaries/evidence for audit trails
- require review and branch protection for remediation PRs
- treat unresolved outcomes as escalation inputs
Surfaces
- CLI for workflow jobs and CI runs
- SDK for custom automation programs (
remediate,planRemediation,remediateFromScan) - MCP for AI tooling ecosystems
- OpenAPI for service-based integration
Public API naming canon: runTests, policy, evidence, patchCount, and patchesDir.
Documentation
- Docs Home
- Getting Started: setup, first runs, and result interpretation
- CLI Reference: command modes, option semantics, and CI behavior
- Scanner Inputs: scanner format support and parsing constraints
- Policy and Safety: policy precedence, safety guarantees, and fallback controls
- API and SDK: programmatic integration and CI summary utilities
- Integrations: GitHub Actions, MCP, OpenAPI, and multi-stage automation patterns
- Contributor Guide: architecture and contribution standards
Product Direction
- Prioritize automation workflows over one-off manual runs
- Configure policy and branch protection before broad rollout
- Use CI summaries and evidence outputs for operational governance
Project References
License
MIT