Production keeps moving.
So does the work.
Dispatch is running. Then a vulnerable dependency needs attention. Watch the finding become a controlled repair. Then see what proves the problem is gone.

The release is live. Keep it working.
Projects
Open a project to inspect its own evidence
Keep dispatch running while the next repair moves through the same controlled delivery process.
Open the system the business relies on. Its deployments, monitoring and maintenance evidence stay attached to the project, ready for the next decision.
Each project keeps its own releases, monitoring and maintenance records.
Two findings. One dependency. One repair.
Maintaining
Vulnerable request parsing in the routing dependency
api/package.jsonworker/package.jsonSEC-08 · Dependency maintenance
Remediate vulnerable dependencies through the approved delivery process.
Published organization policy2 findings mapped to this control
c39e264Repository sweep · osv-scannerA repository sweep finds the vulnerable package in two places. Maintaining groups them and connects the findings to the organization’s published dependency policy.
The repository scan identifies a vulnerable dependency. It does not establish that its vulnerable path is reachable in production.
The repair joins the work already in motion.
Initiatives
Patch the vulnerable routing dependency in the API and worker. Keep dispatch behavior unchanged.Patch the vulnerable routing dependency in the API and worker. Keep dispatch behavior unchanged.
- NP-SEC-09Patch dispatch routing dependencyPlanning
2 findings · urgent patch · automatically proposed
- NP-INIT-10Improve delivery exception handling
No initiatives
No initiatives
Build on its own by default · enabledMerge review · a person must approve
One active initiative per project. The next starts after merge, not merely after the build finishes.
This illustrated urgent patch qualifies for automatic remediation. Its initiative enters the queue, is planned in turn, and builds under the same autonomy settings as other work.
Automatic proposals are limited to eligible minor or patch upgrades, with caps and cooldowns. They never override your build or merge settings.
Both references are patched. Your reviewer checks the change.
NP-SEC-09 · Pull request review
parcel-router: 2.4.1parcel-router: 2.4.2parcel-router: 2.4.2API and worker references updated · dispatch checks passed
Required reviewer approved · PR #44 merged
Illustrated settings: automatic build; human merge review. Required checks and branch protections remain in force.
Both package references are updated and the dispatch checks pass. This project requires a person to review the pull request; the next initiative waits until it merges.
The organization’s automation limits and repository protections govern the real merge. This example keeps human review.
The same change reaches your production environment.
Deployments
What is running in each environment, and the deployments that got it there.
d40f375main · GitHub Actionsd40f375main · GitHub Actionsd40f375ProductionSucceededd40f375DevelopmentSucceededYour configured pipeline deploys. Taiga brings its reported versions, environments and history into the project.
After merge, the configured pipeline takes the repair through development and production. Taiga mirrors the connected provider’s deployment records.
A successful deployment says the pipeline finished. It does not, by itself, resolve the finding.
A shipped fix still has to prove itself.
Finding verification
The repair is merged. The finding still needs evidence.
The vulnerable version is absent from both package references.
Same package. Both references. A new scan of the repaired commit.
A failed scanner preserves the previous findings; a green deployment does not replace a scan.
The new scan checks the repaired package references. The original findings resolve only when the vulnerable version is no longer detected.
If scanning fails, the earlier findings stay open. Silence is not verification.
Know what changed. Know what was verified.
Inspect the released repair, replay a failed verification, or check the production signals. Each record answers a different question.
Inspect the production outcome
Vulnerable request parsing in the routing dependency
api/package.jsonworker/package.jsond40f375Independent scan · vulnerable version not detectedThe independent scan no longer detects the vulnerable version in either reference. Both findings are resolved.
Local demonstration with fictional records. Failed verification retains the earlier finding; project switching preserves missing-data states.
North Pole Dispatch, its package, advisory, policies and records are fictional examples. The inspector runs locally; it does not scan or change a real system.