DEV Community

agentic autofix needs evidence, not applause

GitHub put agentic autofix for code scanning alerts into public preview this month, and it is exactly the kind of feature that sounds small until you imagine it touching a real backlog.

Code scanning used to give you an alert.

Now the tool wants to explore the repository, work across files, propose a fix, rerun the original analysis, and open a pull request.

That is not just "faster remediation."

That is AppSec crossing from detection into change management.

the security alert has a pull request now

I like this direction, with the usual amount of fear in my eyes.

Security teams have lived for years with the world's least romantic queue: findings, duplicates, false positives, stale alerts, "we will fix it next sprint", and the immortal ticket assigned to someone who left the company in 2023.

So yes, a tool that can turn a code scanning alert into a reviewable pull request is useful. Very useful.

But the interesting part is not that Copilot can write a patch.

The interesting part is that the scarce skill moves.

Before, the scarce skill was often "can we understand and prioritize the alert?"

After agentic autofix, the scarce skill becomes "can we trust this remediation enough to merge it?"

That is a different job.

the alert was annoying, but at least it was honest

A static analysis alert is irritating in a very simple way. It says: "I found a pattern that may be dangerous."

Sometimes it is right. Sometimes it is nonsense. Sometimes it is technically right and operationally useless, which is the AppSec version of being stuck in a meeting with a spreadsheet.

But an alert has a clean boundary. It points at a potential problem.

A generated fix has a bigger blast radius.

It can change control flow. It can move validation. It can add escaping in the wrong layer. It can silence the scanner without fixing the actual vulnerability. It can make a test pass while changing behavior that was never tested because the legacy system was held together with vibes and one senior engineer's memory.

This is not an argument against autofix.

It is an argument against treating generated remediation as a magical cleanup button.

Security fixes are not only code changes. They are claims about risk.

If the tool opens a PR, the PR should carry those claims clearly.

generated security prs need evidence bundles

The mature version of agentic autofix is not "here is a diff, good luck."

The mature version is an evidence bundle.

A good security autofix PR should answer boring questions in plain language:

  • What vulnerability class was detected?
  • What input or state made it exploitable?
  • What files and data paths did the agent inspect?
  • Why is this remediation scoped to these changes?
  • Which analysis was rerun?
  • Which tests were added or updated?
  • What behavior might still be risky?
  • What did the agent not verify?

That sounds like paperwork.

It is.

Security is partly paperwork because humans need to build trust across teams that do not share the same context. The application team knows the weird code path. The security team knows the vulnerability class. The platform team knows how scanning is wired. The reviewer knows the change may wake them up later.

A generated PR has to be legible to all of them.

show your work, tiny robot

Without the evidence, the reviewer has to reverse engineer the agent's reasoning from the diff. That is not automation. That is outsourcing the confusing part to a human with less time.

Congratulations, we made the queue shorter and the review harder.

Very modern.

rerunning the scanner is necessary, not sufficient

GitHub says agentic autofix reruns the original analysis to confirm the alert closes before opening the pull request.

That is good.

It is also the floor.

Closing the original alert proves the scanner no longer sees the same shape. It does not prove the system is secure. It does not prove the fix belongs at the right abstraction layer. It does not prove the change handles adjacent inputs. It does not prove the application still behaves correctly.

This is where teams get into trouble with any automated remediation tool.

The machine optimizes for the detectable condition. The product carries the real-world behavior.

Imagine a SQL injection alert. A bad fix can parameterize one query and leave the actual untrusted path open somewhere else. A worse fix can escape strings manually because it makes the pattern disappear. A very cursed fix can add validation that blocks valid customer data because nobody wrote a test for the angry customer with a quote in their surname.

The scanner is a useful witness.

It is not the judge.

For serious vulnerabilities, I want a small test that fails before and passes after. I want the changed boundary explained. I want the agent to say whether it found similar patterns elsewhere. I want the reviewer to see what was intentionally left alone.

This is normal engineering discipline.

The only new part is that the first draft came from a tool.

appsec becomes review design

Agentic autofix will probably make some security programs look better in dashboards.

Fewer open alerts. Faster mean time to remediation. More security PRs created. A cleaner executive chart. Everybody loves a chart until it asks for nuance.

But the real metric is not how many alerts got patched.

The real metric is how many risky changes were safely understood, reviewed, merged, and kept healthy afterward.

That means AppSec has to care about review.

What should an autofix PR look like? Who is allowed to trigger one? Should high-risk fixes require security review plus code owner review? Should the agent be allowed to edit tests? Should it touch authentication code? Should it change dependencies? Should it open one PR per finding or group related findings in a campaign?

These questions sound procedural because they are.

That is where production safety lives.

The same feature can be excellent in one organization and chaos in another. A team with clear ownership, good tests, and reviewers who understand the affected code can absorb generated security PRs. A team with weak tests, overloaded reviewers, and twenty services nobody owns will just create a more efficient machine for generating false confidence.

Automation does not remove ownership.

It finds out whether ownership was real.

the review queue after the agent discovered alerts

security review is moving left and sideways

GitHub also added security reviews in the Copilot app through a slash command for in-flight code changes.

That pairs nicely with agentic autofix. One feature tries to fix known alerts. The other tries to catch high-confidence issues while code is still being written.

This is the part I find useful: security is getting closer to the work loop.

Not in the old "shift left" slogan way, where everyone repeats the phrase until the developer inherits six more tools and a guilt dashboard.

I mean literally closer to the work loop.

The IDE, CLI, code scanning alerts, pull requests, and review comments are starting to become one security surface. That is powerful because context is nearby. The diff is fresh. The author still remembers what they were doing. The fix can land before the finding becomes a fossil.

But it also means security automation is entering the same messy place where normal software decisions happen.

Half-written code. Experimental branches. Weird mocks. Deleted tests. Local assumptions. Deadlines.

So the tooling has to be humble.

It should say what it knows, what it checked, and what it did not check. It should preserve context for humans instead of pretending the human is just a merge button with a salary.

the punchline

Agentic autofix is a good feature because security teams need help with remediation, not just alert production.

But the useful future is not a robot silently cleaning the backlog while everyone applauds.

The useful future is generated remediation with evidence: clear scope, tests, analysis results, affected paths, remaining uncertainty, and ownership.

If a tool can open a security PR, it should also help the reviewer understand why the PR is safe to merge.

Otherwise we are not reducing risk.

We are just converting security alerts into code review debt with better branding.

And honestly, we already had enough debt. It came with free dashboards.

references

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

Top comments (0)