Fixing findings: patches and fix pull requests

DVSentry helps you fix vulnerable dependencies in three ways, from least to most access:

All three cover npm and pip dependencies only, and only a change DVSentry can prove is safe to make mechanically.

#Version-bump patch (download)

1. Open a repository report, open an npm or pip dependency finding and choose Remediation guidance.
2. Under Version-bump patch, choose Prepare patch. The panel shows the current step and the seconds elapsed (the checkout of a large repository takes a minute or two), then a download link or the reason no patch is offered. For a transitive npm package it names the direct packages that pull it in, so you know which one to upgrade or where to add an overrides entry.
3. Download the patch within one hour. Its header names the repository, the exact commit it applies to, the package, the two versions and the advisories.

Apply it:

git checkout -b fix/lodash-4.17.21 <the commit named in the patch header>
git apply -p1 dvsentry-fix-lodash.patch
npm ci && npm test                       # or: pip install --require-hashes -r requirements.txt && pytest
git commit -am "Bump lodash to 4.17.21 (DVSentry fix patch)"

What is offered:

• npm: a direct dependency declared as exact, ^ or ~ in package.json, with package-lock.json v2 or v3. The prefix is kept (^4.17.15 becomes ^4.17.21); in the lockfile only that package's version, resolved and integrity change.
• pip: one name==version pin in a requirements file; --hash lines are replaced by the new version's hashes.
• The target is the lowest fixed, non-pre-release version newer than the installed one, staying in the same major version when the advisory names one there.

Never offered, with the reason shown: transitive packages; workspace (monorepo) manifests; packages not from the public registry (a private package name is never sent to a public registry); requirements files with custom indexes, includes, editable or URL requirements; a new version that changes the dependency tree or install scripts; yanked, pre-release-only or downgrade versions; files changed since the scan (rescan first); symlinks or oversized files.

Limits: 20 patch requests per organization per day (DEPENDENCY_FIX_DAILY_LIMIT). The request needs a signed-in browser session (no API token) and the Member role. Private repositories are cloned with the GitHub App, or with a Secret Vault github_pat entry you pick in the panel.

How it stays safe: the patch is generated in an isolated container with no network, then DVSentry re-parses it strictly, rebuilds it from the parsed hunks, and applies it to the exact files it hashed before offering it. The patch is encrypted at rest and deleted after an hour.

#Fix pull requests (Phase 2)

Not verified live. The feature is built and tested against GitHub fakes, but the DVSentry Fix App on GitHub is not set up yet, so it is not available during the beta. Every repository report still shows the panel, with its buttons disabled and the exact reason ("Fix App not set up", "repository not opted in", "Admin only").

Once set up:

1. Install the Fix App (Admin, browser session): a second GitHub App, separate from the scan App, with Contents and Pull requests read/write. It is never used for scans.
2. Opt a repository in (Admin): accept the fix pull requests authorization, prove you are a repository admin (GitHub is asked twice), and make sure the default branch is protected (an unprotected one is refused).
3. Commit the opt-in file DVSentry shows you to the default branch, then choose Check again:

   # .github/dvsentry-fix.yml
   version: 1
   organization: 6b0d1c9e-0000-0000-0000-000000000000
   opt_in: 1f2e3d4c-0000-0000-0000-000000000000

   The repository's own file is the real authorization: remove it and DVSentry stops.
4. On a dependency finding choose Raise PR. DVSentry's separate fix-publisher service (no database, signed one-time grants) creates branch dvsentry-fix/<package>-<version>-<12 hex> and one pull request. It never merges, never pushes to an existing branch, never writes under .github/, and only picks versions released at least 3 days ago (FIX_PULL_REQUESTS_MIN_RELEASE_AGE_DAYS).

The scan App's webhook records when the pull request is closed, merged or reopened. Revoking the opt-in, the Fix App or the scan App link stops any further write.

#Fix bundles: many fixes in one pull request

Not verified live. On a repository report, an Admin opens Fix several findings in one pull request:

1. Find fixable findings: the npm/pip findings DVSentry can fix, one per package, most severe first (up to 25).
2. Pick some and choose Prepare fixes. DVSentry clones once, prepares each fix and applies them in order; a fix that no longer applies on top of the others is left out and named.
3. Raise pull request shows the exact title and description (facts only: packages, versions, severities, advisory ids, files). Confirm and raise binds its SHA-256; the publisher refuses any difference. An unconfirmed bundle expires after 24 hours.
4. The publisher creates branch dvsentry-fix/bundle-<12 hex> with one commit per fix and a pull request on your fork. Bundles work only from a fork in a personal GitHub account. The panel then links GitHub's compare page so you can submit it to the upstream project yourself; DVSentry holds no access to the upstream.

#AI remediation

For findings that are not dependency bumps, the AI remediation plan on the report's AI Remediation tab gives step-by-step guidance (Reports and findings). It never changes code.

Something missing or unclear? Tell us with Feedback in the app.