OSCAL packages: export, verify, attest and import
Axis Assure writes your compliance records as OSCAL, NIST's machine-readable format for security plans, assessments and remediation plans, and reads OSCAL that other tools wrote. Every file you take out is kept as a revision with the SHA-256 of its exact bytes, so you can always show which file you handed over and that it has not changed since. A signed revision also carries AxisSynapse's signature; one that is not signed says so, and cannot be released.
TL;DR — Assure → Packages → Export a package: choose the kind, the system (and the program or assessment), the OSCAL version and the format. Unchanged data never makes a second revision. Download it and compare the SHA-256 the page shows. Release the revision for submission, then attest it with your passkey. Verify a package checks any package you are handed back. Import brings another tool's OSCAL in, shows you what it would change, and writes nothing until you apply it.
What you can export
| Field | What it does | Accepted values / default |
|---|---|---|
| System Security Plan | A system's controls in a program: how each is implemented, by which component, with its parameter values. | Every plan. Evidence that is current, scanned clean and within the classification you choose can be listed with its SHA-256. |
| Component definition | What each component of the system states about the controls it helps meet. | Every plan. |
| Assessment plan / assessment results | An assessment: the plan it was approved with (what it assesses and by which methods), its subjects and tasks; then each determination with every method used, its reason and evidence, its samples and its findings. | Every plan. |
| POA&M | Open weaknesses, their milestones and deadlines. | Professional and above (the POA&M is tracked there). |
| Signed bundle | One ZIP: the plan, the component definition, the POA&M and the evidence they cite, with a manifest that lists every file's SHA-256 and, when the bundle is signed, a signature over the manifest. | Every plan. A member your plan does not include is listed in the manifest as left out, with the reason. A bundle is at most 25 MB: evidence that does not fit is listed as left out too; list evidence as metadata to include any number of files. |
| FedRAMP CPO, SDR and OCR | FedRAMP's 2026 package documents (not OSCAL). | Enterprise. See FedRAMP packages. |
Versions and formats. OSCAL documents are written in OSCAL 1.2.3 by default, or 1.1.3 or 1.1.2 for tools that need them, as JSON, YAML or XML. OSCAL 1.1.2 cannot carry an evidence file's SHA-256, so a bundle written as 1.1.2 must embed its evidence; choose 1.1.3 or later to list it by reference.
Framework words. A document carries a framework's own text only where its licence allows it to leave the platform. Where it does not, the document keeps the control's identifier and label and says the words were withheld. The licence is checked again each time a stored package is downloaded: when a framework licence you brought ends, or its text is destroyed under its terms, the packages that carry that text are no longer served. Their record and hash stay, so what you handed over can still be shown. A bundle's NOTICE credits only the publishers whose words it carries.
What a revision is
A revision is a state of your data, not a click on Build.
- Building again when nothing changed gives you the stored revision, byte for byte. Nothing new is stored.
- Another version or format of the same data is another file of the same revision.
- A document's last-modified date is when the data last changed, not when the file was built, so the same data always gives the same bytes.
- Each element keeps the same identifier from revision to revision. An element you imported keeps the identifier it arrived with.
The validation report
Every revision is checked when it is built, and the report is kept with it, finding by finding, by layer:
- Schema — NIST's published JSON schema for the document's model and OSCAL version.
- OSCAL constraint — NIST's own rules for OSCAL: allowed values, references that must resolve, identifiers that must be unique. AxisSynapse adds one rule of its own for packages: a package must be self-contained.
- Checked in CI only — the few NIST rules written in a form the in-app checker does not evaluate. The report names each one instead of passing it silently.
- Package lint — FedRAMP's package rules, for FedRAMP documents.
- Licence withholding, Omission, Not carried (version) — framework words the licence kept back, records the document could not hold, and members the chosen OSCAL version cannot carry.
A revision with errors is stored so you can read its report, but it cannot be released. You can download the report as SARIF, the standard format for tool findings.
Release and attest
Release the revision
Release for submission freezes the revision: a released revision never changes, and an earlier released revision of the same file is superseded. A revision with validation errors, or one that is not signed, cannot be released, and neither can an older revision once a newer one of the same file is released. The released file is put under a legal hold in the documents library, so nobody can delete it there.
Attest it
Attest records that you reviewed this exact file: the attestation is bound to its SHA-256 and recorded once, in the workspace's audit trail. It asks for your Passkey or security key; a password alone is not enough. It needs the permission to attest packages, and an assistant can never attest.
Four eyes, if your workspace asks for it
When the workspace requires a second person, you ask for the attestation instead. A different person reviews the same file and decides, with their own passkey. The person who asked cannot decide.
What the signature means, and what it does not
AxisSynapse's signature says the platform produced these bytes from your workspace's data. It is not your attestation. Your attestation is a separate act, by a named person in your workspace, bound to the same SHA-256.
Verify a package
Assure → Packages → Verify a package checks a package's signature and hashes.
- A file you have. A bundle (ZIP) carries its own signature: every file is checked against the manifest, nothing unlisted is allowed, no file may appear twice or under a name that is not a plain path, and the signature is checked over the manifest. A single document needs the signature it was downloaded with (the download's signature header).
- A stored revision. The stored bytes are read again and checked against their SHA-256 and signature.
The result names the key that signed it: the current key, an earlier key kept after a rotation, or the key kept with the revision. Anyone outside your workspace can verify a package with AxisSynapse's published keys and any standard JOSE library; the verify page shows how.
Import OSCAL from another tool
Assure → Packages → Import brings an OSCAL System Security Plan, component definition, assessment plan or results, or POA&M into the workspace's records.
Upload
Choose the document's model and upload it: JSON, YAML or XML, up to 25 MB. It goes into the documents library first.
Scan and read
The file is read only once the malware scan says it is clean, and in isolation. A file that is not valid OSCAL, or is another model than the one you chose, is refused, and nothing is written.
Choose where it lands
Pick the program the document's controls bind to. Programs are ranked by how well they match the profile the document names; nothing is fetched from the internet. An assessment plan or results names no system the import may trust, so you choose the system.
Preview
See what applying it would do: what it creates, updates or leaves unchanged; what you must decide; what is carried as written (members AxisSynapse has no field for, stored beside the records and given back on export); and what will not be carried, each with where it is in the document.
Apply
A person who may apply imports does it. Each record is written by its own part of Assure and audited. Imported implementations arrive as needing review. An approved record is never overwritten unless you choose to replace it, which sends it back to review.
Accept assessment results
An imported assessment's determinations do not count toward your scores until a person who manages assessments accepts them.
Importing the same document again changes nothing. Inventory items are matched to your asset records only when you accept a match; nothing is created in another module. Embedded evidence becomes library evidence and is unusable until its scan is clean.
Related
- FedRAMP packages — the offering profile, the CPO, SDR, OCR and vulnerability reports, and FedRAMP's 2026 dates.
- Step-up authentication — what asks for your passkey.