Knowledge about end-to-end compliance pipelines using Compliance Trestle: GRC personas and artifact ownership, multi-repository coordination, the two-phase component definition authoring pattern, CI/CD pipeline integration, and the Compliance-to-Policy (C2P) bridge. Use when users ask about compliance pipelines, personas, who owns what artifact, multi-repo workflows, component definition dual-mapping (control-to-rule, rule-to-check), CI/CD compliance, C2P, or end-to-end workflow design.
From compliance-trestlenpx claudepluginhub ethanolivertroy/compliance-trestle-skillsThis skill is limited to using the following tools:
examples.mdpersonas-reference.mdDesigns and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
This skill covers the full compliance pipeline from regulation authoring through assessment results, including persona ownership, multi-repository coordination, and the Compliance-to-Policy (C2P) bridge between OSCAL artifacts and runtime policy validation.
Each compliance artifact has a primary owner persona and flows downstream to consumers:
| Persona | Primary Artifact | Key Trestle Commands | Downstream Consumer |
|---|---|---|---|
| Regulators | Catalog | catalog-generate, catalog-assemble | Compliance Officers |
| Compliance Officers / CISO | Profile | profile-generate, profile-assemble, xlsx-to-oscal-profile | Control Providers, System Owners |
| Control Providers (vendors) | Component Definition (Service) | csv-to-oscal-cd, component-generate, component-assemble | Control Assessors, System Owners |
| Control Assessors (PVP vendors) | Component Definition (Validation) | csv-to-oscal-cd (with Check_Id column) | CPAC / C2P |
| System Owners / CIO | System Security Plan | ssp-generate, ssp-assemble, ssp-filter | Assessors, Auditors |
| Assessors | Assessment Results | xccdf-result-to-oscal-ar, tanium-result-to-oscal-ar | CISO, System Owners |
| Operations | Remediation (POA&M) | create, split, merge (JSON workflow) | Auditors |
Key principle: Each persona manages their artifact independently. Artifacts flow downstream via Git-based propagation, enabling separation of duties and independent versioning.
Regulators publish security controls as catalogs (e.g., NIST 800-53, PCI-DSS, ISO 27001).
# Import existing catalog or create new one
trestle import -f nist-800-53-catalog.json -o nist-800-53
# Generate markdown for human editing
trestle author catalog-generate --name nist-800-53 --output md_catalogs/nist-800-53
# Edit control markdown files (one per control, grouped by family)
# Then reassemble
trestle author catalog-assemble --markdown md_catalogs/nist-800-53 --output nist-800-53
Compliance Officers select and tailor controls from catalogs into organization-specific baselines.
# Generate profile markdown from existing profile
trestle author profile-generate --name my-baseline --output md_profiles/my-baseline
# Edit markdown: adjust parameter values, add guidance sections
# Then reassemble
trestle author profile-assemble --markdown md_profiles/my-baseline --output my-baseline
# Or convert directly from spreadsheet
trestle task xlsx-to-oscal-profile
Profiles can import from multiple catalogs and other profiles, creating layered baselines (e.g., FedRAMP High inherits from NIST 800-53, adding FedRAMP-specific parameters).
Control Providers (vendors, service providers) declare how their products implement controls. This is a two-phase process — structured rule data via CSV, then narrative responses via markdown.
Phase 1 — Rules via CSV spreadsheet:
# CSV contains: Rule_Id, Rule_Description, Component_Title, Component_Type,
# Control_Id_List, Parameter_Id, Parameter_Value_Alternatives, ...
trestle task csv-to-oscal-cd
The CSV captures structured mappings: which controls map to which technical rules and parameters. Vendors manage this in spreadsheet tools and commit the CSV to Git.
Phase 2 — Responses via markdown:
# Generate markdown from the component definition created in Phase 1
trestle author component-generate --name my-service --output md_compdefs/my-service
# Edit markdown: write prose responses describing HOW controls are implemented
# Then reassemble
trestle author component-assemble --markdown md_compdefs/my-service --output my-service
The markdown captures narrative prose: implementation descriptions, rationale, and status.
Why the split? Structured data (rules, parameters, control mappings) is best managed in spreadsheets. Narrative prose (implementation descriptions) is best edited as markdown. The two-phase pattern separates these concerns cleanly.
System Owners combine profiles and component definitions into a System Security Plan.
# Generate SSP markdown from profile + component definitions
trestle author ssp-generate --profile my-baseline --compdefs service-a,service-b --output md_ssp/my-system
# Edit markdown: fill in system-specific implementation details, set ssp-values
# Then reassemble
trestle author ssp-assemble --markdown md_ssp/my-system --output my-system
# Filter SSP to a specific profile (for different audit scopes)
trestle author ssp-filter --name my-system --profile fedramp-high --output my-system-fedramp
The component definition is the bridge artifact that connects regulatory controls to automated assessment. It operates at two layers via two distinct component types.
Service components map regulation controls to technology-specific rules and parameters:
Control (e.g., AC-2) --> Rule (e.g., rule-account-types) --> Parameter (e.g., timeout=15min)
Rule_Id, Rule_Description, Control_Id_List, Parameter_Id, Component_Type=ServiceValidation components map rules to PVP check identifiers:
Rule (e.g., rule-account-types) --> Check_Id (e.g., test_github.GitHubOrgs.test_members_is_not_empty)
Rule_Id, Check_Id, Check_Description, Component_Type=ValidationTogether, the two layers create full traceability:
Regulation Control (NIST AC-2)
--> Service Rule (rule-account-types)
--> Validation Check (test_github.GitHubOrgs.test_members_is_not_empty)
--> Assessment Result (pass/fail)
--> Control Posture (satisfied/not-satisfied)
This chain enables automated compliance: given assessment results from PVPs, the system can automatically compute whether regulatory controls are satisfied by following the mappings backward through the component definitions.
Large organizations separate artifacts by ownership boundaries:
catalog-repo (Regulators)
|
v imports
profile-repo (Compliance Officers)
|
v references
compdef-repo (Vendors / Control Providers)
|
v combined into
ssp-repo (System Owners)
Each repository has independent:
When an upstream artifact changes, downstream repositories receive automated PRs:
trestle author *-assemble to produce updated OSCAL JSONExample: A new control is added to the catalog. The profile repo gets a PR to include it. Once merged, the compdef repo gets a PR to add rule mappings. Once merged, the SSP repo gets a PR to include the new control responses.
| Factor | Single Repo | Multi-Repo |
|---|---|---|
| Team size | Small team (1-5 people) | Multiple teams / organizations |
| Ownership | Same team owns all artifacts | Different teams own different artifacts |
| Release cadence | All artifacts change together | Artifacts change independently |
| Access control | Same permissions for all | Different access per artifact type |
| Complexity | Simple, lower overhead | Higher overhead, better separation |
Recommendation: Start with a single repo. Split when ownership boundaries become clear or when independent versioning is needed.
Pre-commit --> PR Merge --> Post-Merge
trestle validate trestle author Propagate to
*-assemble downstream repos
(conditional write)
Pre-commit / PR validation:
# Validate all models in workspace
trestle validate -a
# Or validate specific model
trestle validate -t catalog -n my-catalog
PR merge / assembly:
# Assemble only writes if content changed (prevents unnecessary git churn)
trestle author catalog-assemble --markdown md_catalogs/my-catalog --output my-catalog
trestle author profile-assemble --markdown md_profiles/my-baseline --output my-baseline
trestle author component-assemble --markdown md_compdefs/my-service --output my-service
trestle author ssp-assemble --markdown md_ssp/my-system --output my-system
Post-merge propagation:
A core principle from the COMPASS architecture: write each compliance artifact once, then reuse it across multiple contexts:
This avoids duplication and ensures consistency across the compliance program.
C2P is a separate tool (not part of Trestle) that bridges OSCAL compliance artifacts to runtime policy validation and back to OSCAL assessment results.
OSCAL Component Definition
--> C2P generate_pvp_policy --> PVP-specific policy config
--> PVP executes checks
<-- C2P generate_pvp_result <-- PVP-native results
OSCAL Assessment Results
C2P reads the component definition's rule-to-check mappings and:
Trestle authors the OSCAL artifacts that C2P consumes:
csv-to-oscal-cd creates the component definitions with rule and check mappingscomponent-generate / component-assemble adds narrative responsestrestle import -f assessment-results.jsonTrestle does NOT execute PVP checks — that is C2P's responsibility.
| PVP Type | Policy Style | Examples |
|---|---|---|
| Declarative | Desired-state manifests | Kubernetes (OCM, GateKeeper, Kyverno) |
| Imperative | Step-by-step scripts | Auditree (Python), Ansible playbooks |
auditree.json) with parameters# 1. Author component definitions with Trestle (rules + checks)
trestle task csv-to-oscal-cd
# 2. C2P generates PVP-specific configuration
# (C2P reads component-definition.json, outputs PVP config)
# 3. PVP executes checks against target systems
# (Auditree runs fetchers + checks, OCM distributes policies to clusters)
# 4. C2P collects results and produces OSCAL Assessment Results
# (C2P reads PVP output, outputs assessment-results.json)
# 5. Import results back into Trestle workspace
trestle import -f assessment-results.json -o latest-scan
csv-to-oscal-cd configuration, CSV column reference, dual component definition CSV pattern