Trackr.Live The landing site for Trackr Services
§ Trackr.Live

STIG Manager

The first thing to get straight about STIG Manager is what it doesn’t do: it doesn’t scan anything. It runs no checks against a target, evaluates no rules against a live host, produces no assessment results of its own. Calling it a scanner, which people do constantly, gets the whole tool backwards. STIG Manager is the layer that sits after the scanners. It ingests their output, holds it, tracks who reviewed what and whether the result was accepted, and becomes the auditable system of record for an information system’s STIG posture. That distinction is the entire point of the tool, and it’s the thing most people miss when they first hear the name.

Conceptual console aggregating many checklist documents from several feeder sources into a single tracked review board.

It’s open-source, and it’s government-built. STIG Manager OSS comes out of the U.S. Naval Undersea Warfare Center Division Newport (NUWCDIVNPT), released under a DoD open-source initiative and sponsored through the NAVSEA Warfare Centers. The home is github.com/NUWCDIVNPT/stig-manager, with container images on Docker Hub under nuwcdivnpt/stig-manager. There is no vendor here. No license to buy, no support contract behind a phone number, no account rep. That cuts both ways, and I’ll get to the cost side of it.

Version and licensing reality

As of late May 2026 the current release is 1.6.10, shipped May 12, on an actively maintained 1.6.x line. Point releases land often, so pin against the release number rather than any sense of “the latest.” The recent line tells you something about how the project handles itself: 1.6.8 (April 14) fixed a reflected XSS in OIDC error handling, and 1.6.9 (April 27) added guards to stop elevated requests from modifying collection settings. Security fixes get cut and shipped quickly. That’s a healthier signal than most government FOSS.

Licensing is dual and slightly unusual. Most of the project is MIT. The web client specifically is GPL v3, because it carries the ExtJS 3.4 framework, which is GPL. If you’re repackaging or redistributing, that split matters and it’s easy to miss when you skim the LICENSE file. The API and the client are not under the same terms.

One thing the page has to be honest about, because the name invites the assumption: STIG Manager holds no FedRAMP authorization and sits on no DoD APL. It can’t. It’s software you stand up yourself, not a service somebody operates for you or an appliance that goes through a product evaluation. FedRAMP and the APL are categories for SaaS and for vendor products, and neither applies to a thing you self-host. The DoD connection is origin and sponsorship, not a certification. If you see a deployment claiming STIG Manager is “FedRAMP authorized,” someone has confused the tool with the boundary it’s running inside.

Where it sits in the chain

The cleanest way to understand STIG Manager is by what feeds it and what it feeds.

Stage What it is Artifact Who runs it
STIG / SRG library DISA’s published benchmarks and rule content XCCDF benchmarks DISA publishes; you load current content
Evaluate-STIG, SCC The actual evaluation engines .ckl / .cklb / XCCDF results Engineers / automation on the endpoints
STIG Manager Aggregation, review workflow, system of record imports results, exports checklists ISSO/ISSE team on a self-hosted instance
eMASS The ATO package and authorization record POA&M, assessment state Package owner, into the RMF process

Read top to bottom, that’s the flow. The STIG definitions come from DISA. The evaluation happens upstream in Evaluate-STIG and the SCAP Compliance Checker, or by hand in DISA’s STIG Viewer. Those tools produce CKL, CKLB, or XCCDF. STIG Manager parses all three, lands them against the right asset, and tracks the result through a review. Downstream, the assessment state it holds gets carried into eMASS as part of the ATO package. STIG Manager is the middle. It’s the place the raw scanner output stops being a pile of files and becomes a tracked, reviewable record.

What it actually does

Collections are the top-level organizing unit, and the design choice that matters most: a Collection can be drawn to mirror an RMF package boundary, so the tool’s structure lines up with the system you’re authorizing. Inside a Collection you build an asset inventory, assign the relevant STIGs to each asset, then work reviews. The review workflow has two roles that do real work, Evaluator and Validator, with an Accept/Reject step on validation. The UI marks where each review came from, whether it was automated, entered manually, or supplied through an override or answer file, so an assessor can see how a given result was produced.

There’s a bulk Collection Review workspace for evaluating one Rule across every asset at once, which is how you actually clear a finding that spans a fleet instead of clicking through hosts one at a time. Exports go back out to CKL and CKLB, and toward POA&M-style artifacts for the package. The import parsers are the load-bearing feature, and also the fiddly one. When a scanner emits slightly off-spec CKLB, the parser path can get cranky, and tracking down which tool produced the malformed file is its own small chore.

Deeper: why the Collection-as-boundary and the two-role split exist.
The Collection mapping to an RMF package isn’t cosmetic. It means the unit you assess and the unit you authorize are the same object, so the export you hand toward eMASS already matches the boundary in the SSP. The Evaluator/Validator separation is there for the same audit reason. Whoever runs a check is not automatically the person who accepts its result, which mirrors the evidence chain a CCRI or CORA wants to see: the assessment was performed, then independently validated, with both steps recorded against the same artifact. The tool is shaped this way because the inspection is shaped this way. If you flatten the roles to move faster, you’ve thrown away the thing that made the record defensible.

Authentication, and the headache that comes with it

Auth is OAuth2 / OIDC. Keycloak is the reference identity provider in the sample orchestration, but it is not a hard dependency; any OIDC provider works, and the docs say it has been tested against Keycloak, Okta, and Azure Entra ID (AzureAD). Configuration is provider-agnostic: STIGMAN_OIDC_PROVIDER (and the client-side STIGMAN_CLIENT_OIDC_PROVIDER) point at your issuer, and STIGMAN_JWT_PRIVILEGES_CLAIM names the token claim that carries privileges, defaulting to realm_access.roles. Privileges ride in the claim you point that variable at, which means your IdP, not STIG Manager, is where authorization actually gets decided.

Here’s the operational pothole worth flagging up front. CAC authentication on Keycloak 24+ has known breakage, documented in the project’s own discussions, and the create-user.jar helper that some CAC setups leaned on is tied to an out-of-date keycloak-cns-authenticator and doesn’t play with newer Keycloak. People have worked around it by provisioning users manually or wiring LDAP/AD user federation instead. If your plan was “stand up Keycloak, plug in CAC, done,” budget more time than that. The reference orchestration gives you a starting point, but the IdP plumbing is yours to own end to end.

Honest complaints

No commercial support is the big one. When OIDC breaks at 2 a.m. before an assessment, there’s no vendor to call. You read GitHub discussions and you fix it yourself. The CAC-on-Keycloak-24+ friction above is a live example of exactly that. STIG Manager also only reflects the STIG content you’ve loaded into it, so a stale library quietly produces stale assessments against benchmarks DISA already superseded. And it manages assessment state without remediating anything. It will tell you a host is failing CM-6 all day long; closing the finding still happens out on the endpoint, by hand or by your config-management tooling. None of that makes it a bad tool. It makes it a specific tool, and treating it like a one-box compliance solution is how teams get disappointed.

Control ties

The strongest tie is CM-6. STIGs are configuration-settings evidence, and STIG Manager is where that evidence is aggregated and tracked, which puts it squarely against the CM family. After that come CA-2 and CA-7. It’s the place the continuous-monitoring assessment state lives between formal events, which is most of what CA-7 is asking for, and the validated, accepted results it records are exactly what CA-2 wants to see. The open findings it carries feed the POA&M, so there’s a clean CA-5 angle too. RA-5 is a lighter touch, since STIG Manager tracks config compliance rather than CVE scanning, so call that fit partial and move on. Forcing SA-11, SA-15, or the SR family onto this tool would be a stretch; it isn’t a developer-testing or supply-chain instrument, and a control mapping that claims otherwise is padding.

If you remember one thing: STIG Manager earns its keep as the auditable point where scanner output becomes a defensible record, not as an assessment engine. Judge it on whether the evidence survives an inspection, because that’s the job it was built for.

Sources

Adjacent material on this site