Microsoft Ships AttackSurfaceAnalyzer v2.3.334 With a Code-Signature Bug Fix and a Copilot Credit
Microsoft's latest maintenance release for its open-source attack-surface tool quietly corrects how it judges Authenticode certificates, and one of the changes was written and reviewed by AI agents.
Microsoft published AttackSurfaceAnalyzer v2.3.334 to GitHub on November 13, 2026. Maintainer Giulia Stocco, known around the repo as gfs, tagged the release as a maintenance build, which is Microsoft's way of saying it fixed things that could bite you rather than added things you'd click on.
The release folds in three pull requests, and the one worth your attention is #763, which corrects how ASA decides when a binary's signature has actually expired. The other two are infrastructure: an upgrade to Microsoft's ESRP code-signing pipeline and a move to a .NET 10.0 runtime target.
Keep in mind that ASA is the kind of tool security teams reach for when they want to know exactly what an installer did to a machine. You scan the system before you install software, scan it again after, and the tool diffs the two to surface changes like new services, opened firewall ports, and writes to protected registry keys. It's MIT-licensed, lives in Microsoft's Security Development Lifecycle family alongside BinSkim and CredScan, and has quietly racked up roughly 3,000 stars on GitHub.
The fix that matters
Here's the bug. ASA's old rules flagged a binary as having an "expired signature" whenever the signing certificate happened to be expired at the moment of the scan. That sounds fine until you remember that Authenticode signatures often carry a timestamp from a signing authority, which keeps a signature verifiable long after the certificate itself has lapsed. So an older but genuinely signed binary would trip the alarm needlessly.
The corrected logic now checks whether the binary was signed during the certificate's validity window, matching how Windows's own WinVerifyTrust actually behaves. The Signature class gains a SigningTime property, a new IsTimeValid check compares signing time against the certificate's NotBefore/NotAfter, and GetSigningTime() was rewritten in Lib/Collectors/WindowsFileSystemUtils.cs. It pulls the Authenticode timestamp three ways: the countersigner info, RFC 3161 timestamp tokens, and the signer's own signed attributes.
For what it's worth, the rewrite is notably cleaner. The method dropped from about 84 lines with five levels of nesting to roughly 40, using .NET's Pkcs9SigningTime type check instead of manual OID string comparisons. Rule authoring in analyses.json now fires on "Binaries with unverified signature validity," whose text reads "The signing time may be outside the validity period or could not be determined," and it only triggers when the binary has a valid Authenticode signature. Unsigned binaries still fall under the existing rules.
This also lines up with defensive-research heuristics (think NCC Group's work on time-stomped binaries) that flag PE files whose timestamp lands outside the certificate window. Reducing false positives here lets analysts triaging a pile of binaries spend less time chasing legitimate ones.
The part that's a bit unusual
This is where it gets interesting. #763 was merged on February 26, 2026, and its authorship tells you something about where Microsoft's own tooling is heading. Per the repo, the fix was authored by a Copilot coding agent, reviewed by a Copilot PR-reviewer agent, then directed and approved by human maintainers. That makes it one of the more visible examples of this repo leaning on GitHub's AI agents for real implementation and review work, not just a snippet here and there.
A follow-up, PR #769 opened July 31, 2026, shows the team is still refining the area. Treat this as shipping, not final.
The other two changes are less flashy. Not unimportant, though. #771 adds a .NET 10.0 target across the projects and updates pipeline configs and dependencies. The tool had already picked up a .NET 9 target back in v2.3.319 and dropped .NET 6 and 7, so this keeps it running on the current runtime.
#772 upgrades the Azure Pipelines ESRP code-signing task to version 6, ensuring the binaries you download are signed through Microsoft's current trusted platform. That's a supply-chain integrity move aimed squarely at the trust you place in the asa executable.
Head here if you want to try it yourself. You install the CLI as a NuGet tool with dotnet tool install -g Microsoft.CST.AttackSurfaceAnalyzer.CLI, or grab platform-specific binaries straight from the GitHub releases page.
One warning that keeps coming up whenever anyone runs this thing: it needs administrator or root privileges and it hammers CPU and disk I/O. Don't run it against a live production server. It's a differential auditing tool, so it won't block a malicious process or catch a live anomaly. For that, you'd reach for EDR or SIEM.
The release sits on the release/v2.3 branch, and while the project's main development branch has moved up to 2.4, this stays the line with public builds. Given how Microsoft's recent releases have focused on internal hardening rather than shiny new features, v2.3.334 is a reminder that the mature tools sometimes do the most valuable work under the hood.
