Remediate a vulnerability
Goal: choose an action suited to the repository, verify its outcome, and avoid confusing a hidden alert with a fix.
Verified on September 13, 2026 against ecbd364. Prerequisites: a
completed scan, a finding to examine, and, for actions,
an authorized role and the required permissions on the code hosting platform.
Guide home.
1. Examine the finding
Section titled “1. Examine the finding”In Findings, open the finding for the relevant repository. Check the package, observed version, repository, and advisory. Read Risk breakdown and the indicator limitations. Confirm that the scanned reference matches the version you want to fix.
If Fixed version shows a dash, consult the advisory and project releases to identify an applicable fix. You may need to wait for a release or apply a temporary mitigation assessed by your team. Perpensa does not guarantee an automatic proposal for every finding.
2. Open the proposed change
Section titled “2. Open the proposed change”From Recommended updates, open the update details page. You can also find it in Queue. Examine the current version, target version, affected file, associated findings, and any AI rationale.
A security change aims to fix a security issue; that does not guarantee the absence of breaking changes. Review release notes and required tests, including for a minor update. A Suggested command is guidance to check against your environment, not a command to run blindly.
3. Choose an action based on repository type
Section titled “3. Choose an action based on repository type”| Your situation | Action | Expected outcome |
|---|---|---|
| Your connected repository, instance enables PR creation, write access, supported fix format | Open upgrade PR | A branch and PR/MR are created on the code hosting platform if the operation succeeds |
| Your repository, automatic fix unavailable | Change dependencies through your usual workflow | A reviewed and tested change in your repository |
| Third-party product tracked as a Public watch | Open the upstream release analysis | Evaluate a product version, then update your own installation |
| Signal to exclude from your current workflow | Evaluate Suppress or Dismiss finding, depending on the object | An exclusion from tracking, without fixing the software |
Your repository: create and review a PR
Section titled “Your repository: create and review a PR”If upgrade PR creation is unavailable, use your usual dependency update workflow or contact support. While disabled, Open PR, Group PR, Open upgrade PR, and the PR policy controls are hidden. AI actions that propose opening a PR return “Upgrade PRs are disabled on this instance.” Other AI actions remain available. The Require PR for KEV policy does not block suppression while PR creation is unavailable; its saved setting applies again when PR creation is available.
Click Open upgrade PR if the action is available. Creation requires a working integration and write access. Inventory support for an ecosystem does not imply that its format can be changed automatically. Automatic preparation of PR files is currently limited to npm; check the result for the affected manifest and lockfile.
Existing PRs remain visible and their status continues to refresh, even while creation is disabled. If a PR already exists, open it instead of creating another. In Pull requests, follow the link to the code hosting platform to check changed files, tests, review comments, and the actual PR status.
The Open, Merged, and Closed badges describe the recorded PR status. CI pending, CI green, CI failed, and CI unknown describe the recorded CI status. If in doubt or if statuses differ, check the code hosting platform directly: do not assume badges are synchronized in real time. An old Not created on GitHub entry is a legacy placeholder, not a real PR.
After review and testing, merge through your usual process, then deploy the change if needed. Creating the PR does not perform these steps.
Public watch: update the upstream product
Section titled “Public watch: update the upstream product”A third-party product’s internal dependencies may be grouped into a single release analysis. Check the proposed upstream version, the findings it would address, and those that remain. A proposed version is not a promise of a complete fix or compatibility with your installation.
For example, you track the fictional product example/server at tag v1.2.0.
The analysis proposes v1.3.0. Evaluate and deploy that version in your own
environment, then adjust tracking with Change tag and check the new scan.
Changing the tracked tag does not deploy anything: you can also use it to
evaluate a version before deployment, but note that the tracked reference then
temporarily differs from your installed version.
A Public watch cannot open a PR against upstream. If you need to maintain a fix in a fork, connect that fork as your own repository with the required permissions and supported formats.
4. Understand states before closing your work
Section titled “4. Understand states before closing your work”| State or action | Meaning in the current flow | Does not mean |
|---|---|---|
Finding open |
Finding still open in tracking | Proven exploitation in your application |
| Dismiss finding | Sets the finding to suppressed |
Package fixed or all associated updates suppressed |
| Suppress on an update | Sets that update to suppressed and excludes it from the default queue |
Associated findings resolved |
Update fulfilled |
A PR has been linked to the proposal; this state is set as soon as the PR is created | PR merged, change deployed, or finding resolved |
| PR Merged | Recorded merge status | Deployed version or result of a new scan |
Finding resolved |
Tracking considers it resolved under the applicable scan flow | Proof of deployment in all your environments |
In Queue, Show suppressed lets you find hidden updates. A KEV protection policy may block suppression. Ordinary suppression buttons do not imply automatic expiry; record your rationale and when to revisit the decision.
5. Verify after the change
Section titled “5. Verify after the change”Open the repository details page and run Rescan on the relevant reference. Wait for the completed result, then check:
- Scan date, success, and relevant coverage.
- The new version in inventory and the correct file or tag.
- Findings still associated with that version, using appropriate filters.
- Actual deployment of that version in the relevant environments, outside Perpensa.
Automatic reconciliation is not uniform: the Public watch flow can resolve previously open findings absent from the new scan when reconciliation is enabled. Other flows do not all guarantee this transition; suppressed findings are handled separately. An older finding may therefore require investigation even if the version has changed.
Similarly, some obsolete open updates are removed on rescan, but updates linked to a PR or suppressed are retained. Neither a row disappearing nor its remaining is sufficient evidence on its own. If results remain inconsistent, keep the repository, scan, and finding references for your administrator or support, without sharing secrets.
Troubleshoot the workflow
Section titled “Troubleshoot the workflow”| Problem | Next action |
|---|---|
| PR creation denied | Check role, connection, write permissions, and format; read the exact error |
| PR creation controls missing on your repository | Use your usual dependency update workflow or contact support |
| Action missing on a Public watch | Use upstream analysis; use a connected fork for a code change |
| Queue row disappears as soon as the PR opens | Check Pull requests: fulfilled is not a confirmed fix |
| No target version | Examine the source advisory and compatibility of release branches containing fixes |
| Finding still visible after merge | Check scanned reference, inventoried version, rescan result, and reconciliation limits |
| Different result after AI | Recheck the rationale and effective priority; finding data still needs examination |
A fix is verified when you have evidence of the change, appropriate tests, an updated inventory, and deployment where required. Return to the user guide.