ComplyRoll

A local-first evidence compiler for FedRAMP® 20x Vulnerability Detection and Response (VDR).

ComplyRoll turns scanner observations, validation runs, and operational evidence into traceable vulnerability cases, class-aware response clocks, and official-format FedRAMP reports that a provider can publish and an independent assessor can recompute.

Project status (2026-08-21): pre-alpha. Phase 0 (hardened ingestion) is complete. Phase 1 has its first end-to-end path: complyroll report vdt compiles scanner artifacts into a schema-valid Vulnerability Detail Report and complyroll validate checks any report against the pinned official schemas. Case history persistence is not wired yet. ComplyRoll does not produce a FedRAMP submission package and must not be represented as FedRAMP approved. It is not yet published on PyPI; install only from this repository.

What runs today

The report compiler is stateless by design (ADR 0007): the same artifacts, evaluations, options, and --as-of instant produce the same bytes, which is the property an independent assessor is asked to test. Persisted case history, accepted-vulnerability and historical-activity reports, and the event-sourced rebuild of this same report are the next slices. See docs/BUILD_PLAN.md.

Quick start

From a source checkout:

python3 -m venv .venv
.venv/bin/python -m pip install -e .
.venv/bin/python -m complyroll version
.venv/bin/python -m unittest discover -s tests -v

Compile the synthetic fixtures into a Vulnerability Detail Report and validate it:

complyroll report vdt \
  tests/fixtures/ubuntu-host.cklb \
  tests/fixtures/windows-host.ckl \
  tests/fixtures/openscap-results.xml \
  --class C \
  --package-uri https://example.test/cpo \
  --from 2026-08-01T00:00:00Z \
  --to 2026-08-31T23:59:59Z \
  --as-of 2026-08-21T12:00:00Z \
  --detected-at 2026-08-01T00:00:00Z \
  --evaluations examples/evaluations.json \
  -o report.json \
  --markdown report.md

complyroll validate report.json --schema vulnerability-detail

The fixtures declare no assessment timestamp, so --detected-at attests one; ComplyRoll never substitutes file modification or ingestion time. --evaluations supplies the contextual judgement a scanner cannot provide (IRV, LEV, PAIN, impact, rationale, evaluator; see examples/evaluations.json). --as-of pins the instant overdue flags are computed against, which makes the run reproducible byte for byte; the expected output is tests/golden/vdt-fixtures.json and tests/golden/vdt-fixtures.md.

The report period selects contents: a vulnerability appears when it had activity inside --from/--to (detection, evaluation, a PAIN reduction, or a planned reduction), or when it is still undisposed and was detected on or before the period end. Every exclusion is reported as an excluded_by_period diagnostic and counted in the document, so "nothing happened" is distinguishable from "nothing was compiled". Output files are written all-or-nothing: a failed Markdown write leaves no JSON behind.

Everything ComplyRoll adds beyond the official minimum structure lives under one x-complyroll key: generator and parser versions, the rules dataset and schema commits and digests, the compile diagnostics, every computed deadline with its rule and force, the grouped observation ids and affected resources, the detection-time source (artifact, artifact-partial, or attestation), and the evaluator and rationale. The Markdown twin carries the same detail in a per-vulnerability section. That makes the document the provider's and assessor's working record. It includes internal resource identifiers and provider rationale, so redact it before sharing with an agency; audience-specific views are a later slice.

Roll up the synthetic fixtures with the predecessor command:

stigroll tests/fixtures/windows-host.ckl tests/fixtures/ubuntu-host.cklb --format json

Ingest an artifact and inspect its observations and diagnostics:

from pathlib import Path

from complyroll.adapters import ingest_stig_artifact

result = ingest_stig_artifact(Path("assessment.cklb"))
if not result.successful:
    for diagnostic in result.errors:
        print(diagnostic.code, diagnostic.message)
else:
    print(result.observations[0].to_canonical_json())

Calculate a Class C response target with rule provenance:

from datetime import UTC, datetime

from complyroll.models import PainRating
from complyroll.policy import CertificationClass, CertificationProfile, load_bundled_policy

policy = load_bundled_policy(CertificationProfile(CertificationClass.C))
deadline = policy.response_deadline(
    datetime(2026, 8, 21, 15, 0, tzinfo=UTC),
    pain=PainRating.N4,
    is_internet_reachable=True,
    is_likely_exploitable=True,
)
print(deadline.rule_id, deadline.force.value, deadline.due_at.isoformat())
print(deadline.provenance.commit, deadline.provenance.dataset_sha256)

Validate a report against the pinned official schema:

from pathlib import Path

from complyroll.schemas import ReportSchema, validate_bundled_report_bytes

result = validate_bundled_report_bytes(
    ReportSchema.VULNERABILITY_DETAIL, Path("vulnerability-detail.json").read_bytes()
)
for issue in result.issues:
    print(issue.instance_pointer, issue.validator, issue.message)
print(result.provenance.schema_version, result.provenance.schema_sha256)

Why this exists

FedRAMP 20x is based on measured outcomes and persistent validation. A failed STIG rule or CVE is only a source observation. VDR additionally covers drift, failed validation pipelines, stale security decisions, supply-chain exposures, and failures in the detection and response process itself. ComplyRoll therefore separates immutable observations from stateful vulnerability cases.

Target pipeline (the stages after observations are not built yet):

flowchart TD
    A["STIG, XCCDF, SARIF, SBOM and cloud sources"] --> B["Immutable observations"]
    B --> C["Grouped vulnerability cases"]
    C --> D["IRV, LEV and PAIN evaluation"]
    D --> E["Class-aware deadlines and response history"]
    E --> F["VER JSON, SDR evidence and human reports"]
    G["KSI validation and process health"] --> B

Non-negotiable rules

• Source severity, DISA CAT, CVSS, and PAIN are separate concepts.
• ComplyRoll must never infer PAIN solely from source severity or CVSS.
• A scanner pass may support a Key Security Indicator (KSI); it does not prove the complete KSI.
• Grouping observations must not destroy affected-resource or source-level details.
• Rule calculations must identify the exact pinned FedRAMP rules version used.
• Human-readable and machine-readable reports must come from the same normalized records.
• Historical evaluations and evidence must remain reproducible.

For independent assessors

ComplyRoll is meant to be run cold on provider-supplied artifacts: ingest the raw scanner exports, recompute the clocks and the report, and compare against what the provider published. Every deadline names its rule identifier, force (MUST or SHOULD), certification class, dataset commit, and digest. Assessors do not configure or operate ComplyRoll on a provider's behalf; under the 2026 recognition rules, advisory work on an offering bars assessing that offering for two years.

Design documents

• docs/BUILD_PLAN.md: phased implementation plan and exit criteria
• docs/ARCHITECTURE.md: system boundaries and component design
• docs/DATA_MODEL.md: observation, case, evaluation, and evidence model
• docs/FEDRAMP_2026_MAPPING.md: current rule and schema mapping
• docs/SECURITY.md: threat model and evidence-handling requirements
• docs/decisions/: architecture decision records 0001 through 0007 (0007 fixes the report mappings: attested detection time, disposition table, clock semantics, overdue wording, the x-complyroll extension, and the evaluations file)
• examples/: the fixture-to-report demo inputs
• AGENTS.md: repository rules and development commands

Dependencies and data

Persistence uses Python's standard-library SQLite binding. Report validation uses the major-version-bounded jsonschema package with its non-GPL format extra, because the standard library does not implement JSON Schema Draft 2020-12 (ADR 0006). Everything else is the standard library.

The official FedRAMP rules dataset and VER schemas are bundled unmodified and pinned to immutable upstream commits with SHA-256 digests; see NOTICE and src/complyroll/data/README.md for provenance and license.

Authoritative sources ComplyRoll consumes and pins rather than copies into constants:

• FedRAMP Consolidated Rules for 2026
• FedRAMP machine-readable rules
• FedRAMP JSON schemas
• Vulnerability Detection and Response
• Vulnerability Evaluation and Reporting
• Key Security Indicators

Disclaimer

ComplyRoll is informational tooling, not legal or compliance advice. A report that validates against an official schema satisfies that schema's minimum structure; it is not a FedRAMP determination, and the provider remains responsible for meeting the Consolidated Rules. Verify every clock against https://www.fedramp.gov/2026/ before relying on it.

License

ComplyRoll's code is licensed under the Apache License, Version 2.0 (see LICENSE and NOTICE). The bundled FedRAMP data files are works of the U.S. Government and are not covered by that license. The ComplyRoll name is not licensed (Apache License, Section 6). Contributions require a Developer Certificate of Origin sign-off (CONTRIBUTING.md).

FedRAMP® is a registered trademark of the U.S. General Services Administration. ComplyRoll is an independent project and is not affiliated with, endorsed by, or approved by GSA or the FedRAMP Program Management Office.