Job dependency-vulnerability-updates-for-one-repository · revised 11 October 2026
Clear the fixable dependency vulnerability findings in one repository
Findings from one named scanner that a patch or minor update fixes are cleared in a tested pull request; the rest are listed with the decision each needs. A scanner check, not a security audit.
You might be seeing
- The scanner or alert list shows many open findings and the number keeps growing
- An earlier attempt to update packages broke the build, so the updates were abandoned
No passwords, keys, card details or admin invites needed to start.
What usually happened
Dependency scanner findings pile up because each update risks a breaking change, transitive packages need their parent updated or a version override, and nobody owns the order of work. The job turns one scanner's list into a tested set of version changes and a plain list of what remains and why. It is not a penetration test, a review of your own code or a security certification.
Who it’s for: An engineering lead or founder whose repository's dependency scanner reports findings that nobody has had time to work through.
Usually starts when: A customer questionnaire, an investor, a new hire or a scanner email asks about vulnerable dependencies, and the list is long or has been left for months.
The result: On the agreed branch, the named scanner reports no finding at or above the agreed severity whose fix is a patch or minor update, or a major update you approved in writing for that package, other than findings you deferred in writing. Findings that need a major jump you have not approved, that have no fixed version, or whose patch or minor update was tried and broke a baseline test are listed with the decision each needs from you. The project's own tests give the same results as before. You receive the pull request and the list of every remaining finding with its reason.
Check whether this job fits
Answer from your scanner's summary screen without sharing code or the full report. The result is a fit check for this bounded update job.
Checks you can run yourself
Sort findings by how they would be fixed
From your scanner's summary, count the findings whose fixed version is a patch or minor release, those whose fix is a major release and those with no fixed version. Do not paste the report anywhere.
Look for: A large share of patch and minor fixes suits this job. Many major fixes or none-available findings mean the remaining-findings list will be long, which is still useful but changes what you are buying.
What you get
- A pull request with the version changes, built from the agreed branch
- The scanner output before and after at the agreed threshold, and the test and build results before and after
- A change list: each package, the old and new version, and whether it was a direct update, a parent update or an override
- A remaining-findings list with the reason for each and the decision it needs from you
Included
- One repository, one package ecosystem such as npm, pip or bundler, one source revision, one named scanner and one severity threshold, all agreed in writing
- Record the starting state: the scanner's output, the build and test results and the lockfile or pinned requirements
- Update direct dependencies to fixed versions in order of severity; fix a transitive finding by updating its parent or, where the package manager documents it and you agree, with a version override; take no major-version jump without your approval for that package
- Re-run the scanner, build and tests, and record every remaining finding with its reason: no fixed version exists, a major upgrade needs your decision, a patch or minor update was tried and broke a baseline test, or you deferred it. A finding whose only fix is a major jump you have not approved stays open and is listed with the decision it needs
Not included
- A penetration test, a review of your own code, a vulnerability assessment of your running application or any security certification or compliance statement
- Judging whether a vulnerable function is actually reachable in your application, or any claim that the application is secure after the update
- Upgrading a framework or runtime across major versions; that is a separate upgrade job
- More than one repository or package ecosystem, production deployment or secret rotation
- Repairing tests that were already failing before the updates
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The named scanner, run on the final branch, reports no finding at or above the agreed severity whose fix is a patch or minor update, or a major update you approved in writing for that package, other than findings you deferred in writing and findings whose update was tried and broke a baseline test. Any finding it still reports is one you deferred in writing, one that needs a major jump you have not approved, one with no fixed version, or one whose patch or minor update was tried and broke a baseline test (listed with that test), and it appears in the remaining-findings list.
Evidence: The scanner output on the baseline and on the final branch, with the scanner version and the date, the written deferrals and approvals, the failing test output for any update that broke a baseline test, and the remaining-findings list.
The build passes and the project's tests give the same pass and fail results as the baseline, with no test removed, skipped or loosened to get there.
Evidence: The test and build output before and after, and the pull request diff showing no change to test files except any agreed new tests.
Every changed package is listed with its old and new version and whether it was a direct update, a parent update or an override, and no major-version change was made without your written approval.
Evidence: The change list compared with the lockfile diff, and your written approvals.
Every finding still reported is listed with its reason: no fixed version, a major upgrade awaiting your decision, a patch or minor update that broke a baseline test, or deferred by you. Your authorised maintainer accepts the pull request.
Evidence: The remaining-findings list compared with the final scanner output, and your written sign-off.
Sign-off. You compare the two scanner outputs, read the change list and the remaining-findings list, sign off in writing and merge the pull request. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. If most findings need an upgrade or the tests are too thin, we explain what we found and stop, and a different scope needs a new written agreement.
When it fits, and when we stop
It fits when
- The repository has a lockfile or pinned requirements, and a build and test command that pass, or fail in a known and recorded way, before any change
- The scanner you name can be run on an authorised copy without your credentials, and its advisory source is reachable
- The code can be shared through an authorised company-controlled route after agreement, and a named person on your side can review and merge the pull request
We stop and tell you if
- The tests do not run, or are too thin to show that an update left behaviour unchanged: we say so and agree whether to add tests first
- Most findings need a framework or runtime major upgrade: we stop and propose the upgrade job instead of forcing the change
- Vendored or private packages we cannot update or scan make up most of the findings
- A finding appears to show a live compromise, an exposed secret or active exploitation: we stop and ask you to use your incident process
What could go wrong
Each update group is a separate commit in one pull request, so any group can be reverted on its own. Closing the pull request before merge leaves your default branch unchanged. Reverting restores the earlier versions and the earlier findings.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| An update changes behaviour that the tests do not cover. | The baseline and final test results are compared, major changes are listed with their release notes, and you decide on each major jump. The handover says what the tests could not show. |
| A version override forces a package to a version its parent was not built for. | Overrides are used only where the package manager documents them and you agree, are tested, are listed as overrides and are flagged for removal once the parent is updated. |
| A clean scan is read as a statement that the application is secure. | The handover states that a scanner reports known advisories only. A clean result at the agreed threshold says nothing about your own code, configuration or unknown weaknesses. |
| Resolving or auditing packages runs untrusted package code on our side. | Work happens in an isolated workspace without your secrets, and the scanner's own documentation about auditing requirement files is followed. |
An independent reviewer checks that no test was removed, skipped or loosened, that no major-version jump or override went in without your approval and that the remaining-findings list is complete. Your authorised maintainer reviews and merges under your existing rules.
Need to keep it working?
To keep newly reported findings and support dates handled month after month, a separate monthly service is agreed in writing; it is listed in the related products.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- npm documents audit and audit fix. Your maintainer can run them on a branch, and the page warns against forcing major-version changes unless you know you want them. docs.npmjs.com
- For Python, pip-audit scans an environment or requirements file and has a fix option; its documentation says unfixed findings need filtering outside the tool. github.com
- If the repository is on GitHub, a Dependabot alert can open a pull request that updates the affected package, which you can review yourself. docs.github.com
Questions
Does this make my application secure?
No. A scanner lists known advisories for the packages you install. A clean result at the agreed threshold says nothing about your own code, your configuration or weaknesses nobody has reported.
What if a fix needs a major upgrade?
We list it with the decision it needs from you and do not force it. A framework or runtime upgrade is a separate job with its own tests.
Which scanner do you use?
The one you name, agreed in writing, for example your package manager's audit command, pip-audit or your platform's dependency alerts. The same scanner is used before and after.
Will you deploy the updated packages?
No. You review and merge the pull request and decide when and how to deploy. We do not touch production.
Send an enquiry
Send us
- The package manager and ecosystem, the scanner you use or want used, and the number of open findings by severity (counts only)
- Whether the build and tests pass today (yes or no)
- The severity threshold you care about, and any packages that must not change
- Do not send repository code, credentials or the raw scanner report in the first enquiry; counts are enough
Later, once you agree
- The agreed source revision through an authorised company-controlled repository or code-export route, with a branch route for the pull request
- Build and test commands, and any registry settings needed to install packages, supplied without secrets in the message
- The packages you want left alone, the person who decides on major-version jumps and the person who accepts the pull request
You keep the repository, package registries and secrets. We work on a copy in an isolated workspace through a company-controlled identity, never a personal login, and return a pull request. You review and merge it and decide when and how to deploy. We do not deploy or change repository settings.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “dependency-vulnerability-updates-for-one-repository” as the subject.