Code remediation in CI/CD: fixing issues inside the pipeline

Detection gates find issues well and close almost none of them. A common CI/CD model layers four gates: in-editor prevention while a developer writes config, pull request scanning at the CI stage, container image scanning before deployment, and continuous post-deployment scanning triggered by new CVEs (ARMO). Each gate produces findings. None of them writes the fix.

ARMO describes the standard response to a scan as three steps: acknowledge the finding in a log, then fix or ignore it (ARMO). Acknowledging a finding records that someone saw it. A logged acknowledgment moves nothing toward merge, and the fix still waits on a human. The gap between detection and closure is where the backlog grows.

Scanning tools compound the problem by finding more than any team can act on. ARMO calls this alert fatigue, or "CVE Shock," where the volume of surfaced misconfigurations and vulnerabilities overwhelms developers who do not know where to start (ARMO). Every scan adds to the pile faster than triage removes from it. The queue never drains because the tooling that fills it does not empty it.

The human bottleneck sits between the developers who write the code and the security professionals who read the findings. Cycode reports that 76% of security professionals find it challenging to build a culture of collaboration between security and developer teams (Cycode). A finding produced by a security scan often needs a developer to fix it, and the handoff between those two roles stalls. A detection-only pipeline leaves that handoff unresolved, so findings accumulate on both sides of it.

Where a remediation layer fits in the pipeline#

Remediation is a distinct pipeline stage that produces fixes. It sits alongside the detection gates, not in place of them. The gates decide what counts as a problem. The remediation stage runs its own review of the code and writes changes that resolve the same classes of problems.

A standard pipeline runs through a familiar sequence. A code push triggers a build, the build installs dependencies, the tests run, and the pipeline deploys to staging before production (Cycode). Detection checkpoints sit across that sequence. Linting warns during coding, SAST scans pull requests against severity thresholds, and quality gates fail or pass the build based on defined rules (ARMO). Each checkpoint answers one question: whether a problem exists.

Remediation answers the next one: what the fix is, and whether it holds. That stage runs in parallel to the detection tools rather than downstream of a single one. It reviews the code and creates a pull request that resolves the issue, then verifies the fix before a human sees it.

Sonar quality gates stay in place. Semgrep CI checks stay in place. Neither changes, and neither hands its output to another tool. Hyrax runs its own review of the code and produces fixes for what that review surfaces, alongside the existing gates rather than replacing their judgment. A team keeps every required status check it already trusts, and adds a stage that turns findings into reviewable changes.

Separating detection from remediation matters because the two jobs need different tools. A scanner that fails a build is doing detection well. Asking that same scanner to also write and verify the fix stretches it past its design (Parasoft). Keeping remediation as its own stage means the detection gates stay strict, and the fixes arrive as pull requests a reviewer can accept or reject. The pipeline finds and closes issues without conflating the two.

Before and after: a pipeline with remediation wired in#

Consider a Semgrep CI check that flags a hardcoded credential on a pull request. Before a remediation layer, that finding fails the status check and stops there. A developer acknowledges it in a log, adds it to a backlog, and moves on. The severity threshold blocks the merge, so the branch waits until someone finds time to triage, understand the flag, write the fix, and rerun the pipeline. Multiply one finding by the volume a scanner produces and the backlog grows faster than the team clears it, the pattern ARMO describes as alert fatigue.

The deploy path pays for that delay. A required status check holds the merge until a human acts, so unrelated work queued behind the same branch stalls. The gate did its job by finding the credential. It did nothing to close the issue, and it held the pipeline shut while a person caught up.

With remediation wired in, the same hardcoded credential triggers a different response. Hyrax's own review catches it, writes the fix, and reruns verification against it before proposing anything. The issue becomes a pull request with a scoped diff a reviewer reads and approves, rather than a line item in a backlog. The Semgrep check still runs, and the Sonar quality gate still enforces its threshold. Neither changes.

The operational shift is the reviewer's queue. Instead of triaging a raw finding and writing the fix from scratch, the reviewer reads a proposed change that has already passed verification. The deploy path is not held for manual work, because the fix arrives as reviewable code on its own branch. Nothing merges without a human approving it, so the gate's enforcement stays intact while the remediation runs in parallel.

Issues that once accumulated as debt now arrive as candidate fixes. The pipeline keeps finding problems at its existing checkpoints, and remediation keeps closing the same problems without blocking the deploys queued behind them.

How Hyrax turns findings into verified pull requests#

Hyrax reviews the code moving through the pipeline and produces fixes as pull requests that a human still reviews. Each fix is pre-verified before it reaches the reviewer, so the pull request arrives with the change already tested against the same checks the pipeline runs. Nothing merges on its own. A reviewer approves the diff, and the deploy path stays clear while that review happens.

The review and fixing span six domains, not security alone. Hyrax finds and fixes issues in security, correctness, maintainability, performance, architecture, and operations. A security-only remediation layer closes one class of finding and leaves the rest in the backlog. A null-pointer bug, a slow query, a tangled module boundary, and a fragile deploy script all stall the same way a vulnerability does. Fixing across all six domains means the reviewer's queue shrinks on every axis the pipeline flags, not just the one a scanner labels as security.

Spanning the domains also catches problems that cross them. A performance fix that introduces a correctness regression, or an architecture change that weakens an operational safeguard, shows up when one system reviews all six together. A tool scoped to a single domain cannot see those interactions, because it never looks at the others.

Hyrax reviews all code, not just AI-written code. A fresh machine-generated diff and a five-year-old hand-written module get the same review, so a maintainability issue in an old file gets a fix the same way a new security flaw does. The remediation layer treats the full codebase as its input.

The guardrail that answers the adoption-risk concern is the review step itself. Parasoft's guidance for safe adoption of AI remediation puts humans in the loop for approval, uses existing testing as a check, and keeps an audit trail of every change (Parasoft). Hyrax follows the same shape. Every fix ships as a reviewable diff, the change is verified before it reaches the pull request, and no merge happens without a person approving it. An engineering lead worried about autonomous code changes keeps the same control they have over any other contributor's pull request.

Setting up remediation without disrupting existing gates#

Adoption works best as sequencing, not replacement. Keep the Sonar quality gate and Semgrep CI checks configured as required status checks exactly as they are today. Add remediation as a step that runs alongside them, acting on Hyrax's own review findings across the codebase rather than gating the build a second time. The detection gates keep failing merges that cross a defined risk threshold, and the remediation layer produces fixes for review in parallel.

Sequencing keeps the pipeline predictable during rollout. A required status check still decides pass or fail on every pull request, so nothing about the deploy path changes when remediation is added. Hyrax reviews all code and submits fixes as separate pull requests, which means an engineering lead can adopt it without touching branch protection rules or existing gate configuration.

Trust builds through the audit trail. Parasoft's safe-adoption practices for AI-driven remediation call for accountability through an audit trail of every change, recording the files and lines modified with version-control integration and rollback (Parasoft). Hyrax follows the same practice. Every fix arrives as a reviewable diff in a pull request, tracked in version control, and nothing merges without human approval.

That reviewable diff is what makes a phased rollout practical. Start remediation on a single service or a small set of repositories, review the pull requests it submits, and measure fix quality against the diffs before widening scope. Parasoft recommends exactly this pattern of iterative, branch-based workflows in small batches before merging (Parasoft). The existing gates stay required throughout, so the pipeline never depends on the remediation layer to enforce a threshold.

FAQ#

Does remediation replace Sonar or Semgrep? No. Sonar quality gates and Semgrep CI checks stay in place as required status checks. Remediation runs alongside them and closes the same classes of issues those tools flag rather than duplicating their gate role.

Does anything auto-merge? No. Hyrax ships every fix as a pull request that a human reviews before it merges. The remediation layer proposes and verifies changes, and the reviewer decides whether the diff belongs in the codebase.

What happens to the existing backlog of findings? Hyrax reviews all code, not just recent commits, so long-standing issues become candidates for verified pull requests. Instead of acknowledging a finding in a log and waiting for a free engineer, the reviewer receives a proposed fix to accept or reject.

Does remediation slow down the pipeline? No. Remediation produces pull requests in parallel to detection gates, so the deploy path stays live while fixes wait for review. A flagged issue no longer blocks a merge until a person triages it.

What is the pricing model? Hyrax runs on credits with a Free plan and a Paid plan. Credits meter review and fixing work, so the cost scales with how much code Hyrax processes rather than a fixed charge.

Gates find, remediation closes#

A CI/CD pipeline finds issues at every checkpoint. Linting flags style problems, tests catch regressions, and SAST scanners surface security gaps. Detection alone leaves those findings sitting in a backlog. A remediation layer closes the loop by running its own code review and fixing pass, then submitting pre-verified pull requests a human still reviews. Sonar quality gates and Semgrep CI checks keep running as required status checks. Hyrax fixes across security, correctness, maintainability, performance, architecture, and operations, and nothing merges without review. Gates keep finding issues, remediation keeps closing them, and deploys keep moving.

Hyrax makes your code better. Ship clean code.