Copilot Autofix for Azure DevOps Adds Agentic Dependency and Third-Party Scanner Fixes

What actually changed​

Autofix launched in limited public preview in June 2026. It analyzed CodeQL code scanning alerts and suggested targeted fixes, creating a pull request automatically. Microsoft's blog says the early version was limited to a scoped set of CodeQL rules. Three things are new:

• An agentic foundation. The Copilot coding agent can explore relevant repository context, review and refine its proposed changes, and open a pull request with a suggested fix.
• Third-party scanner alerts. Autofix now supports fixes for code scanning alerts from CodeQL and third-party scanning tools.
• Dependency vulnerability fixes. Open a supported dependency alert and select Generate fix. Autofix can then open a pull request with a suggested change and an explanation.

Microsoft's announcement doesn't list which third-party scanners or which dependency alerts are supported. Don't assume universal coverage. Microsoft's dependency scanning documentation does say the feature doesn't support malware findings in the Autofix path. That detail comes from Learn, not the blog.

Repository context: the practical hook​

The agent can use custom instructions and skills in supported .github or .agents locations. Microsoft's examples are:

• An instruction that tells the agent to use your approved input-validation helper.
• A dependency-update skill that documents your package-update procedure and compatibility checks.

Microsoft says this context helps suggested changes follow a team's coding standards, architecture, and remediation patterns. That is a goal, not a guarantee. A fix that compiles but ignores your internal conventions still costs you review time. The gap between "generic patch" and "patch that fits our repo" is where this feature will be judged.

In practice, it means your repository guidance files now affect security remediation. If your team has a documented way to bump packages, such as pinning rules or a required test suite, writing it down in a supported location is the lever Microsoft is giving you.

Triaging dependency alerts before you spend credits​

Autofix consumes AI credits, so choosing which alerts to send it matters. Microsoft pairs the launch with two triage signals.

EPSS percentile. The Exploit Prediction Scoring System estimates how likely a vulnerability is to be exploited in the wild. A higher percentile means a higher relative rank for predicted exploitation likelihood. It is not the probability that someone will attack your application.

Dependency scope. Alerts can be flagged as runtime or development-only. A Development badge and a Scope filter show which is which.

Microsoft's suggested triage pass combines the Runtime scope filter with a high EPSS percentile range. Then weigh severity and your application's exposure before picking an alert for Autofix.

Microsoft Learn adds some limits worth knowing:

• Scope metadata appears only when the scan result includes it. The documentation also notes that scope applies to the specific dependency result, not to the package globally, so the same package can have different scopes in different dependency paths or projects.
• EPSS data isn't available for every advisory. A missing percentile doesn't change the alert's severity, state or remediation guidance.
• The Alerts page can filter by branch, pipeline, package, severity, dependency scope and EPSS percentile. The EPSS range boundaries are inclusive and combine with other filters.

Availability: read this part carefully​

The announcement says agentic Autofix will roll out over the next two to three weeks. If your organization is already enrolled in the limited public preview, you can request a fix from a supported dependency or code scanning alert. Public preview is planned for November.

The Sprint 280 release notes are more cautious. They say Autofix remains in limited public preview and that Microsoft isn't accepting additional participants right now. Those notes confirm the agentic foundation, repository context and third-party code scanning support. They don't mention dependency Autofix. The dependency claim and the November timeline come from the October 21 blog post, though Microsoft's current Learn documentation also describes agentic remediation for dependency alerts.

This is not generally available, and not everyone can switch it on today.

Setup and prerequisites​

Autofix acts on findings that already exist. It is not a scanner. Microsoft's documentation lists these prerequisites:

• Code scanning or dependency scanning must be configured and producing alerts, with at least one supported alert.
• The user who selects Generate fix needs the Advanced Security: view alerts repository permission.
• Dependency scanning requires either GitHub Advanced Security for Azure DevOps or the standalone GitHub Code Security for Azure DevOps. A scan must also run, either through the AdvancedSecurity-Dependency-Scanning@1 pipeline task or through default setup. Enabling Advanced Security doesn't run it automatically.

On enabling Autofix, you can enable Copilot Autofix at the organization, project, or repository level. Microsoft's configuration docs describe selecting Autofix for security alerts and then Apply. The same setting covers both alert types. Enabling it doesn't configure scanning or generate fixes automatically, and generating a fix consumes AI credits. Microsoft's blog says you then pick the individual alerts at repository level.

The workflow, step by step​

1. Confirm that scanning is running and producing alerts.
2. Triage dependency alerts: filter to Runtime scope and a high EPSS range, then weigh severity and exposure.
3. Open a supported alert and select Generate fix.
4. Wait for the agent to work in the background and open a pull request.
5. Review the full diff and the explanation. Run your build and tests.
6. Merge through your normal pull request process.
7. For dependency fixes, run dependency scanning again. An alert is automatically marked Closed when the vulnerable component is no longer detected in the latest build for the pipelines where the task is installed.

Step 7 matters. A merged pull request is not proof the vulnerability is gone. The rescan is.

Caveats and open questions​

• Not every request yields a fix. Microsoft says so directly. It doesn't explain why requests fail, and it doesn't publish credit rates.
• Transitive dependencies are tricky. Microsoft's own documentation says fixing a vulnerable transitive dependency usually means explicitly overriding the version for each affected direct dependency. Whether the agent handles those cases well is something the announcement doesn't claim or demonstrate. Test it on a low-risk repo first.
• AI credits are a budget line. Because each fix request consumes credits, triage is a cost control as well as a security practice.
• Human review stays mandatory. The blog tells preview users to review the diff, run builds and tests, and verify changes before merging.

Why it matters​

InfoQ described the original launch as part of Microsoft's effort to close the feature gap between GitHub and Azure DevOps. The new release continues that effort. The shift is from alerts you have to fix by hand to alerts that arrive with a candidate pull request. For teams that live in Azure Repos, that matters because remediation is usually where security backlogs stall.

The skeptical view is fair too. The tool doesn't remove the need to understand your dependency graph, and it won't close a vulnerability by itself. Its value will depend on how well the agent follows your repository guidance, how often it returns usable fixes, and what the credits cost at scale. Microsoft hasn't published data on any of those yet.

If you're in the limited preview, start with a small set of runtime, high-EPSS dependency alerts and add instruction files that describe your update process. If you're not, wait for the November public preview and use the time to get scanning running and your repository conventions documented.