RepoWarden scans your repositories for outdated dependencies, runs security audits, checks for supply chain risks, and opens pull requests with tested updates -- all automatically.
RepoWarden scans run on a schedule -- weekly on the Free and Starter plans, daily on Pro and Business. You can also trigger a scan manually from your dashboard at any time.
Each scan follows a deterministic pipeline designed to maximize safety and minimize noise.
RepoWarden reads your repository tree and identifies dependency manifest files: package.json (JavaScript/TypeScript), Cargo.toml (Rust), requirements.txt / pyproject.toml / Pipfile (Python). It also detects your package manager from lock files and configuration (npm, pnpm, Yarn Classic, Yarn Berry, pip, Pipenv, Poetry, Cargo).
Each dependency is checked against its registry (npm, crates.io, PyPI) for newer versions. RepoWarden respects your semver constraints -- caret (^), tilde (~), and exact pins are all handled correctly. Pre-release and yanked versions are filtered out automatically.
A bulk security advisory check runs against every dependency. For JavaScript, this uses the npm advisory database. Dependencies with active CVEs are flagged and prioritized in the update PR. The advisory severity (critical, high, moderate, low) is included in the PR description.
Before including any package upgrade, RepoWarden checks for supply chain compromise indicators: recent maintainer changes, typosquatting against popular packages, suspicious install scripts, and abnormally low download counts. Risky packages are flagged and skipped.
Updates are applied and the project is built and tested in an isolated environment. If the build or tests fail, RepoWarden uses bisection to identify which specific update caused the failure. Failing updates are excluded from the PR and recorded in rollback memory so they are not retried.
A clean PR is opened on your repository with a detailed summary: which packages were updated, which have security advisories, a risk assessment, and links to changelogs. The PR triggers your CI pipeline as usual.
RepoWarden does not blindly update everything to the latest version. It respects the version constraints in your manifest files to avoid unexpected breaking changes.
| Prefix | Behavior | Example |
|---|---|---|
^ (caret) | Updates within the same major version | ^2.3.0 may update to 2.9.1 but not 3.0.0 |
~ (tilde) | Updates within the same minor version | ~2.3.0 may update to 2.3.9 but not 2.4.0 |
= (exact, Cargo) | Skipped entirely -- pinned versions are not updated | =1.0.0 stays at 1.0.0 |
No prefix / >= | Updates to the absolute latest stable version | 2.3.0 may update to 4.1.0 |
Workspace, link, file, path, and git references are always skipped.
Every scan includes a full security audit. RepoWarden checks all your dependencies against known vulnerability databases and prioritizes packages with active security advisories.
Dependencies are checked against the npm advisory database (for JavaScript) using the bulk advisory endpoint. Each advisory includes the severity level (critical, high, moderate, low) and a description of the vulnerability.
Security updates are always prioritized over regular updates. If a dependency has multiple advisories, the highest severity one is surfaced. Critical and high severity packages appear first in the PR description.
In addition to dependency update scans, RepoWarden runs dedicated security audits monthly. You receive a clear report of all known vulnerabilities with severity levels, even when no updates are needed.
RepoWarden detects your Node.js version from configuration files and flags end-of-life or maintenance LTS versions. You get specific upgrade recommendations with EOL dates.
Before upgrading any package, RepoWarden performs a series of safety checks to protect against supply chain attacks. Packages that fail these checks are automatically flagged and excluded from the update PR.
Flags packages where maintainership recently changed, which is a common vector for supply chain compromise.
Checks package names against popular packages to detect typosquatting attempts (e.g., lodahs instead of lodash).
Identifies packages with postinstall or preinstall scripts that could execute arbitrary code during installation.
Flags packages with abnormally low download counts relative to their age and scope, which can indicate a compromised or fake package.
When a batch of updates causes build or test failures, RepoWarden does not simply fail the entire scan. Instead, it uses bisection to identify exactly which update caused the problem.
How bisection works
All dependency updates are applied and the project is built and tested.
If the build fails, the updates are split into two halves and each half is tested independently.
This continues recursively until the specific failing update is identified.
The failing update is excluded from the PR and recorded in rollback memory.
The remaining safe updates are included in the PR as normal.
When a specific dependency version causes a build failure, RepoWarden records it in a per-repo rollback memory. That version is not retried on future scans until a newer version of the package is released. This prevents the same broken update from being proposed repeatedly.
When a dependency update breaks your CI, RepoWarden can automatically analyze the failure and push a fix. This works both during the initial scan and after the PR is opened.
If a build fails after applying updates, the AI reads the error output, identifies the cause (often a breaking API change in a new version), and generates a fix. Changelog information is used when available to understand what changed.
If CI fails on a PR that is already open, you can comment @repowarden fix-tests to trigger an AI analysis of the CI logs. RepoWarden reads the failure annotations, identifies the relevant source files, and pushes a fix commit.
All builds and tests run in isolated Docker containers with strict security controls. Your code never leaves the execution sandbox, and the sandbox is destroyed after each job.
Containers run with network access disabled. Code cannot make outbound requests, phone home, or exfiltrate data.
Dangerous environment variables (secrets, tokens, API keys) are automatically stripped before execution.
Each job runs in a fresh container that is destroyed after completion. Nothing persists between jobs.