// Create or update a versioned profile pair (versioned + unversioned extends pattern).
Create a template for checks and remediations
Create a new product in ComplianceAsCode project
Create Automatus test scenarios to test the given rule.
Search for existing rules that match a given requirement text. Identify rules that implement a specific control.
Build a ComplianceAsCode product
Create a new security rule with all required components
| name | manage-profile |
| description | Create or update a versioned profile pair (versioned + unversioned extends pattern). |
| disable-model-invocation | true |
Create or update a versioned profile.
Arguments: $ARGUMENTS
Expected arguments: <action> <profile_name> <product(s)> [version]
Actions:
create — Create a new versioned profile pair (versioned + unversioned)update — Bump an existing profile to a new versionFor example:
create cis ocp4 1.7.0update cis ocp4 1.8.0This project uses a two-file versioning pattern for profiles (browse existing profiles under products/<product>/profiles/ for examples):
cis-v1-7-0.profile): Contains the actual selections, metadata.version, and all profile configuration. Users pin to this for a stable baseline.cis.profile): Contains extends: cis-v1-7-0 and no selections of its own. Users referencing this always get the latest version.When multiple products are specified (e.g., ocp4,rhcos4), both profile pairs are created/updated under their respective products/<product>/profiles/ directories.
createproducts/.products/<product>/profiles/ exists for each product.update instead.2.0.0 → v2-0-0).Check if a control file exists that matches the profile name. Control files live under controls/ and products/*/controls/, typically named <profile>_<product>.yml or as a split directory with the same base name. If found:
product field.product field does not list all the products from the argument, warn the user and offer to update it. A control file needs all target products listed in its product field to work with each product's profile. Check existing multi-product control files for examples of this pattern.For each product, show the two files that will be created:
Versioned profile (products/<product>/profiles/<name>-<version>.profile):
---
documentation_complete: true
title: '<Title> for <Product Full Name>'
platform: <product>
metadata:
version: <Version>
description: |-
<Description text.>
selections:
- <control_id>:all
Unversioned profile (products/<product>/profiles/<name>.profile):
---
documentation_complete: true
title: '<Title> for <Product Full Name>'
platform: <product>
metadata:
version: <Version>
description: |-
<Description text.>
extends: <name>-<version>
Ask the user to confirm before creating.
Create all files for each product after approval.
updateproducts/<product>/profiles/<name>.profile.extends target (e.g., cis-v1-7-0).selections and other configuration.2.1.0 → v2-1-0).If the unversioned profile doesn't use extends, warn the user that it doesn't follow the versioning pattern and offer to convert it.
For each product, show what will happen:
<name>-<new_version>.profile): Created with the same selections as the current versioned profile (the user can modify selections afterward).<name>-<old_version>.profile): Add status: deprecated to mark it as superseded.<name>.profile): Update extends to point to the new version and update metadata.version.Ask the user to confirm before applying.
After approval:
metadata.version.status: deprecated to the previous versioned profile.extends field to reference the new versioned profile.metadata.version to the new version.full_name field from products/<product>/product.yml for each product.v (e.g., 2.0.0 → v2-0-0, V2R3 → v2r3).V2.0.0, V2R3).selections, filter_rules, variables, and other configuration from the current versioned profile.