Attack Surface Analyzer: diffing a Windows or Linux system before and after an install
Attack Surface Analyzer can help you analyze your operating system's security configuration for changes during software installation.
At a glance
- What is it?
- Microsoft's C# tool snapshots file system, registry, services, ports, certificates and more into local SQLite databases, then diffs two runs to show what an installer changed. It is built for auditors and DevOps engineers who can run it with elevated privileges.
- Who is it for?
- Adopt Attack Surface Analyzer if you audit third-party installers on Windows or Linux and can run collection as Administrator or root on a controlled machine. Do not adopt it as a continuous monitoring agent: the README describes snapshot and diff workflows, not a background service, and the data lives in local SQLite files you must manage yourself.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 59 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The installer trust problem Attack Surface Analyzer was built for
Most software installers ask for elevated privileges, and once those privileges are granted the installer can change things the user never sees: a new service, a listening port, a certificate in the machine store, a registry key that alters how other programs launch. The README puts the point plainly: "most installation processes require elevated privileges, and once granted, can lead to unintended system configuration changes." Attack Surface Analyzer exists to make those changes visible by comparing the state of the operating system before and after.
The README names two audiences. DevOps engineers who want to see what their own software changes on a target system, and IT security auditors who need to evaluate the risk of third-party software. Both share a precondition that shapes everything else: you must be able to take a snapshot before the install, and the tool must run with Administrator rights on Windows or as root on Linux. If you cannot control the machine at both points in time, the tool has nothing to diff.
Snapshot, collect, diff: the two-run model
The core feature is described as the ability to "diff" an operating system's security configuration before and after a software component is installed. The workflow is two collection runs and one comparison. Each run writes to a set of local SQLite databases; nothing is uploaded anywhere by default, which matters when the snapshot contains user accounts, certificates and cryptographic keys.
The README lists the components reported on: file system (with both a static snapshot and live monitoring), user accounts, services, network ports, certificates, registry, COM objects, event logs, firewall settings, WiFi networks, cryptographic keys, processes and TPM information. That list is the real scope of the tool, and it is also its boundary. A change that does not fall into one of those collectors will not appear in the diff, no matter how interesting it is.
On top of the diff, the tool can "run arbitrary complex rules on the results to surface interesting findings." The 2.3 line adds a Blazor GUI with rule authoring and a testing sandbox, new collectors, and what the release notes describe as improved collection and analysis performance. Rules are the part that turns a long list of changed files into a short list of things worth reading.
Installing the CLI and running your first before/after diff
The README gives two distribution paths. If you have the .NET SDK installed, the tool installs as a global .NET tool:
dotnet tool install -g Microsoft.CST.AttackSurfaceAnalyzer.CLIPlatform-specific binaries are also published on the GitHub releases page. On Linux, the README warns that .NET's Linux dependencies must be present; some distributions do not include them by default. The README also points to the .NET Docker image base for container use, installing the tool from NuGet inside the Dockerfile with `RUN dotnet tool install -g Microsoft.CST.AttackSurfaceAnalyzer.CLI`.
Collection must run in an Administrator shell, or as root on Linux. The README says to replace `asa` with `asa.exe` where appropriate for your platform. To run every collector in one pass:
asa collect -aDo this once on a clean machine, install the software you are auditing, then run the same command again. To compare the two most recent runs:
asa export-collectThat last command is the whole point of the exercise: it compares the last two collection runs. For anything else, `asa --help` lists the available commands. If you prefer a browser interface, the README says `asa gui` opens a window at `http://localhost:5000` with the web-based interface, which is where the rule authoring and testing sandbox live.
Where the tool stops being the right choice
The README does not document rollback, and it does not describe a background service or an agent that keeps watching a host. The model is discrete runs and a comparison of the last two. If your question is "what is this server exposing right now, continuously", Attack Surface Analyzer answers a different one. Live monitoring exists for the file system collector, but the README does not describe a supported always-on deployment pattern, and treating the tool as one would be an assumption the documentation does not back.
There is a second constraint in the architecture: all collected data is stored in local SQLite databases. That is good for confidentiality and bad for fleet-scale work. Comparing a hundred machines means moving or querying a hundred SQLite files yourself, and the README does not describe a central aggregation path. If you need cross-host correlation out of the box, this is the wrong layer.
A third limitation is scope by construction. The diff can only show what the collectors cover. A change in a place none of the listed collectors watches is invisible, and the README gives no method for extending the collector set from the command line. The rules engine works on the results, not on the gaps.
Attack Surface Analyzer compared with a live mapper
People searching for this tool often land on attack surface mapping tools instead, and the difference in approach is worth stating. A mapper enumerates what is exposed on a host or network at one moment: open ports, running services, reachable endpoints. It answers "what can be reached right now."
Attack Surface Analyzer answers a historical question: what changed between two points in time on one machine, and what did the installer do while it held elevated privileges. The unit of output is a diff, not an inventory. That is why it stores two snapshots in SQLite and why the central command is a comparison of the last two runs rather than a scan. If you want an inventory, a mapper is the better fit. If you want to know what an installer quietly added to a machine you control, a single-moment scan cannot tell you, because it has no baseline to compare against.
Licence, maintenance and upgrade cost
Attack Surface Analyzer 2 is licensed under the MIT licence, which is permissive and places few obligations on internal or commercial use. The repository also carries a NOTICE.txt and a CONTRIBUTING.md describing a Contributor License Agreement; contributions require agreeing to the CLA, which is a condition on contributors, not on users. Nothing in the README imposes a support contract, and the README directs security issues to the Microsoft Security Response Center rather than to public issues.
The last push to the repository was on 2026-08-01, and the latest release listed is v2.3.331 from 2026-01-23. Development is focused on the release/v2.3 branch, and the README states that the latest public version with public builds is 2.3. Upgrading is cheap if you installed through the .NET tool, since a global tool update replaces the binary; the real cost sits elsewhere. Collectors can change between releases, and a collector that starts or stops reporting a component changes what your diffs contain. If you compare a baseline collected with one version against a run from another, part of the diff may reflect the tool rather than the software you installed. Pin the version you collect with, and re-baseline after upgrading. The README does not document a compatibility guarantee between collection runs from different versions.
Editorial conclusion
Adopt Attack Surface Analyzer if you audit third-party installers on Windows or Linux and can run collection as Administrator or root on a controlled machine. Do not adopt it as a continuous monitoring agent: the README describes snapshot and diff workflows, not a background service, and the data lives in local SQLite files you must manage yourself. Before relying on it, install the CLI with dotnet tool install -g Microsoft.CST.AttackSurfaceAnalyzer.CLI on a disposable VM, run asa collect -a twice around a single installer, and check that asa export-collect surfaces the changes you already know that installer makes. If the diff misses a change you can observe by hand, the collector set is the thing to question first, not the diff.
Frequently asked questions
How do I install Attack Surface Analyzer?
With the .NET SDK installed, run dotnet tool install -g Microsoft.CST.AttackSurfaceAnalyzer.CLI. Platform-specific binaries are also distributed on the GitHub releases page, and on Linux you may need to install .NET's Linux dependencies first.
How do I use Microsoft Attack Surface Analyzer?
Run asa collect -a in an Administrator shell or as root to run all collectors, install the software you are auditing, run the same command again, then run asa export-collect to compare the last two collection runs.
What is Attack Surface Analyzer?
It is a Microsoft-developed open source security tool that analyzes the attack surface of a target system and reports on potential vulnerabilities introduced during software installation or by system misconfiguration. It works by diffing an operating system's security configuration before and after an install.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/microsoft-attacksurfaceanalyzer)