Stats
Actions
Tags
From compliance-trestle
Explains OSCAL model types including catalogs, profiles, SSPs, component definitions; their relationships and Compliance Trestle management. Useful for OSCAL document and compliance model queries.
How this skill is triggered — by the user, by Claude, or both
Slash command
/compliance-trestle:trestle-oscal-modelsThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
| Model Type | CLI Name | Directory | Description |
| Model Type | CLI Name | Directory | Description |
|---|---|---|---|
| Catalog | catalog | catalogs/ | Collection of security controls (e.g., NIST 800-53) |
| Profile | profile | profiles/ | Selection and modification of controls from catalogs |
| Component Definition | component-definition | component-definitions/ | How a component implements controls |
| System Security Plan | system-security-plan | system-security-plans/ | Complete system security documentation |
| Assessment Plan | assessment-plan | assessment-plans/ | Plan for assessing security controls |
| Assessment Results | assessment-results | assessment-results/ | Results of security assessment |
| POA&M | plan-of-action-and-milestones | plan-of-action-and-milestones/ | Remediation tracking |
Catalog (controls)
↓ imports
Profile (selects + modifies controls)
↓ resolved profile catalog
Component Definition (how components implement controls)
↓ combined
System Security Plan (complete system documentation)
↓ assessed by
Assessment Plan → Assessment Results → POA&M
A profile can import from:
Each import selects specific controls and can modify parameters and add content.
All models share:
uuid - Unique identifiermetadata - Title, version, last-modified, oscal-version, roles, partiesback-matter - Resources, citations, attachments.json.yaml or .ymlTrestle uses dot-notation to address elements within models:
catalog.metadata - The metadata of a catalogcatalog.groups.*.controls.* - All controls in all groupscatalog.groups.0.controls.3 - Specific control (0-indexed)Rules:
* wildcard for arrays (quote on *nix shells)catalog.controls.control = catalog.groups.controls.control| Operation | Command | Description |
|---|---|---|
| Create | trestle create -t <type> -o <name> | Create bare-bones sample model |
| Import | trestle import -f <file> -o <name> | Import existing OSCAL file |
| Split | trestle split -f <file> -e <elements> | Decompose into sub-files |
| Merge | trestle merge -e <elements> | Reassemble split files |
| Describe | trestle describe -f <file> -e <element> | Inspect model structure |
| Validate | trestle validate -f <file> or -t <type> -n <name> or -a | Check model integrity |
| Assemble | trestle assemble <type> -n <name> | Combine split parts to dist/ |
| Replicate | trestle replicate <type> -n <name> -o <new> | Copy/rename model |
Each OSCAL model type has a primary owner persona responsible for authoring and maintaining it:
| Model Type | Primary Persona | Trestle Commands | Notes |
|---|---|---|---|
| Catalog | Regulators | catalog-generate, catalog-assemble | Source of truth for controls |
| Profile | Compliance Officers / CISO | profile-generate, profile-assemble | Tailored baselines with org guidance |
| Component Definition (Service) | Control Providers (vendors) | csv-to-oscal-cd, component-generate/assemble | Maps controls to product rules |
| Component Definition (Validation) | Control Assessors (PVP vendors) | csv-to-oscal-cd (with Check_Id) | Maps rules to automated checks |
| System Security Plan | System Owners / CIO | ssp-generate, ssp-assemble | Combines profile + compdefs |
| Assessment Plan | Assessors / CISO | create, split, merge | Defines assessment scope |
| Assessment Results | Assessors / PVP tools | xccdf-result-to-oscal-ar, tanium-result-to-oscal-ar | Scan findings |
| POA&M | System Owners | create, split, merge | Remediation tracking |
In real organizations, one person may fill multiple persona roles. The ownership mapping is logical (separation of duties), not necessarily physical (one person per artifact).
The component definition plays a unique bridging role in the OSCAL model chain. It connects regulatory controls (governance layer) to automated assessment (technical layer) through two distinct component types:
Service components declare which technology-specific rules implement a regulation control:
rule-account-types) --> Parameter (e.g., timeout=15min)csv-to-oscal-cd with Component_Type=Service)component-generate / component-assemble)Validation components declare which PVP checks validate a rule:
rule-account-types) --> Check_Id (e.g., test_github.GitHubOrgs.test_members_is_not_empty)csv-to-oscal-cd with Component_Type=Validation and Check_Id column)Together, the two layers create the full compliance automation chain:
Regulation Control (NIST AC-2)
--> Service Rule (rule-account-types)
--> Validation Check (test_github.GitHubOrgs.test_members)
--> Assessment Result (pass/fail)
--> Control Posture (satisfied/not-satisfied)
This traceability enables automated posture computation: given PVP results, map backward through component definitions to determine control-level compliance status.
For full pipeline details, see the trestle-compliance-pipeline skill.
npx claudepluginhub ethanolivertroy/compliance-trestle-skills --plugin compliance-trestleGuides OSCAL document selection (SSP, Profile, AR, POA&M), authoring, validation error fixes, schema versioning, and integrations with FedRAMP, eMASS, Compliance Trestle.
Provides senior GRC analyst expertise across 15 frameworks including NIST 800-53, FedRAMP, FISMA, CMMC, SOC 2, ISO 27001. Supports control lookups, cross-mapping, document review, audit prep, compliance workflows.
Guides conversion of FedRAMP Rev 5 DOCX SSP templates to OSCAL 1.2.0 JSON, covering metadata, system characteristics, inventory, and control implementations. Use after filling templates for machine-readable compliance outputs.