Initialize and scaffold your policy
Write the policy logic in Rego
Lint and validate the policy
Test the policy with sample materials
chainloop policy develop
- Main command for policy development toolschainloop policy develop init
- Initialize a new policy with proper template structurechainloop policy develop lint
- Validate YAML schema and Rego syntax, with optional formattingchainloop policy develop eval
- Test policies against sample materials locallyinit
command. This ensures a consistent file structure and reduces manual setup.
lint
command to detect issues. This ensures both the YAML structure and Rego code are valid, enforcing best practices via Open Policy Agent (OPA) and Regal.
eval
command. Violations or pass/fail results will be shown clearly, helping you quickly spot logic issues or edge cases.
kind
), the evaluation result will be the sum of all evaluations.
inputs
section, will be used by Chainloop to know with inputs arguments are supported by the policy
For example, this policy matches a “quality” score against a “threshold” argument:
input
section tells Chainloop which parameters should be expected. If missing, the argument will be ignored (an no value will be passed to the policy)input.args
rego input field.threshold
parameter, by adding a with
property in the policy attachment in the contract:
to_number
in the policy script
result
, if present. Older versions of Chainloop will only check for a violations
rule.
result
object has essentially three fields:
skipped
: whether the policy evaluation was skipped. This property would be set to true when the input, for whatever reason, cannot be evaluated (unexpected format, etc.). This property is useful to avoid false positives.skip_reason
: if the policy evaluation was skipped, this property will contain some informative explanation of why this policy wasn’t evaluated.violations
: will hold the list of policy violations for a given input. Note that in this case, skipped
will be set false
, denoting that the input was evaluated against the policy, and it didn’t pass.valid_input
and violations
rules:
valid_input
would fail if some preconditions were not met, like the input format.valid_input
rule would look like this:
violations
rule would return the list of policy violations, given that valid_input
evaluates to true
. If we wanted the CycloneDX report to be version 1.5
:
inputs
variable with all the payload to be evaluated. Chainloop will inject the evidence payload into that variable, for example a CycloneDX JSON document.
This way, input.specVersion
will denote the version of the CycloneDX document.
Additionally, Chainloop will inject the following fields:
input.args
: the list of arguments passed to the policy from the contract or the policy group. Each argument becomes a field in the args
input:
String
type. So if you expect a numeric value you’ll need to convert it with the to_number
Rego builtin.
Also, for convenience, comma-separated values are parsed and injected as arrays, as in the above example.
input.chainloop_metadata
: This is an In-toto descriptor JSON representation of the evidence, which Chainloop generates and stores in the attestation. Developers can create policies that check for specific fields in this payload.
A typical chainloop_metadata
field will look like this:
annotations
field will contain some useful metadata gathered by Chainloop during the attestation process.
The example above corresponds to an OCI HELM_CHART evidence, for which Chainloop is able to detect the notary
signature. You can write, for example, a policy that validates that your assets are properly signed, like this:
default violations := []
when using violations contains msg if
rules--kind
parameter in eval commandchainloop policy develop lint --format
to fix formatting issuessome
and contains
efficientlyopa.runtime
rego.parse_module
trace
http.send
has been isolated so only requests to the following domains are allowed:
chainloop.dev
cisa.gov