Automated security remediation

Scanners find security issues well. They rank severity, map CVEs, and produce a prioritized list of what needs attention. The work that follows detection stays manual. An engineer reads each finding, decides whether it applies, writes the fix, runs the tests, and confirms the change holds. That labor accumulates faster than most teams can clear it.

The lag shows up in the numbers. Veracode's State of Software Security 2025 puts the median time to remediate a flaw at 252 days, up from 171 days five years earlier, cited within Pixee's remediation roundup. Backlogs grow in parallel. Tenable Research reports that 66% of organizations carry more than 100,000 unresolved vulnerabilities, also noted in the same roundup. A scanner that surfaces a thousand new findings a week hands the team a list, not a resolution.

Detection and remediation are different problems. Finding a vulnerability tells an engineer where the risk sits. Closing it means producing a correct code change, validating it, and shipping it through review. The first problem is largely solved. The second is where hours disappear and where the backlog forms.

Hyrax works on the second problem with autonomous code review and fixing. It reads the codebase, writes a fix for each security issue it finds, validates that fix, and submits it as a pull request for an engineer to review and merge. Detection tells the team what to fix. Hyrax does the fixing and closes the loop.

How the Fix workflow works#

Hyrax runs security remediation in three steps. Fixes never merge on their own. Every change arrives as a pull request that an engineer reviews and approves before it reaches the main branch.

1. Find. Hyrax reviews the full codebase and surfaces security issues wherever they live.
2. Fix. Hyrax writes a fix and verifies it against tests and the build before proposing it.
3. Ship. Hyrax submits the fix as a pull request for an engineer to review and merge.

Each step gets its own treatment below.

Find: scanning the codebase for security issues#

Find means Hyrax reviews the whole codebase for security issues, not just the lines changed in a recent commit. Most scanners run against diffs or gate a pull request, which leaves older code that predates the tool unreviewed. Hyrax reads the existing files as they stand, so a vulnerability introduced two years ago gets the same attention as one written this morning.

Breadth comes from how the review runs. Hyrax traces how data moves through the code, so it catches issues that span multiple files rather than flagging single lines in isolation. An unsanitized input in one module and a query builder in another become a single finding when the path between them is unsafe. Diff-scoped tools miss that path because they only see the one file that changed.

Hyrax reviews all code the same way, whether an engineer wrote it or a coding assistant generated it. Machine-written code carries the same injection, authentication, and secret-handling risks as hand-written code, and it enters the codebase faster. Reviewing by origin would leave gaps, so Hyrax reviews by content instead.

Each finding carries the context needed to act on it. Hyrax records the file, the vulnerable pattern, and the data path that makes it exploitable. That record is what the fix step reads from. A finding without that context produces a guess, and a guess cannot be verified before it reaches an engineer.

The find step exists to feed the fix step. A precise, whole-codebase finding gives Hyrax enough to write a change that addresses the actual cause rather than the symptom. The next step turns that finding into a verified fix.

Fix: writing a verified fix#

A suggested patch and a verified fix carry different weight in review. A suggestion tells an engineer where the problem is and offers a possible change, leaving the work of confirming it correct. Hyrax generates the fix, then runs it against the existing test suite and the build before any human sees it. The pull request that arrives has already passed those checks.

Verification is what makes the fix fast to review. The engineer reviewing the PR is not confirming whether the code compiles or whether tests still pass. Hyrax has done that. The engineer reads the change to confirm the intent matches the codebase and the fix fits the surrounding logic, which is judgment work a machine should not decide alone. The mechanical checks that usually slow a security review are already complete.

This step covers the vulnerability classes engineering leads worry about most. Hyrax writes fixes for injection flaws, broken authentication and authorization paths, exposed secrets, and vulnerable or outdated dependencies. Each fix targets the specific finding rather than a broad rewrite, so the change stays small and the diff stays readable.

When a fix cannot pass verification, Hyrax does not submit it. A change that breaks the build or fails a test never reaches a pull request, which keeps the review queue free of noise. The engineer sees fixes that already work, not proposals that need debugging first.

That verification loop is the difference between a remediation tool that generates more work and one that removes it. A scanner surfaces a finding and hands it to a person. Hyrax closes the finding with a change that has already proven itself against the code it touches, leaving the engineer a clear decision to merge or revert.

Ship: submitting a pull request for review#

Every verified fix arrives as a standard pull request in the repository, not a dashboard alert or an auto-applied patch. Hyrax pushes a branch, writes a description of the security issue and the change, and submits the PR to the existing review process. An engineer reads it the same way they read any teammate's PR.

The engineer sees the exact diff, the vulnerability class it addresses, and the verification results attached to the change. They approve, request changes, or close it. Merge authority stays with the human, because the person accountable for the code decides what ships. Hyrax never merges a fix on its own.

Keeping the handoff in git matters for a mechanical reason. A pull request runs through the same branch protections, required reviews, and status checks the team already enforces, so a Hyrax fix inherits those controls without special handling. Checkmarx describes the same boundary in its own remediation flow, where automated agents generate merge-ready pull requests but "developers review and merge each fix" (DevOps Digest).

A git-native fix is reviewable, revertible, and traceable. The reviewer can inspect the change line by line, the commit history records who approved it, and a single revert undoes it if something looks wrong after merge. That fits how teams already ship code, so adopting Hyrax adds a contributor to the workflow rather than a new console to check. The fix moves through the pipeline the team trusts, and the engineer keeps final say over what reaches the main branch.

Security is one of six review domains#

Security remediation is one part of what Hyrax reviews and fixes. The same Fix workflow that finds a security issue, writes a verified fix, and submits a pull request also covers correctness bugs that break behavior, maintainability problems that slow the next change, performance regressions that show up under load, architectural drift that accumulates across services, and operational gaps that surface in production. Each domain runs through the same review and fixing process, so a security fix and a correctness fix arrive as the same kind of reviewable pull request.

Placing security inside that broader scope matters for engineering leads weighing another point tool. Hyrax reviews all code across all six domains rather than bolting a single-purpose scanner onto the stack. The security work described on this page is the focus here, but it runs on shared infrastructure that also closes issues a security scanner would never flag.

Complementing Snyk, Checkmarx, and Semgrep#

Snyk, Checkmarx, and Semgrep are strong at detection. They scan the codebase, rate severity, and rank findings by exploitability so the most dangerous issues rise to the top. That detection is where a scanner's job ends and a backlog of unfixed findings begins.

The division of labor is clean. A scanner tells the team which issues exist and which ones matter most. Hyrax reviews the same code, writes the fix, verifies it against tests and the build, then submits a pull request for an engineer to review. Detection and prioritization stay with the scanner. Writing and shipping the fix moves to Hyrax.

Teams keep their existing scanner stack. Hyrax does not ask anyone to replace Snyk, Checkmarx, or Semgrep, and it does not compete with the scan they already run. It works in the same repositories and the same pull request workflow the team uses now, closing the same classes of issues the scanners raise.

That split matters most where remediation work piles up. A scanner can surface hundreds of issues in a single run, and each one still needs a human to triage, patch, and validate before it merges. Hyrax closes that gap by drafting the fix and proving it works, so the engineer spends review time on approval rather than authoring. The scanner finds the problem. Hyrax fixes it.

Built for trust: how fixes stay safe to ship#

Every fix Hyrax writes runs through model infrastructure on AWS Bedrock, and no customer code is used to train those models. The codebase stays inside the account boundary where it already lives. Bedrock handles the model calls without routing source into a shared training set, so proprietary code is not absorbed into a general-purpose model that other users could reach.

That data policy matters most when paired with the review step. Hyrax generates a fix, verifies it, and submits it as a pull request. It does not merge the change. An engineer reads the diff, checks the reasoning, and approves the merge, which keeps policy control and traceability with the team rather than the tool.

The never-auto-merge rule is the anchor for both concerns. Because every fix arrives as a normal pull request, each change carries a full audit trail of what was found, what was written, and who approved it. A reviewer can reject a fix, request a change, or revert it after merge using the same git history already in place.

Engineering leads evaluating remediation tooling tend to check three things before adoption. Where the models run, whether their code trains anything, and who holds merge authority. On all three, the answer is the account boundary, no training on customer code, and the engineer.

Find. Fix. Ship. Close.#

Hyrax finds security issues across the codebase, writes a verified fix, and submits a pull request for an engineer to review. Fixes never auto-merge. The existing scanner stack stays in place, and Hyrax closes the findings.

Engineering leads and CTOs evaluating remediation tooling can start free at hyrax.dev.

Hyrax makes your code better. Ship clean code.