OSCAL SAR generation
An OSCAL SAR is hard to produce not because the format is difficult but because it demands distinctions most assessment records never made — observation, finding and risk are three separate things, and a record that conflated them has nothing to serialize.
The OSCAL assessment-results model is the machine-readable form of a Security Assessment Report.
It is more demanding than the SSP model, and the reason is instructive: it forces distinctions that
most assessment processes never bothered to make.
If producing an OSCAL SAR from your record is difficult, the format is usually not the problem. The record is.
Three things that are not the same thing
OSCAL separates observation, finding and risk. Most spreadsheets have one column that mushes all three together, and untangling them afterwards is the actual work.
An observation is something noticed during assessment. A scan returned this result. This configuration setting has this value. This document was reviewed and contains this. An observation is a fact about what was seen, with a method and a date. It carries no judgment.
A finding is a determination about an objective. This CCI is satisfied, or it is not, on the basis of these observations. A finding has an assessor’s name on it and it is the authoritative act of an assessment.
A risk is the consequence that follows from a finding, with a characterization, a status and a remediation path. Risks are what become POA&M items.
The relationship runs one way: observations support findings, findings give rise to risks. Collapse them and you lose the ability to answer the most common assessor question there is — on what basis did you decide that?
A record holding only “AC-2: Not Satisfied — see attached scan” has a finding, a gesture at an observation, and no risk. There is nothing to serialize properly, and the OSCAL export will either fail or fabricate structure.
What the model wants
Assessment metadata. Who assessed, when, under what scope, using what methods. OSCAL wants the assessment as a described activity rather than an implied one.
Reviewed controls. Which controls and control objectives were within scope. Note the objectives: OSCAL is comfortable operating below control granularity, which maps naturally onto CCI-level assessment and awkwardly onto control-level status fields.
Observations. Each with a method — EXAMINE, INTERVIEW, TEST — a description, subjects, and optionally the evidence supporting it, with a collection timestamp.
Findings. Each targeting a specific objective, with a state, related observations and any associated risks.
Risks. With characterizations, status, and remediation.
Back matter. The evidence resources everything above refers to.
Working through that list against your own assessment record is a diagnostic. Every field you cannot populate names a distinction your process is not making.
The field everybody omits
An assessment result describes a system at a moment. If the system it described has changed, the result is a historical fact rather than a current one — and telling those apart requires knowing which system state was assessed.
That means every assessment result should name the architecture version it was performed against. Not the date. The version.
Dates are a poor proxy because they only tell you the result is old, not whether anything relevant changed. A determination from fourteen months ago against an architecture version the system is still on is more current than one from last month against a version since superseded.
With architecture published as immutable, content-hashed versions, this is a stored reference. The consequences are worth spelling out:
- Staleness becomes computable. A control whose latest assessment names version 24 while the system runs version 27 is visibly behind, and you can check whether anything between those versions actually touched it.
- Reassessment scope becomes derivable rather than negotiable.
- The SAR can state what it was assessed against, which is the single most useful piece of context a reviewer can be given.
Getting from evidence to a defensible finding
The chain OSCAL wants you to be able to walk, in the order the assessment actually produces it:
- Evidence arrives. A scan result, a checklist, a screenshot, a policy document, an interview note. It knows its source and its date.
- An observation records what was seen. With the method used, referencing the evidence.
- An assessor makes a finding against a specific objective, citing the observations.
- Where the finding is negative, a risk is characterized, with a status and a remediation path.
- The risk becomes a POA&M item, retaining the link back through finding and observation to the original evidence.
Step 5 is where most processes break. The POA&M item gets written by hand, in a different tool, and the chain back to the scan that produced it survives only in the memory of whoever typed the row.
When a reviewer asks where a POA&M item came from — and they do — the answer should be a link, not an archaeology project.
The SAR and the SSP have to agree
They are generated from the same record or they will contradict each other. It is not a question of diligence.
An SSP claiming a control is fully implemented, next to a SAR recording a not-satisfied determination for a CCI under that control, is an internal contradiction. It is one of the first things a reviewer looks for, because it is easy to find and it indicates a process problem rather than a technical one.
One implementation status. One determination. One finding. Rendered into two documents. There is no version of that arrangement where they disagree.
Practical notes on the export
- Stable identifiers. Findings and observations need UUIDs that persist across regenerations, or nobody can diff two assessments.
- Methods on every observation. EXAMINE, INTERVIEW and TEST are not decoration. An assessor reading your SAR wants to know whether you looked at a document or actually tested the thing.
- Do not synthesise observations. If your record has findings and no observations, exporting invented observations to satisfy the schema produces a valid file that lies. Export what you have and let the gap be visible.
- Reference, do not embed. Evidence belongs in back matter and gets referenced. Inlining it produces enormous files nobody can process.