CKL vs CKLB
CKL is the legacy XML checklist format produced by earlier STIG Viewer versions. CKLB is the newer JSON format introduced with STIG Viewer 3. Both carry per-rule status, finding details, comments and CCI references — and any tool handling DoD STIG work needs to read and write both, because programs have years of CKL history.
If you work with DISA STIGs you will encounter both formats, usually at the same time, usually because different people on the program are running different versions of STIG Viewer.
The distinction is worth understanding precisely, because the practical question — what does my tooling need to support? — has a clear answer, and it is “both, for a long time.”
What each one is
CKL is the legacy checklist format: XML, produced and consumed by STIG Viewer 2 and earlier. It has been the working format for DoD STIG assessment for many years, which means every program with any history has a substantial archive of CKL files, and many established workflows and scripts assume it.
CKLB is the newer format introduced with STIG Viewer 3: JSON rather than XML. It carries the same essential assessment information in a more tractable structure and is better suited to programmatic handling.
Both are checklist files. Both record, per rule, what the assessment outcome was.
What both carry
The content that matters is common to both formats:
- Per-rule status — Open, Not a Finding, Not Applicable, Not Reviewed
- Finding details — what was observed
- Comments — the assessor’s notes, which are frequently the most valuable content in the file
- Rule and group identifiers — including the version-specific rule identifier
- The CCI reference — which is what connects the rule to an 800-53 control statement
- Severity — CAT I, II or III
- Target metadata — the asset the checklist applies to
The CCI reference deserves particular attention. It is the link that makes a STIG result meaningful to RMF, and it is present in both formats. Tooling that ingests checklists and discards the CCI reference has thrown away the connection to the control set, which is the whole reason the file matters to an authorization.
The differences that matter operationally
Parsing. JSON is easier to work with than the CKL XML structure, which carries a certain amount of historical awkwardness. For anyone writing tooling this is a genuine improvement.
Multiple targets. The CKLB structure handles multiple assessment targets in a single file more cleanly. On a fleet this matters.
Tool support. STIG Viewer 3 works with CKLB. Older tooling, and a great deal of program-local scripting, expects CKL. This is the source of most day-to-day friction.
Archive weight. Years of assessment history exist in CKL. That history has value — it is the record of what was reviewed and why — and it does not migrate itself.
What tooling has to do
Read both. Non-negotiable. A program will have both, from different people and different periods.
Write both. Somebody downstream is running STIG Viewer 2, and telling them to upgrade is not a strategy that survives contact with a large program.
Preserve comments through conversion. Assessor comments are the highest-value content in a checklist. They explain why a rule is Not Applicable, what compensating measure is in place, what the finding actually was. Losing them in a format conversion destroys exactly the work that took longest to produce.
Merge revisions without losing review work. The most important capability, and the one most often absent. When DISA publishes a new revision of a STIG you have already assessed, the new checklist should merge into your existing one: unchanged rules keep their status and comments, changed rules are flagged for re-review, new rules arrive as Not Reviewed, and removed rules are retired.
Where that merge is not available, every STIG release costs a complete re-review. That is why so many programs are assessing against STIG revisions that are two years old — not negligence, just a rational response to updating costing more than not updating.
Migration, in practice
There is no urgency to convert historical CKL files. They are a record of past assessments and they remain valid as such.
What is worth doing is standardizing going forward and making sure whatever holds your checklist data is format-agnostic internally. If your record stores rule results as structured facts with CCI references, then CKL and CKLB are both just import and export formats — and the next format DISA publishes will be too.
That is the general principle. A program whose checklist data lives as files is coupled to a format. A program whose checklist data lives as facts, with files as import and export, is not.
The question that reveals a tool’s real capability
Ask for this in a demo:
Import a CKL file from an older STIG revision. Now import the CKLB for the current revision of the same STIG. Show me which rules carried their status and comments forward, which are flagged for re-review because the rule text changed, and which are new.
That exercises both formats, the merge logic and the revision handling in one request. It is routine for a tool that stores checklist results as structured facts, and awkward for one that stores them as attached files — and the shape of the answer tells you which you are looking at.