Why it exists
STIG releases can land as dense XML and documentation deltas. That is usable for authoritative compliance tooling, but slow for an analyst who needs to answer a practical question quickly: what changed, what matters, and what needs review?
STIGPilot keeps that review step small. It compares release content and produces a short change brief, manager summary, backlog export, and reviewer checklist before anything becomes a ticket.
What it optimizes for
- Added, removed, and modified controls
- Severity, check text, fix text, CCI, and reference changes
- Analyst review before ticket creation
- Local output that can be inspected without sending host or environment data anywhere
What it refuses to be
STIGPilot is not a scanner, not a compliance authority, and not a replacement for DISA tooling. It is a triage layer: useful when a team needs to understand release movement before assigning remediation work.
Proof path
pip install stigpilot
stigpilot diff v2r9 v2r10 --ticketThe strongest version of the story is not “this parses XML.” It is “this changes the work shape.” Instead of dumping a raw delta on reviewers, it creates a smaller set of artifacts: brief, backlog, checklist, and ticket-ready rows.
Next refinements
- Publish more sample outputs with sanitized fixture data
- Add a short walkthrough that shows one control moving from release diff to review checklist
- Keep the PyPI, GitHub, and portfolio language aligned so the tool reads as maintained, not just posted