Remediation: from verified finding to reviewed change

“Detecting is not fixing”: what a reviewable change is and why your team keeps merge control

A finding tells you that something is wrong. It does not change one line of your code. Between the two sits work that scanners do not do. Someone has to write the fix and check that it removes the root cause without breaking anything. Then the change has to get through your team’s review.

Remediation is the Remediate step of Proof-Driven AppSec. AI Swarm Pentest validates what is exploitable (module 6), and Deep Code Analysis explains how a weakness affects your application (module 5). Remediation turns that knowledge into a change your team can review. Start from findings you have triaged (module 4), ideally ones backed by evidence such as a confirmed pentest finding or a reachable code path, so review time goes to risks that are real.

What a reviewable change contains

In Plexicus, a code remediation is a proposed change for one or more findings. It is not a commit to your main branch, and it is not a bare “please fix” ticket. It has four parts:

• A diff. The exact lines added and removed, file by file.
• An explanation and a title. AI writes them for the reviewer, saying what changed and why. They become the pull request’s description and title.
• A verification badge. It tells you whether the fix was tested, and with what result.
• A destination. The change goes to a new branch in your repository, with a pull request against your base branch. On GitLab it is a merge request.

Take a SQL injection in a login handler, where the handler concatenates the submitted email address into a query string. A reviewable change replaces the concatenation with a parameterized query in that handler and explains why. It lands as a pull request that your reviewers can read next to the finding’s evidence. It does not rewrite your data-access layer, and nothing reaches your main branch until someone on your team merges it.

Why your team keeps merge control

Plexicus never merges a remediation pull request. Merging happens in your SCM, under your branch protections, your required reviews and your CI, by people on your team. There are three reasons.

• AI-written code can be wrong or incomplete. The review screen carries a disclaimer that asks you to validate the suggestion against your project’s context and requirements.
• Your team owns the context. Take an IDOR in an invoice API, where any logged-in customer can read another customer’s invoice by changing the ID. A fix might add an ownership check. Only your team knows whether support staff should still be able to open every invoice.
• Accountability. The pull request description names the user who opened it, and your SCM records who approved and merged it. Plexicus writes remediation requests to the organization’s Audit Log, and each finding’s Activity section shows when a remediation was generated and when its pull request was created.

Which findings can be fixed in code

Plexicus can only patch something that lives in a repository. What the finding detail panel offers depends on where the finding comes from.

Finding	What the detail panel offers
A finding that points at a file in a connected repository	Create AI Remediation
A container registry finding whose image is linked to a source repository	Remediate in repo
A finding whose remediation type is Issue, for example when there is no source line to change	Create Issue
An AI Pentest finding	No code fix unless the pentest has a linked source repository; confirm with Plexicus that pentest fixes are available in your release
A cloud misconfiguration, an SCM posture finding, or a registry image not linked to a repository	No remediation action

If an AI Pentest has no linked repository, Plexicus tells you that remediation requires a linked source repository and that you can configure one in the pentest settings.

Creating an AI remediation: checks, fix strategies and live progress

The checks Plexicus runs first

Plexicus confirms that the work can succeed.

1. AI connection. It tests your organization’s AI connection, whether the Plexicus default or your own (lesson 5).
2. SCM connection. It validates your source-control token. If the token is no longer valid, Plexicus asks you to reconnect your source control.
3. Repository access. It confirms the repository is reachable.
4. False-positive verdict. A finding still pending false-positive review, or one the AI pass flagged as a false positive, cannot be remediated. The tooltip says so, and the server enforces it too. Reverting the AI’s false-positive mark (module 4) lifts the block.
5. One person at a time. If a colleague is already remediating the finding, the button is disabled with “Another user is working on this finding”.

Sandbox demo repositories skip the SCM checks and can generate fixes, but not open pull requests or issues. If your monthly AI usage allowance is used up, the button is disabled (lesson 5).

How Plexicus picks a fix strategy

You do not choose the strategy. Plexicus picks it from the finding.

Situation	Strategy	How the change is produced
A person marked the finding as a false positive	Suppression comment	An inline comment that silences that rule at that location
A dependency finding with a known fixed version in the same major version	Dependency version bump	A deterministic edit to the manifest, with no AI writing code
Everything else, including dependency upgrades across a major version	AI fix agent	A code change written by the agent

The suppression comment follows a human decision. When someone marks a finding as a false positive (module 4), Plexicus requests a change that adds this comment. Depending on your source-control provider, it arrives as a pull request for your team to review, at no cost to your AI usage allowance.

The dependency version bump covers common manifests, including npm, Composer, requirements.txt, Gemfile, TOML files, go.mod, Gradle and .csproj. The proposed version is checked against the package registry; if it cannot be verified, the remediation carries a “review before merging” warning. A major-version jump can change the library’s API, so it goes to the AI fix agent. No AI writes the bump, but it still counts against your AI usage allowance.

What the AI fix agent does and does not do

The agent works on a fresh clone of the repository’s configured branch. Its scope is deliberately narrow:

• It fixes only the reported issue at the reported file and line.
• It touches another file only when the fix needs it, such as a shared helper.
• It is instructed not to refactor, not to fix other issues it notices, not to edit test files and not to commit. Plexicus captures the result as a git diff.

Instructions are not guarantees, so check the diff for anything beyond the finding.

For common vulnerability classes, the agent receives the secure-coding pattern for the file’s language: SQL injection (CWE-89), cross-site scripting (CWE-79), OS command injection (CWE-78), path traversal (CWE-22) and insecure temporary files (CWE-377). This steers it toward a parameterized query instead of a blocklist filter. For an exposed secret, the agent moves the value into an environment variable, and the review adds guidance to configure a secret-management solution.

When one remediation covers several findings, they are grouped by file, a few per AI session, and the groups run in turn. Finished groups are delivered even if a later group times out.

Watching progress

The live terminal streams each step, from the repository clone through “Generating fix…” and one line per file group to “Fix captured” and a final result. When the fix is ready, the review modal opens automatically. View AI Remediation reopens it later.

If a fix is still running after 15 minutes, Plexicus says “This remediation is taking longer than expected.” and offers Create Remediation Again. If generation fails, you see “Failed to create remediation” and a Try Again button. A failed attempt never blocks a retry.

Reviewing the fix and opening the pull request

The review modal is where your judgment comes in. Read it as you would a colleague’s pull request, with the finding’s evidence beside it.

What the review modal shows

• The finding title and a verification badge.
• A change summary: lines added, lines removed, and the number of files.
• A unified diff for each file. Any generated line that looks corrupt is struck through and marked “Possibly corrupt generated line — review before applying.”
• A collapsible section, Why this fix — reasoning & verification, with the AI-written explanation.
• The AI disclaimer, and the source branch and target branch the pull request will use.

The explanation is written in your organization’s Scan & Report Language, which an Admin sets under Settings Platform .

Reading the verification badge

Fix verification is optional. Your organization turns it on with the Fix verification toggle under Settings Platform , and whether it is available depends on your plan. When it is on, a second AI session runs in an isolated, throwaway copy of the repository. It writes a focused security test for the finding and runs it against the fixed code.

Badge	What it means
Fix verified	The isolated test ran and passed against the fixed code
Fix not tested	No verification test was run for this fix
Fix unverified	The fix was applied, but the test timed out, so it is not proven
Verification failed	The test found the vulnerability still exploitable
Verification error	The test could not run

Verification only annotates the fix. It never changes the diff you review.

What to check before you open the pull request

• Root cause, not symptom. For the login handler, a parameterized query is the fix. Escaping quotes in the email field is not.
• Behavior. For the invoice IDOR, confirm that the new ownership check matches your real authorization rules.
• Dependencies. Read the changelog for the new version and check whether your lockfile needs regenerating.
• Secrets. Moving a secret into an environment variable stops the leak in code, but the old value is still compromised. Rotate it.

Editing, then opening the pull request

With the default roles, Admin and Cyberoper users can edit the generated code before a pull request exists. Use Edit Pull Request, or Edit and then Save on each file of a multi-file fix. Once a pull request or issue exists, editing locks with “A pull request has already been created — editing is locked.” From then on, you change the code on the branch in your SCM.

When the change is ready, an Admin or Developer clicks Pull Request (Merge Request on GitLab) at the bottom of the modal. Plexicus clones the configured branch and creates a new branch whose name starts with Plexicus-AI-Remediation-. It applies the diff, pushes, and opens a pull request against the base branch. Its title and description come from the remediation, and the description ends with “Created by:” and the email address of the user who opened it. A banner confirms “Pull request created” with a See PR link, and the button on the finding becomes See Pull Request.

Remediation pull requests work on GitHub, GitLab, Bitbucket Cloud, Azure DevOps, Gitea and Forgejo. Azure TFVC has no pull requests. If the push fails, Plexicus says why: the repository is a read-only mirror, the token needs write access, or the token is invalid.

For findings remediated as an issue, the modal offers Create Issue, plus Send Webhook if an issue webhook is configured. If a ticketing integration is set up to follow pull requests, the ticket is updated too (module 9).

Status	What it means here
Ready to Fix	A remediation is generated and waiting for review
Fix Submitted	A pull request or merge request was opened
Issued	An issue was opened instead of a pull request
Fixed	Your SCM reported the pull request merged, or the linked issue closed

Bulk remediation across many findings

Fixing findings one at a time does not keep up when a scan reports 40 vulnerable packages across a service. Bulk remediation applies the same flow to a selection and tracks the whole run in one place. Whether bulk remediation is available depends on your plan.

Starting a bulk run

In Findings , tick at least two findings, open the bulk actions and choose Remediate. One request accepts up to 100 findings. The bulk actions you see depend on your role (module 4); with the built-in roles, Developers can only use Create Pull Request on findings whose remediation is already generated.

Plexicus groups the selection by repository, then by fix strategy, just as for one finding (lesson 2). In each repository, suppression comments, dependency version bumps and AI fixes each become their own remediation, and only the AI fixes go through the AI fix agent’s file groups. Findings that are remediated as an issue each get their own AI-written issue. The modal has two options:

• Automatically create pull requests. On by default. When it is off, fixes stop at Ready to Fix and nothing is pushed.
• Pull request mode applies to the AI fixes. Either way, each repository gets one pull request for them. Single PR records each remediation group as its own commit, so reviewers can step through the change file by file, and leaves out groups that failed or changed nothing. One PR per remediation, the default, delivers the same fixes as a single commit. Dependency bumps and suppression comments always get a pull request of their own.

Click Remediate to start. Findings that already have a remediation are skipped. Findings still pending false-positive review, or flagged as false positives by the AI pass, are blocked, just as they are one at a time.

Following the run

The toolbar toggle Findings Bulk remediation status opens the Bulk Remediation Progress panel. Each run moves through four phases: Queued, Generating fixes, Creating pull request and Completed. A run reads Running, Completed or Incomplete.

Each remediation group, a few findings in the same file, shows its own status. These are the ones you will see most:

Group status	Meaning
Queued	Waiting for the remediation engine
Processing (with a percentage)	The AI fix agent is working on this group
Succeeded	The group produced a change
Failed	The AI session hit an error or timed out
Skipped (no changes)	The group produced no change, and its findings are left as they were

Each group has its own live terminal, and View Pull Request takes you to the result. The panel survives a page refresh and the whole team can see it. A colleague can follow a run you started without asking you for status. In Single PR mode, findings in a group that failed or produced no change keep their status.

Designing a batch your reviewers can handle

A bulk run is only as useful as the pull requests it produces. Keep batches together by repository, by owning team and by class of issue. For example, select the 25 vulnerable-dependency findings in the payments service rather than 25 unrelated findings from six repositories. A focused batch gives one team a pull request it recognizes and can review in one sitting. A mixed batch produces pull requests that nobody feels responsible for.

AI configuration and usage: allowance, bring-your-own AI and what never happens automatically

Your AI usage allowance

AI actions draw on one monthly allowance for your organization. That includes AI fixes, dependency version bumps, AI-written issues and AI false-positive analysis. Running repository scans does not draw on it, but AI-powered analysis can, so check the meter before a large AI scan. The allowance resets on the 1st of each calendar month (UTC), not on your billing date. AI Pentest sessions (module 6) and AI filter conversions have their own counters. How large your allowance is depends on your plan.

When usage data is available, your profile menu shows a usage meter and a Manage billing & usage link. Depending on your plan, Settings Billing , a page titled Billing & Usage, shows what has been used against your limit this month and the date the allowance resets, or Unlimited. On the Billing page, the bar turns amber at 75% and red at 90%, and Plexicus warns you at both points. Where your release includes it, a Usage page under Settings breaks usage down by action, with a full history.

When the allowance runs out, Create AI Remediation is disabled with a message that the monthly limit is reached, bulk Remediate is disabled, and the Findings page shows a banner with Upgrade plan. AI actions resume when the allowance resets.

Bring your own AI (BYO-AI)

Depending on your plan, you can run Plexicus AI on your own model endpoints instead of the Plexicus default models.

Slot	What it is used for	What you enter
Fast model	Runs on every finding for validation and enrichment, so it handles high volume	API key, Base URL, Model
Smart model	Generates fixes and deep analysis, with lower volume and higher stakes	API key, Base URL, Model
Embeddings endpoint	Builds the searchable index of your code before every AI scan	API key and Base URL; the embeddings model is fixed and shown read-only

Each slot accepts a standard chat-completions or embeddings endpoint from your AI provider, authenticated with an API key, including a self-hosted gateway. There is no provider picker. Save BYOAI configuration tests and saves all three blocks together, and the embeddings endpoint is required, because a partial setup would break every AI scan. Stored keys are never shown again; leave a key field blank to keep it. Base URLs are checked against server-side request forgery before a connection test. Reset to Plexicus default clears all three blocks. With BYO-AI, the usage meter shows Unlimited because inference runs on your own key and account with your AI provider.

Where your code goes

AI features send the relevant code context to the configured model endpoint: the Plexicus default models, or your own endpoint with BYO-AI. Each remediation runs in a short-lived isolated job. The agent can write only to its cloned workspace and gets none of the platform’s other credentials. Verification runs in a throwaway copy that is deleted afterwards. Customer code is not used to train AI models, and SaaS data stays in the EU by default.

What never happens automatically

Key takeaways

• A remediation is a proposal: a diff, an explanation, a verification badge and a pull request on a new branch. Plexicus never merges it. Your team does, in your SCM.
• Before a fix starts, Plexicus checks the AI connection, the SCM token, repository access and the false-positive verdict. It then picks a suppression comment, a dependency version bump or the AI fix agent.
• Review the diff and the “Why this fix” explanation as you would any pull request. A Fix verified badge proves the targeted test passed, not that nothing else broke.
• Edit while the remediation is still a proposal. Once the pull request exists, editing locks, and Fix Submitted becomes Fixed only when your SCM reports the merge.
• Bulk remediation groups up to 100 findings by repository and fix strategy. Choose automatic pull requests and the pull request mode on purpose, and follow the run in the Bulk Remediation Progress panel.
• AI actions draw on a monthly AI usage allowance, shown under Settings Billing and in your profile menu. With BYO-AI, you point the Fast, Smart and Embeddings slots at your own AI provider endpoints.