If you're working on a DoD system and you need to get to an ATO, there's a set of free tools from DISA and the open source community that most ISSOs and system administrators use. They're genuinely useful. They're also not enough on their own, and understanding why is worth your time before you end up six weeks from an assessment realizing you've been maintaining two disconnected pictures of your compliance posture.
This article walks through the main free tools, what each one actually does, and where the gaps are that tend to cause problems.
The free tools you probably already know
There are five tools that come up most often when DoD programs try to handle STIG compliance without spending money on a platform: STIG Viewer, the SCAP Compliance Checker, OpenSCAP, STIG Manager, and OpenRMF. Each one solves a specific part of the problem. None of them solves all of it.
STIG Viewer
What it does
STIG Viewer is a Java-based desktop application from DISA that lets you open STIG checklists (.ckl files), step through each requirement, and manually mark findings as Open, Not a Finding, Not Applicable, or Not Reviewed. It's the standard tool for manual STIG assessments and it works reasonably well for that specific task.
It can import results from SCC scans, which saves you from marking automated checks by hand. It produces CKL files that are the accepted artifact format for manual checklist reviews. Most ISSOs have used it. Most ISSOs have also spent a lot of time in it.
Where it stops
STIG Viewer is a single-checklist, single-user, single-machine tool. There's no shared state. If two people on your team are working on different checklists for the same system, you're coordinating by emailing CKL files back and forth and hoping nobody overwrites anyone else's work. There's no history, no audit trail of who changed what and when, and no way to see your overall compliance posture across multiple checklists at once. Every new STIG version means starting that manual tracking work over again.
For a single component being assessed once, it's fine. For a system with multiple components going through continuous monitoring, it becomes a file management problem that compounds over time.
SCAP Compliance Checker (SCC)
What it does
SCC is DISA's automated scanning tool. It takes SCAP content (the machine-readable version of STIGs) and runs it against a system, checking configuration settings, registry values, file permissions, and other technical controls automatically. The scan produces XCCDF results files and HTML reports that show which checks passed, which failed, and which couldn't be assessed automatically.
For large checklists with many automated checks, SCC is genuinely valuable. Running SCC against a Windows Server STIG will handle a significant portion of the checklist without manual review. That's real time savings.
Where it stops
SCC only checks what SCAP content covers, and SCAP content doesn't cover everything. Many STIG requirements are manual checks that require human judgment: reviewing documentation, inspecting configurations that can't be evaluated by a script, interviewing administrators. SCC marks these as "Not Reviewed" and they stay on your plate.
SCC also produces output, not tracking. After you run a scan you have a results file. What you do with that file, how you reconcile it against your POA&M, how you track remediation, how you compare it to last month's scan to see what changed, none of that is SCC's job. That work falls to whoever is managing compliance for the program.
OpenSCAP
What it does
OpenSCAP is an open source implementation of the SCAP standard maintained by Red Hat. It does essentially what SCC does for Linux and other non-Windows systems: runs SCAP content against a target and produces results. It integrates well with Linux automation tooling and is commonly used in container and pipeline-based environments where SCC doesn't fit naturally.
For programs running Linux components or building STIG compliance into CI/CD pipelines, OpenSCAP is often the right call. It's flexible, scriptable, and actively maintained.
Where it stops
Same fundamental limitation as SCC: it produces scan results, it doesn't manage them. You still need to do something with the output. And for programs that mix Windows and Linux components, you're now running two different scan tools and consolidating their results manually, which adds another layer of tracking work.
STIG Manager
What it does
STIG Manager is an open source web application developed under a Navy project and now maintained on GitHub. It's the most ambitious of the free tools in terms of scope: it's designed to be a multi-user, web-based STIG checklist management system with role-based access, collection management, and reporting. If STIG Viewer is a single-user desktop tool, STIG Manager is the attempt to build something that a whole team can work out of.
For programs with the technical capacity to stand it up and support it, it solves some real problems. Multiple ISSOs can work in the same system simultaneously. Checklists are centralized rather than scattered across desktops. It imports STIG content directly from DISA and handles CKL output.
Where it stops
The gap between the capability and the operational reality of using it is significant. There's no onboarding, no documentation you'd hand to a new ISSO and expect them to be productive in a day, and no commercial support to call when something breaks or when you need help configuring it for your environment. You're on your own with the GitHub issues board and whatever institutional knowledge your team has built up.
The deployment story is also not simple. It requires a server, a database, and someone who can configure and maintain the application. For a program office that isn't staffed with engineers, standing it up and keeping it running is a real ask. And when the person who set it up leaves, you need someone who can figure out what they built.
STIG Manager also doesn't connect to vulnerability management or POA&M workflows. It handles the STIG checklist side reasonably well for teams that can operate it, but you're still building the compliance management layer on top of it yourself.
OpenRMF
What it does
OpenRMF is an open source RMF compliance platform that takes the most complete swing of any free tool at the full compliance management problem. It handles STIG checklists, vulnerability tracking, compliance reporting, and some POA&M functionality in a single application. It ingests STIG content, CKL files, and SCAP results, and it produces compliance dashboards and reports that give you a broader picture than you get from STIG Viewer alone.
On paper it covers more ground than anything else in the free tier. For a program with the technical staff to run it, it's the most capable option without paying for a commercial tool.
Where it stops
OpenRMF runs on Docker. The entire deployment is container-based, which means you need someone who understands Docker, container networking, and how to keep a multi-container application running in your specific environment. In a standard government IT environment this isn't always a given, and in some restricted or classified environments Docker introduces its own approval and security review requirements.
The same support problem applies here as with STIG Manager: no commercial support, no SLA, no one to call. Community support through GitHub and a small active user base means your questions might get answered or they might not, on whatever timeline the contributors have available.
The other issue is operational maturity. OpenRMF is a capable tool built by people who understand the RMF problem, but it's a community project with the reliability profile that implies. Features can be inconsistent across versions, documentation lags behind the codebase, and the upgrade path between versions sometimes requires manual intervention. For programs that need a stable, predictable compliance workflow, that variability is a real operational risk.
Where all of them stop
The pattern across all five tools is the same. They're point-in-time assessment tools. They tell you what the state of a system is at the moment you run them. What they don't do is help you manage compliance over time across a whole program.
Specifically, none of them handle:
- Multi-component visibility. If your system has five components, each with its own STIG checklist, getting a single view of your overall compliance posture requires manually aggregating results from five separate tools or files. There's no dashboard, no rollup, nothing that shows you the whole picture.
- Change tracking. If you ran SCC last month and you run it again today, comparing the two results to see what changed requires doing that comparison yourself. Which findings were remediated? Which are new? Which CAT I items are still open from three cycles ago? You have to figure that out manually.
- POA&M integration. The findings from your scan tools don't automatically become POA&M items. Somebody has to take the scan output, cross-reference it against the existing POA&M, figure out what's new, what's closed, and what changed, and update the document. That's a manual process that has to happen on a recurring basis.
- STIG version management. When DISA releases an updated STIG, Vulnerability IDs can change. If you've been tracking findings by VulnID and the VulnID changes in the new version, your tracking breaks. STIG Viewer doesn't handle that migration for you.
- Audit trail. For an ATO package, you need to be able to show that your compliance posture is accurate and that the data is trustworthy. A CKL file that someone edited in STIG Viewer with no history of who changed what and when is harder to defend than a system with a full audit log.
The gap that actually costs you time
The place where programs lose the most time isn't the scanning itself. The scanning is relatively fast once it's set up. The time sink is everything that happens after the scan: reconciling results against the POA&M, chasing down the status of findings that were supposed to be remediated, preparing documentation for an upcoming assessment, and answering questions from an AO about why a CAT I finding has been open for six months.
That work gets done in spreadsheets. The ISSO maintains a POA&M spreadsheet, somebody else maintains a STIG checklist tracker, and periodically someone tries to reconcile them. It works until the system gets more complex, or the team changes, or the assessment cycle speeds up. Then it stops working and the program scrambles.
The free tools solve the assessment problem. Even the most capable ones, STIG Manager and OpenRMF, leave the program management layer to you. That's two different problems, and conflating them is where programs get into trouble.
The result is that a lot of security time goes into document management rather than actual security work. ISSOs who should be thinking about risk are instead reconciling spreadsheets. That's not a tool problem that any of the free tools were designed to fix, and it's not reasonable to expect them to.
Where CertiField fits in
CertiField isn't a replacement for STIG Viewer, SCC, OpenSCAP, STIG Manager, or OpenRMF. It's built to work alongside them and handle the program management layer that none of them fully covers.
When you run SCC or OpenSCAP, complete a manual STIG Viewer assessment, or export results from STIG Manager or OpenRMF, that output comes into CertiField. The platform tracks findings across components, maps them to POA&M items automatically, shows you what changed between scan cycles, and maintains the audit trail that an AO actually wants to see. When a STIG version changes, CertiField handles the migration rather than leaving you to figure out which IDs moved where.
The practical effect is that the work that used to happen in spreadsheets after the scan happens in the platform instead, and it happens once rather than being repeated manually every time someone needs a current view of compliance status.
We built CertiField on our own programs first. The free tools were part of our workflow before CertiField existed, and we understand what they do well. The gap they leave is real and it's worth addressing deliberately rather than covering it with spreadsheet hours.
See how CertiField handles the gaps
STIG tracking, POA&M management, and RMF workflow automation in one platform. Built for DoD programs, deployable in classified and unclassified environments.
Visit CertiField Talk to Our Team