Pathwarden for auditors

What to ask for

Four artifacts that tell the whole story

The HTML report

One self-contained file: the accounts with an attack path to Tier Zero, Tier Zero protected, every finding with its attack path, and the remediation path. Check its Collection tab for collection completeness first: a collection that missed sessions and local groups understates the risk, and a Quick one says Not targeted.

A signed evidence pack per fix

Before and after for each remediated finding, the run history, hashes of the collector files, and an Ed25519 signature over the manifest. A redacted pack proves the fix without a single account or domain name.

The trend

pathwarden history: accounts with a path, exposure, Tier Zero protected, open findings, new and fixed per scheduled run. It shows whether the program is working, not only whether one fix landed.

The accepted risks

Each has a written reason, ideally with a change number, who accepted it and when, and an optional review date, after which the finding counts as open again. A short list of dated, explained exceptions is a sign of control.

Verify it yourself

Check a pack in one command

The team publishes its signing key's fingerprint once, out of band: in the statement of work, a signed email, or read out on a call. Every pack is then checked against it. Any change to any byte of any file fails verification.

Exit 0, Verified: valid signature from the expected key, every file matches.
Exit 1, Not verified: a file was changed, added or removed, or another key signed it. Each problem is listed.
Exit 3, Intact, signer not checked: no fingerprint was given, so it only proves the pack is unchanged.

No Pathwarden at hand? verify_evidence.py, shipped in the Pathwarden repository, makes the same checks with Python 3 alone. The signature is in minisign's format.

PS> pathwarden evidence verify pack.zip --fingerprint SHA256:NSrf3sUN38/MMY7n...
Evidence pack pack.zip
  Signature  valid, made with key SHA256:NSrf3sUN38/MMY7n...
  Files      6 of 6 match the manifest
  Created    Oct 10, 2026, 8:30 AM with Pathwarden 0.1.0
  Shows      1 fixed, 0 still open, 0 can't tell, 0 new, against the state (run 20261003T021500.000Z)

VERIFIED: every file is exactly as signed, by key SHA256:NSrf3sUN38/MMY7n...

Why you can rely on the verdicts

Designed not to overstate progress

"Can't tell" is a verdict

If a domain wasn't collected, the collection is less than half the size of the last one, or it didn't read the sessions and local groups a finding rests on, a missing finding is held open, not marked fixed. A failed or Quick collection never closes a ticket.

Stable finding IDs

Each finding's ID is a hash of its rule and the objects involved. It stays the same while the problem exists, so "open on date A, gone on date B" refers to the same problem.

Severity from exposure

Attack paths are rated by the share of the domain that can use them, using BloodHound Enterprise's bands, with a floor of High for direct domain control. A severity the team set for a rule is marked as theirs, with the default beside it.

Exports and integrations

Into the tools you already use

Findings leave Pathwarden in standard formats, all keyed on the stable finding ID, so the receiving system matches a finding across runs, closes it when it's gone and reopens it if it comes back.

SARIF 2.1.0: pathwarden export sarif, validated against the OASIS schema. Accepted risks carry their justification.
DefectDojo^*: pathwarden export defectdojo, in the Generic Findings Import format, for reimport each run.
Tickets: ServiceNow^* and Jira^* plugins open, update and close one ticket per finding.
PingCastle^*: import its health-check reports, and its findings join the same backlog as PC- hygiene findings.

Shell

pathwarden export sarif      --event event.json -o pathwarden.sarif
pathwarden export defectdojo --event event.json -o pathwarden-dd.json

Every command also takes --json. Tickets and integrations

Good questions for the team

What was the Tier Zero exposure at the start of the period, and now?
How complete was the collection: sessions and local groups for what share of computers?
Which Critical and High findings are open, and who owns each one?
Which risks are accepted, why, and when are they due for review?
Can I verify the evidence pack for each fix you're claiming?

Controls you can test

Hygiene findings that map to common audit controls

Stale and over-privileged accounts, password age, local administrator password management and account protection. Each article explains the risk and links to Microsoft's guidance.

"We fixed it" is a claim. This is evidence.