Release Policy
These rules are applied to pipeline run attestations associated with container images built by Konflux.
1. Available rule collections
2. Attestation type
Sanity checks related to the format of the image build’s attestation.
-
Package name:
attestation_type
2.1. Deprecated policy attestation format
The Enterprise Contract CLI now places the attestation data in a different location. This check fails if the expected new format is not found.
Solution: Use a newer version of the Enterprise Contract CLI.
-
Rule type: FAILURE
-
FAILURE message:
Deprecated policy attestation format found
-
Code:
attestation_type.deprecated_policy_attestation_format
-
Effective from:
2023-08-31T00:00:00Z
2.2. Known attestation type found
Confirm the attestation found for the image has a known attestation type.
Solution: Make sure the "_type" field in the attestation is supported. Supported types are configured in data sources.
-
Rule type: FAILURE
-
FAILURE message:
Unknown attestation type '%s'
-
Code:
attestation_type.known_attestation_type
2.3. Known attestation types provided
Confirm the known_attestation_types
rule data was provided.
Solution: Provide a list of known attestation types.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
attestation_type.known_attestation_types_provided
2.4. PipelineRun attestation found
Confirm at least one PipelineRun attestation is present.
Solution: Make sure the attestation being verified was generated from a Tekton pipelineRun.
-
Rule type: FAILURE
-
FAILURE message:
Missing pipelinerun attestation
-
Code:
attestation_type.pipelinerun_attestation_found
3. Base image checks
This package is responsible for verifying the base (parent) images reported in the SLSA Provenace or the SBOM are allowed.
-
Package name:
base_image_registries
3.1. Allowed base image registry prefixes list was provided
Confirm the allowed_registry_prefixes
rule data was provided, since it’s required by the policy rules in this package.
Solution: Make sure to configure a list of trusted registries as a data source.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
base_image_registries.allowed_registries_provided
3.2. Base image comes from permitted registry
Verify that the base images used when building a container image come from a known set of trusted registries to reduce potential supply chain attacks. By default this policy defines trusted registries as registries that are fully maintained by Red Hat and only contain content produced by Red Hat. The list of permitted registries can be customized by setting the allowed_registry_prefixes
list in the rule data. Base images that are found in the snapshot being validated are also allowed since EC will also validate those images individually.
Solution: Make sure the image used in each task comes from a trusted registry. The list of trusted registries is a configurable data source.
-
Rule type: FAILURE
-
FAILURE message:
Base image %q is from a disallowed registry
-
Code:
base_image_registries.base_image_permitted
3.3. Base images provided
Verify the expected information was provided about which base images were used during the build process.The list of base images comes from the components in the formulation
attribute of any associated CycloneDX SBOMs.
Solution: Ensure a CycloneDX SBOM is associated with the image.
-
Rule type: FAILURE
-
FAILURE message:
Base images information is missing
-
Code:
base_image_registries.base_image_info_found
4. Buildah build task
This package is responsible for verifying the buildah build task
-
Package name:
buildah_build_task
4.1. ADD_CAPABILITIES parameter
Verify the ADD_CAPABILITIES parameter of a builder Tasks was not used.
Solution: The ADD_CAPABILITIES parameter is not allowed for most container image builds. This, however, might be required for certain build types, e.g. flatpaks. Either unset the parameter or use a policy config that excludes this policy rule.
-
Rule type: FAILURE
-
FAILURE message:
ADD_CAPABILITIES parameter is not allowed
-
Code:
buildah_build_task.add_capabilities_param
-
Effective from:
2024-08-31T00:00:00Z
4.2. Buildah task uses a local Dockerfile
Verify the Dockerfile used in the buildah task was not fetched from an external source.
Solution: Make sure the 'DOCKERFILE' parameter does not come from an external source.
-
Rule type: FAILURE
-
FAILURE message:
DOCKERFILE param value (%s) is an external source
-
Code:
buildah_build_task.buildah_uses_local_dockerfile
4.3. PLATFORM parameter
Verify the value of the PLATFORM parameter of a builder Task is allowed by matching against a list of disallowed patterns. The list of patterns can be customized via the disallowed_platform_patterns
rule data key. If empty, all values are allowed.
Solution: Use a different PLATFORM value that is not disallowed by the policy config.
-
Rule type: FAILURE
-
FAILURE message:
PLATFORM parameter value %q is disallowed by regex %q
-
Code:
buildah_build_task.platform_param
-
Effective from:
2024-09-01T00:00:00Z
4.4. PRIVILEGED_NESTED parameter
Verify the PRIVILEGED_NESTED parameter of a builder Tasks was not set to true
.
Solution: Setting PRIVILEGED_NESTED parameter to true is not allowed for most container image builds. Either set the parameter value to false or use a policy config that excludes this policy rule.
-
Rule type: FAILURE
-
FAILURE message:
setting PRIVILEGED_NESTED parameter to true is not allowed
-
Code:
buildah_build_task.privileged_nested_param
4.5. disallowed_platform_patterns format
Confirm the disallowed_platform_patterns
rule data, if provided matches the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
buildah_build_task.disallowed_platform_patterns_pattern
5. CVE checks
This package is responsible for verifying a CVE scan was performed during the build pipeline, and that the image under test does not contain CVEs of certain security levels.
The behaviour of the rules in this package is influenced by rule data. Firstly the rules can be configured to emit violations or warnings based on the availability of the vulnerability fix: patched — if there is a remediation available, e.g. new version with a fix, or unpatched — if there is, currently, no remidiation available. Secondly per severity: critical, high, medium, low or unknown choice can be made of the rule outcome: failure or warning. And lastly, per severity, choice can be made of how many leeway days are allowed before a vulnerability causing a failure will be reported as a warning instead.
In the following example if rule data configuration, failures will be reported for critical and high patched vulnerabilities, for critical unpatched vulnerabilities only, warnings will be reported for medium and low patched, and for high and medium unpatched vulnerabilities. For critical and high patched vulnerabilities a leeway of 10 days is allowed.
restrict_cve_security_levels:
- critical
- high
warn_cve_security_levels:
- medium
- low
restrict_unpatched_cve_security_levels:
- critical
warn_unpatched_cve_security_levels:
- high
- medium
cve_leeway:
critical: 10
high: 10
-
Package name:
cve
5.1. Blocking CVE check
The SLSA Provenance attestation for the image is inspected to ensure CVEs that have a known fix and meet a certain security level have not been detected. If detected, this policy rule will fail. By default, only CVEs of critical and high security level cause a failure. This is configurable by the rule data key restrict_cve_security_levels
. The available levels are critical, high, medium, low, and unknown. In addition to that leeway can be granted per severity using the cve_leeway
rule data key containing days of allowed leeway, measured as time between found vulnerability’s public disclosure date and current effective time, per severity level.
Solution: Make sure to address any CVE’s related to the image. The CVEs are detected by the task that runs a Clair scan and emits a result named SCAN_OUTPUT
.
-
Rule type: FAILURE
-
FAILURE message:
Found %d CVE vulnerabilities of %s security level
-
Code:
cve.cve_blockers
5.2. Blocking unpatched CVE check
The SLSA Provenance attestation for the image is inspected to ensure CVEs that do NOT have a known fix and meet a certain security level have not been detected. If detected, this policy rule will fail. By default, the list of security levels used by this policy is empty. This is configurable by the rule data key restrict_unpatched_cve_security_levels
. The available levels are critical, high, medium, low, and unknown. In addition to that leeway can be granted per severity using the cve_leeway
rule data key containing days of allowed leeway, measured as time between found vulnerability’s public disclosure date and current effective time, per severity level.
Solution: CVEs without a known fix can only be remediated by either removing the impacted dependency, or by waiting for a fix to be available. The CVEs are detected by the task that emits a result named SCAN_OUTPUT
.
-
Rule type: FAILURE
-
FAILURE message:
Found %d unpatched CVE vulnerabilities of %s security level
-
Code:
cve.unpatched_cve_blockers
5.3. CVE scan results found
Confirm that clair-scan task results are present in the SLSA Provenance attestation of the build pipeline.
Solution: Make sure there is a successful task in the build pipeline that runs a Clair scan and creates a task result called SCAN_OUTPUT
.
-
Rule type: FAILURE
-
FAILURE message:
Clair CVE scan results were not found
-
Code:
cve.cve_results_found
5.4. Deprecated CVE result name
The CLAIR_SCAN_RESULT
result name has been deprecated, and has been replaced with SCAN_OUTPUT
. If any task results with the old name are found, this rule will raise a warning.
Solution: Use the newer SCAN_OUTPUT
result name.
-
Rule type: WARNING
-
WARNING message:
CVE scan uses deprecated result name
-
Code:
cve.deprecated_cve_result_name
5.5. Non-blocking CVE check
The SLSA Provenance attestation for the image is inspected to ensure CVEs that have a known fix and meet a certain security level have not been detected. If detected, this policy rule will raise a warning. By default, the list of CVE security levels used by this policy is empty. However, this is configurable by the rule data key warn_cve_security_levels
. The available levels are critical, high, medium, low, and unknown.
Solution: Make sure to address any CVE’s related to the image. The CVEs are detected by the task that runs a Clair scan and emits a result named SCAN_OUTPUT
.
-
Rule type: WARNING
-
WARNING message:
Found %d non-blocking CVE vulnerabilities of %s security level
-
Code:
cve.cve_warnings
5.6. Non-blocking unpatched CVE check
The SLSA Provenance attestation for the image is inspected to ensure CVEs that do NOT have a known fix and meet a certain security level have not been detected. If detected, this policy rule will raise a warning. By default, only CVEs of critical and high security level cause a warning. This is configurable by the rule data key warn_unpatched_cve_security_levels
. The available levels are critical, high, medium, low, and unknown.
Solution: CVEs without a known fix can only be remediated by either removing the impacted dependency, or by waiting for a fix to be available. The CVEs are detected by the task that emits a result named SCAN_OUTPUT
.
-
Rule type: WARNING
-
WARNING message:
Found %d non-blocking unpatched CVE vulnerabilities of %s security level
-
Code:
cve.unpatched_cve_warnings
5.7. Rule data provided
Confirm the expected rule data keys have been provided in the expected format. The keys are restrict_cve_security_levels
, warn_cve_security_levels
, restrict_unpatched_cve_security_levels
, and warn_unpatched_cve_security_levels
.
Solution: If provided, ensure the rule data is in the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
cve.rule_data_provided
6. External parameters
Verify the attribute .predicate.buildDefinition.externalParameters of a SLSA Provenance v1.0 matches the expectation.
-
Package name:
external_parameters
6.1. Pipeline run params
Verify the PipelineRun was initialized with a set of expected parameters. By default it asserts git-repo, git-revision, and output-image are provided with non-empty values. This is configurable by the rule data key pipeline_run_params
. Any additional parameters are NOT allowed.
-
Rule type: FAILURE
-
FAILURE message:
PipelineRun params, %v, do not match expectation, %v.
-
Code:
external_parameters.pipeline_run_params
6.2. PipelineRun params provided
Confirm the pipeline_run_params
rule data was provided.
Solution: Provide a non-empty list of expected PipelineRun parameters.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
external_parameters.pipeline_run_params_provided
6.3. Restrict shared volumes
Verify the PipelineRun did not use any pre-existing PersistentVolumeClaim workspaces.
-
Rule type: FAILURE
-
FAILURE message:
PipelineRun uses shared volumes, %v.
-
Code:
external_parameters.restrict_shared_volumes
7. GitHub Certificate Checks
Verify attributes on the certificate involved in the image signature when using slsa-github-generator on GitHub Actions with Sigstore Fulcio
-
Package name:
github_certificate
7.1. GitHub Workflow Certificate Extensions
Check if the image signature certificate contains the expected GitHub extensions. These are the extensions that represent the GitHub workflow trigger, sha, name, repository, and ref.
-
Rule type: WARNING
-
WARNING message:
Missing extension %q
-
Code:
github_certificate.gh_workflow_extensions
7.2. GitHub Workflow Name
Check if the value of the GitHub Workflow Name extension in the image signature certificate matches one of the allowed values. Use the rule data key allowed_gh_workflow_names
to specify the list of allowed values. An empty allow list, which is the default value, causes this check to succeeded.
-
Rule type: FAILURE
-
FAILURE message:
Name %q not in allowed list: %v
-
Code:
github_certificate.gh_workflow_name
7.3. GitHub Workflow Repository
Check if the value of the GitHub Workflow Repository extension in the image signature certificate matches one of the allowed values. Use the rule data key allowed_gh_workflow_repos
to specify the list of allowed values. An empty allow list, which is the default value, causes this check to succeeded.
-
Rule type: FAILURE
-
FAILURE message:
Repository %q not in allowed list: %v
-
Code:
github_certificate.gh_workflow_repository
7.4. GitHub Workflow Repository
Check if the value of the GitHub Workflow Ref extension in the image signature certificate matches one of the allowed values. Use the rule data key allowed_gh_workflow_refs
to specify the list of allowed values. An empty allow list, which is the default value, causes this check to succeeded.
-
Rule type: FAILURE
-
FAILURE message:
Ref %q not in allowed list: %v
-
Code:
github_certificate.gh_workflow_ref
7.5. GitHub Workflow Trigger
Check if the value of the GitHub Workflow Trigger extension in the image signature certificate matches one of the allowed values. Use the rule data key allowed_gh_workflow_triggers
to specify the list of allowed values. An empty allow list, which is the default value, causes this check to succeeded.
-
Rule type: FAILURE
-
FAILURE message:
Trigger %q not in allowed list: %v
-
Code:
github_certificate.gh_workflow_trigger
7.6. Rule data provided
Confirm the expected rule data keys have been provided in the expected format. The keys are allowed_gh_workflow_repos
, allowed_gh_workflow_refs
, allowed_gh_workflow_names
, and allowed_gh_workflow_triggers
.
Solution: If provided, ensure the rule data is in the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
github_certificate.rule_data_provided
8. Hermetic build task
This package verifies the build task in the attestation was invoked with the expected parameters to perform a hermetic build.
-
Package name:
hermetic_build_task
8.1. Build task called with hermetic param set
Verify the build task in the PipelineRun attestation was invoked with the proper parameters to make the build process hermetic.
Solution: Make sure the task that builds the image has a parameter named 'HERMETIC' and it’s set to 'true'.
-
Rule type: FAILURE
-
FAILURE message:
Build task was not invoked with the hermetic parameter set
-
Code:
hermetic_build_task.build_task_hermetic
9. Java dependency checks
This package contains a rule to confirm that all Java dependencies were rebuilt in house rather than imported directly from potentially untrusted respositories. If the result is missing no violation is reported. The rules depend on the configuration under the key 'allowed_java_component_sources', the key lists all component sources that are allowed by the policy. The values of the list can be 'rebuilt' for dependencies that have been explicitly built from sources, or the name of the Maven repository names where the dependency artifact was retrieved from. The Maven repositories are configured using the 'JBSConfig' custom resources. Default configuration in Konflux currently includes Maven repositories with names : 'jboss', 'confluent', 'redhat', 'jitpack' and 'gradle'.
-
Package name:
java
9.1. Java builds have no foreign dependencies
The SBOM_JAVA_COMPONENTS_COUNT task result finds dependencies that have originated from foreign repositories, i.e. ones that are not rebuilt or provided by Red Hat. Verify there are no dependencies from sources not listed in the allowed_java_component_sources
rule data.
Solution: Make sure there are no build dependencies that originate from foreign repositories. The allowed sources are in the rule_data under the key 'allowed_java_component_sources'.
-
Rule type: FAILURE
-
FAILURE message:
Found Java dependencies from '%s', expecting to find only from '%s'
-
Code:
java.no_foreign_dependencies
9.2. Trusted Java dependency source list was provided
Confirm the allowed_java_component_sources
rule data was provided, since it’s required by the policy rules in this package.
Solution: Add a data source that contains allowable source repositories for build dependencies. The source must be located under a key named 'allowed_java_component_sources'. More information on adding data sources.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
java.trusted_dependencies_source_list_provided
10. Labels
Check if the image has the expected labels set. The rules in this package distinguish file-based catalog (FBC) images from all other images. When checking an FBC image, a policy rule may use a different set of rule data. An FBC image is detected by the presence of the operators.operatorframework.io.index.configs.v1 label.
-
Package name:
labels
10.1. Deprecated labels
Check the image for the presence of labels that have been deprecated. Use the rule data key deprecated_labels
to set the list of labels to check.
Solution: Update the image build process to not set the deprecated labels.
-
Rule type: FAILURE
-
FAILURE message:
The %q label is deprecated, replace with %q
-
Code:
labels.deprecated_labels
10.2. Disallowed inherited labels
Check that certain labels on the image have different values than the labels from the parent image. If the label is inherited from the parent image but not redefined for the image, it will contain an incorrect value for the image. Use the rule data disallowed_inherited_labels
key to set the list of labels to check, or the fbc_disallowed_inherited_labels
key for fbc images.
Solution: Update the image build process to overwrite the inherited labels.
-
Rule type: FAILURE
-
FAILURE message:
The %q label should not be inherited from the parent image
-
Code:
labels.disallowed_inherited_labels
10.3. Inaccessible image config
The image config is not accessible.
Solution: Check the provided authentication configuration and the credentials within it.
-
Rule type: FAILURE
-
FAILURE message:
Image config of the image %q is inaccessible
-
Code:
labels.inaccessible_config
10.4. Inaccessible image manifest
The image manifest is not accessible.
Solution: Check the provided authentication configuration and the credentials within it.
-
Rule type: FAILURE
-
FAILURE message:
Manifest of the image %q is inaccessible
-
Code:
labels.inaccessible_manifest
10.5. Inaccessible parent image config
The parent image config is not accessible.
Solution: Check the provided authentication configuration and the credentials within it.
-
Rule type: FAILURE
-
FAILURE message:
Image config of the image %q, parent of image %q is inaccessible
-
Code:
labels.inaccessible_parent_config
10.6. Inaccessible parent image manifest
The parent image manifest is not accessible.
Solution: Check the provided authentication configuration and the credentials within it.
-
Rule type: FAILURE
-
FAILURE message:
Manifest of the image %q, parent of image %q is inaccessible
-
Code:
labels.inaccessible_parent_manifest
10.7. Optional labels
Check the image for the presence of labels that are recommended, but not required. Use the rule data optional_labels
key to set the list of labels to check, or the fbc_optional_labels
key for fbc images.
Solution: Update the image build process to set the optional labels.
-
Rule type: WARNING
-
WARNING message:
The optional %q label is missing. Label description: %s
-
Code:
labels.optional_labels
10.8. Required labels
Check the image for the presence of labels that are required. Use the rule data required_labels
key to set the list of labels to check, or the fbc_required_labels
key for fbc images.
Solution: Update the image build process to set the required labels.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
labels.required_labels
10.9. Rule data provided
Confirm the expected rule data keys have been provided in the expected format. The keys are required_labels
, fbc_required_labels
, optional_labels
, fbc_optional_labels
, disallowed_inherited_labels
, fbc_disallowed_inherited_labels
, and deprecated_labels
.
Solution: If provided, ensure the rule data is in the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
labels.rule_data_provided
11. OLM
Checks for Operator Lifecycle Manager (OLM) bundles.
-
Package name:
olm
11.1. ClusterServiceVersion semver format
Check the spec.version
value in the ClusterServiceVersion manifest of the OLM bundle uses a properly formatted semver.
Solution: Update the ClusterServiceVersion manifest of the OLM bundle to set the spec.version value to a valid semver.
-
Rule type: FAILURE
-
FAILURE message:
The ClusterServiceVersion spec.version, %q, is not a valid semver
-
Code:
olm.csv_semver_format
11.2. Feature annotations have expected value
Check the feature annotations in the ClusterServiceVersion manifest of the OLM bundle. All of required feature annotations must be present and set to either the string "true"
or the string "false"
. The list of feature annotations can be customize via the required_olm_features_annotations
rule data.
Solution: Update the ClusterServiceVersion manifest of the OLM bundle to set the feature annotations to the expected value.
-
Rule type: FAILURE
-
FAILURE message:
The annotation %q is either missing or has an unexpected value
-
Code:
olm.feature_annotations_format
11.3. Images referenced by OLM bundle are from allowed registries
Each image referenced by the OLM bundle should match an entry in the list of prefixes defined by the rule data key allowed_registry_prefixes
in your policy configuration.
Solution: Use image from an allowed registry, or modify your policy configuration to include additional registry prefixes.
-
Rule type: FAILURE
-
FAILURE message:
The %q CSV image reference is not from an allowed registry.
-
Code:
olm.allowed_registries
-
Effective from:
2024-09-01T00:00:00Z
11.4. Required OLM feature annotations list provided
Confirm the required_olm_features_annotations
rule data was provided, since it’s required by the policy rules in this package.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
olm.required_olm_features_annotations_provided
11.5. Subscription annotation has expected value
Check the value of the operators.openshift.io/valid-subscription annotation from the ClusterServiceVersion manifest is in the expected format, i.e. JSON encoded non-empty array of strings.
Solution: Update the ClusterServiceVersion manifest of the OLM bundle to set the subscription annotation to the expected value.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
olm.subscriptions_annotation_format
-
Effective from:
2024-04-18T00:00:00Z
11.6. Unable to access images in the input snapshot
Check the input snapshot and make sure all the images are accessible.
Solution: Ensure all images in the input snapshot are valid.
-
Rule type: FAILURE
-
FAILURE message:
The %q image reference is not accessible in the input snapshot.
-
Code:
olm.inaccessible_snapshot_references
-
Effective from:
2024-08-15T00:00:00Z
11.7. Unmapped images in OLM bundle
Check the OLM bundle image for the presence of unmapped image references. Unmapped image pull references are references to images found in varying locations that are either not in the RPA about to be released or not accessible already.
Solution: Add the missing image to the snapshot or check if the CSV pullspec is valid and accessible.
-
Rule type: FAILURE
-
FAILURE message:
The %q CSV image reference is not in the snapshot or accessible.
-
Code:
olm.unmapped_references
-
Effective from:
2024-08-15T00:00:00Z
11.8. Unpinned images in OLM bundle
Check the OLM bundle image for the presence of unpinned image references. Unpinned image pull references are references to images found in varying locations that do not contain a digest — uniquely identifying the version of the image being pulled.
Solution: Update the OLM bundle replacing the unpinned image reference with pinned image reference. Pinned image reference contains the image digest.
-
Rule type: FAILURE
-
FAILURE message:
The %q image reference is not pinned at %s.
-
Code:
olm.unpinned_references
11.9. Unpinned images in input snapshot
Check the input snapshot for the presence of unpinned image references. Unpinned image pull references are references to images that do not contain a digest — uniquely identifying the version of the image being pulled.
Solution: Update the input snapshot replacing the unpinned image reference with pinned image reference. Pinned image reference contains the image digest.
-
Rule type: FAILURE
-
FAILURE message:
The %q image reference is not pinned in the input snapshot.
-
Code:
olm.unpinned_snapshot_references
-
Effective from:
2024-08-15T00:00:00Z
12. Provenance Materials
This package provides rules for verifying the contents of the materials section of the SLSA Provenance attestation.
-
Package name:
provenance_materials
12.1. Git clone source matches materials provenance
Confirm that the result of the git-clone task is included in the materials section of the SLSA provenance attestation.
Solution: The build pipeline must contain a task named 'git-clone' and that task must emit results named 'url' and 'commit' and contain the clone git repository and commit, respectively.
-
Rule type: FAILURE
-
FAILURE message:
Entry in materials for the git repo %q and commit %q not found
-
Code:
provenance_materials.git_clone_source_matches_provenance
12.2. Git clone task found
Confirm that the attestation contains a git-clone task with commit
and url
task results.
Solution: Make sure the build pipeline contains a task named 'git-clone'.
-
Rule type: FAILURE
-
FAILURE message:
Task git-clone not found
-
Code:
provenance_materials.git_clone_task_found
13. Quay expiration
Policies to prevent releasing an image to quay that has a quay expiration date. In Konflux images with an expiration date are produced by "on-pr" build pipelines, i.e. pre-merge CI builds, so this is intended to prevent accidentally releasing a CI build.
-
Package name:
quay_expiration
13.1. Expires label
Check the image metadata for the presence of a "quay.expires-after" label. If it’s present then produce a violation. This check is enforced only for a "release" pipeline, as determined by the value of the pipeline_intention
rule data.
Solution: Make sure the image is built without setting the "quay.expires-after" label. This label is usually set if the container image was built by an "on-pr" pipeline during pre-merge CI.
-
Rule type: FAILURE
-
FAILURE message:
The image has a 'quay.expires-after' label set to '%s'
-
Code:
quay_expiration.expires_label
14. RHTAP Multi-CI
Checks for images built using an RHTAP build pipeline in either Jenkins, GitLab or GitHub. RHTAP pipelines are defined under https://github.com/redhat-appstudio/tssc-sample-templates/tree/main/skeleton/ci
-
Package name:
rhtap_multi_ci
14.1. SLSA Provenance Attestation Format
Confirm the attestation created by the RHTAP Multi-CI build pipeline matches the expected format.
Solution: This check looks for some fields expected to be present in the SLSA attestation. Modifying the scripts that produce the attestation predicate might cause this to fail. See also the att-predicate-*.sh
scripts at https://github.com/redhat-appstudio/tssc-dev-multi-ci/tree/main/rhtap
-
Rule type: FAILURE
-
FAILURE message:
RHTAP %s attestation problem: %s
-
Code:
rhtap_multi_ci.attestation_format
14.2. SLSA Provenance Attestation Found
Verify an attestation created by the RHTAP Multi-CI build pipeline is present.
Solution: It appears the build pipeline did not create the expected SLSA provenance attestation. Check for relevant error messages in the 'cosign-sign-attest' pipeline step logs.
-
Rule type: FAILURE
-
FAILURE message:
A SLSA v1.0 provenance with one of the following RHTAP Multi-CI build types was not found: %s.
-
Code:
rhtap_multi_ci.attestation_found
15. RPM Repos
This package defines rules to confirm that all RPM packages listed in SBOMs specify a known and permitted repository id.
-
Package name:
rpm_repos
15.1. All rpms have known repo ids
Each RPM package listed in an SBOM must specify the repository id that it comes from, and that repository id must be present in the list of known and permitted repository ids. Currently this is rule enforced only for SBOM components created by cachi2.
Solution: Ensure every rpm comes from a known and permitted repository, and that the data in the SBOM correctly records that.
-
Rule type: FAILURE
-
FAILURE message:
RPM repo id check failed: %s
-
Code:
rpm_repos.ids_known
-
Effective from:
2024-11-10T00:00:00Z
15.2. Known repo id list provided
A list of known and permitted repository ids should be available in the rule data.
Solution: Include a data source that provides a list of known repository ids under the 'known_rpm_repositories' key under the top level 'rule_data' key.
-
Rule type: FAILURE
-
FAILURE message:
Rule data '%s' has unexpected format: %s
-
Code:
rpm_repos.rule_data_provided
16. RPM Signature
This package provides rules for verifying the signatures of RPMs identified in the the SLSA Provenance attestation.
-
Package name:
rpm_signature
16.1. Allowed RPM signature key
The SLSA Provenance attestation for the image is inspected to ensure RPMs have been signed by pre-defined set of signing keys. The list of signing keys can be set via the allowed_rpm_signature_keys
rule data. Use the special value "unsigned" to allow unsigned RPMs.
Solution: Make sure to use RPMs that have been signed by the expected signing key. An RPM lacking such signature, usually indicated the RPM is not ready for consumption.
-
Rule type: FAILURE
-
FAILURE message:
Signing key %q is not one of the allowed keys: %s
-
Code:
rpm_signature.allowed
-
Effective from:
2024-10-05T00:00:00Z
16.2. Result format
Confirm the format of the RPMS_DATA result is in the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
rpm_signature.result_format
-
Effective from:
2024-10-05T00:00:00Z
16.3. Rule data provided
Confirm the expected allowed_rpm_signature_keys
rule data key has been provided in the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
rpm_signature.rule_data_provided
-
Effective from:
2024-10-05T00:00:00Z
17. SBOM
Checks general properties of the SBOMs associated with the image being validated. More specific rules for SPDX and CycloneDX SBOMs are in separate packages.
-
Package name:
sbom
17.1. Disallowed packages list is provided
Confirm the disallowed_packages
and disallowed_attributes
rule data were provided, since they are required by the policy rules in this package.
Solution: Provide a list of disallowed packages or package attributes in the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
sbom.disallowed_packages_provided
18. SBOM CycloneDX
Checks different properties of the CycloneDX SBOMs associated with the image being validated.
-
Package name:
sbom_cyclonedx
18.1. Allowed
Confirm the CycloneDX SBOM contains only allowed packages. By default all packages are allowed. Use the "disallowed_packages" rule data key to provide a list of disallowed packages.
Solution: Update the image to not use a disallowed package.
-
Rule type: FAILURE
-
FAILURE message:
Package is not allowed: %s
-
Code:
sbom_cyclonedx.allowed
18.2. Allowed package external references
Confirm the CycloneDX SBOM contains only packages with explicitly allowed external references. By default all external references are allowed unless the "allowed_external_references" rule data key provides a list of type-pattern pairs that forbid the use of any other external reference of the given type where the reference url matches the given pattern.
Solution: Update the image to use only packages with explicitly allowed external references.
-
Rule type: FAILURE
-
FAILURE message:
Package %s has reference %q of type %q which is not explicitly allowed%s
-
Code:
sbom_cyclonedx.allowed_package_external_references
18.3. Allowed package sources
For each of the components fetched by Cachi2 which define externalReferences of type distribution, verify they are allowed based on the allowed_package_sources rule data key. By default, allowed_package_sources is empty, which means no components with such references are allowed.
Solution: Update the image to not use a package from a disallowed source.
-
Rule type: FAILURE
-
FAILURE message:
Package %s fetched by cachi2 was sourced from %q which is not allowed
-
Code:
sbom_cyclonedx.allowed_package_sources
-
Effective from:
2024-12-15T00:00:00Z
18.4. Disallowed package attributes
Confirm the CycloneDX SBOM contains only packages without disallowed attributes. By default all attributes are allowed. Use the "disallowed_attributes" rule data key to provide a list of key-value pairs that forbid the use of an attribute set to the given value.
Solution: Update the image to not use a disallowed package attributes.
-
Rule type: FAILURE
-
FAILURE message:
Package %s has the attribute %q set%s
-
Code:
sbom_cyclonedx.disallowed_package_attributes
-
Effective from:
2024-07-31T00:00:00Z
18.5. Disallowed package external references
Confirm the CycloneDX SBOM contains only packages without disallowed external references. By default all external references are allowed. Use the "disallowed_external_references" rule data key to provide a list of type-pattern pairs that forbid the use of an external reference of the given type where the reference url matches the given pattern.
Solution: Update the image to not use a package with a disallowed external reference.
-
Rule type: FAILURE
-
FAILURE message:
Package %s has reference %q of type %q which is disallowed%s
-
Code:
sbom_cyclonedx.disallowed_package_external_references
-
Effective from:
2024-07-31T00:00:00Z
18.6. Valid
Check the CycloneDX SBOM has the expected format. It verifies the CycloneDX SBOM matches the 1.5 version of the schema.
Solution: Make sure the build process produces a valid CycloneDX SBOM.
-
Rule type: FAILURE
-
FAILURE message:
CycloneDX SBOM at index %d is not valid: %s
-
Code:
sbom_cyclonedx.valid
19. SLSA - Build - Build Service
The SLSA requirement states the following: "All build steps ran using some build service, not on a developer’s workstation." This package verifies the requirement by asserting the image was built by Tekton Pipelines.
-
Package name:
slsa_build_build_service
19.1. Allowed builder IDs provided
Confirm the allowed_builder_ids
rule data was provided, since it is required by the policy rules in this package.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
slsa_build_build_service.allowed_builder_ids_provided
19.2. SLSA Builder ID found
Verify that the attestation attribute predicate.builder.id is set.
Solution: The builder id in the attestation is missing. Make sure the build system is setting the build id when generating an attestation.
-
Rule type: FAILURE
-
FAILURE message:
Builder ID not set in attestation
-
Code:
slsa_build_build_service.slsa_builder_id_found
19.3. SLSA Builder ID is known and accepted
Verify that the attestation attribute predicate.builder.id is set to one of the values in the allowed_builder_ids
rule data, e.g. "https://tekton.dev/chains/v2".
Solution: Make sure the build id is set to an expected value. The expected values are set in the data sources.
-
Rule type: FAILURE
-
FAILURE message:
Builder ID %q is unexpected
-
Code:
slsa_build_build_service.slsa_builder_id_accepted
20. SLSA - Build - Scripted Build
The SLSA requirement states the following: "All build steps were fully defined in some sort of “build script”. The only manual command, if any, was to invoke the build script." This package verifies the requirement by asserting the image was built by Tekton Pipelines.
-
Package name:
slsa_build_scripted_build
20.1. Build task contains steps
Verify that the predicate.buildConfig.tasks.steps attribute for the task responsible for building and pushing the image is not empty.
Solution: There were no build tasks detected. Make sure the build pipeline contains tasks and that the build system is recording them properly when the attestation is generated.
-
Rule type: FAILURE
-
FAILURE message:
Build task %q does not contain any steps
-
Code:
slsa_build_scripted_build.build_script_used
20.2. Build task set image digest and url task results
Confirm that a build task exists and it has the expected IMAGE_DIGEST and IMAGE_URL task results.
Solution: Make sure the build pipeline contains a build task. The build task must contain results named 'IMAGE_DIGEST' and 'IMAGE_URL'.
-
Rule type: FAILURE
-
FAILURE message:
Build task not found
-
Code:
slsa_build_scripted_build.build_task_image_results_found
20.3. Image built by trusted Task
Verify the digest of the image being validated is reported by a trusted Task in its IMAGE_DIGEST result.
Solution: Make sure the build Pipeline definition uses a trusted Task to build images.
-
Rule type: FAILURE
-
FAILURE message:
Image %q not built by a trusted task: %s
-
Code:
slsa_build_scripted_build.image_built_by_trusted_task
20.4. Provenance subject matches build task image result
Verify the subject of the attestations matches the IMAGE_DIGEST and IMAGE_URL values from the build task.
Solution: Make sure the subject in the attestation matches the 'IMAGE_URL' and 'IMAGE_DIGEST' results from the build task. The format for the subject should be 'IMAGE_URL@IMAGE_DIGEST'.
-
Rule type: FAILURE
-
FAILURE message:
The attestation subject, %q, does not match any of the images built
-
Code:
slsa_build_scripted_build.subject_build_task_matches
21. SLSA - Provenance - Available
The SLSA Provenance Available requirement states the following: "The provenance is available to the consumer in a format that the consumer accepts. The format SHOULD be in-toto SLSA Provenance, but another format MAY be used if both producer and consumer agree and it meets all the other requirements." This package only accepts the in-toto SLSA Provenance format.
-
Package name:
slsa_provenance_available
21.1. Allowed predicate types provided
Confirm the allowed_predicate_types
rule data was provided, since it is required by the policy rules in this package.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
slsa_provenance_available.allowed_predicate_types_provided
21.2. Expected attestation predicate type found
Verify that the predicateType field of the attestation indicates the in-toto SLSA Provenance format was used to attest the PipelineRun.
Solution: The predicate type field in the attestation does not match the 'allowed_predicate_types' field. This field is set in the data sources.
-
Rule type: FAILURE
-
FAILURE message:
Attestation predicate type %q is not an expected type (%s)
-
Code:
slsa_provenance_available.attestation_predicate_type_accepted
22. SLSA - Source - Version Controlled
The SLSA requirement states the following: "Every change to the source is tracked in a version control system that meets the following requirements:
[Change history] There exists a record of the history of changes that went into the revision. Each change must contain: the identities of the uploader and reviewers (if any), timestamps of the reviews (if any) and submission, the change description/justification, the content of the change, and the parent revisions.
[Immutable reference] There exists a way to indefinitely reference this particular, immutable revision. In git, this is the {repo URL + branch/tag/ref + commit ID}.
Most popular version control system meet this requirement, such as git, Mercurial, Subversion, or Perforce." This package verifies the requirement by asserting the image was built from a git repository.
-
Package name:
slsa_source_version_controlled
22.1. Material uri is a git repo
Ensure each entry in the predicate.materials array with a SHA-1 digest includes a valid Git URI.
Solution: Ensure the URI associated with a SHA-1 digest in the materials section of the attestation is valid. This URI is derived from the 'CHAINS-GIT_URL' output of the 'git-clone' task.
-
Rule type: FAILURE
-
FAILURE message:
Material URI %q is not a git URI
-
Code:
slsa_source_version_controlled.materials_uri_is_git_repo
22.2. Materials have uri and digest
Confirm at least one entry in the predicate.materials array of the attestation contains the expected attributes: uri and digest.sha1.
Solution: Make sure the attestation contains the repository URI and digest.sha1. This information comes from the 'CHAINS-GIT_URL' and 'CHAINS-GIT_COMMIT' results in the 'git-clone' task.
-
Rule type: FAILURE
-
FAILURE message:
No materials match expected format
-
Code:
slsa_source_version_controlled.materials_format_okay
22.3. Materials include git commit shas
Ensure that each entry in the predicate.materials array with a SHA-1 digest includes a valid Git commit SHA.
Solution: Ensure the digest.sha1 in the materials section of the attestation is a valid Git commit SHA. This commit information is derived from the 'CHAINS-GIT_COMMIT' output of the 'git-clone' task.
-
Rule type: FAILURE
-
FAILURE message:
Material digest %q is not a git commit sha
-
Code:
slsa_source_version_controlled.materials_include_git_sha
23. SLSA - Verification model - Source
SLSA v1 verification model states: "…artifacts are verified to ensure they meet the producer defined expectations of where the package source code was retrieved from…" This package correlates the provided source code reference with the source code referenced in the attestation.
-
Package name:
slsa_source_correlated
23.1. Expected source code reference
Verify that the provided source code reference is the one being attested.
Solution: The source code reference in the attestation doesn’t match the expected and provided source code reference. Make sure that the provided source code reference is correct, and if it is make sure that the build process is configured to retrieve the source code from the appropriate source code repository. Make sure that the source code reference is pointing to a explicit revision not to a symbolic identifier, e.g. a branch or tag name.
-
Rule type: FAILURE
-
FAILURE message:
The expected source code reference %q is not attested
-
Code:
slsa_source_correlated.expected_source_code_reference
23.2. Rule data provided
Confirm the expected rule data keys have been provided in the expected format. The keys are supported_vcs
and supported_digests
.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
slsa_source_correlated.rule_data_provided
23.3. Source code reference provided
Check if the expected source code reference is provided.
Solution: Provide the expected source code reference in inputs.
-
Rule type: FAILURE
-
FAILURE message:
Expected source code reference was not provided for verification
-
Code:
slsa_source_correlated.source_code_reference_provided
23.4. Source reference
Attestation contains source reference.
Solution: Check that the attestation creation process includes the source code reference in the predicate.materials for SLSA Provenance v0.2, or in predicate.buildDefinition.resolvedDependencies for SLSA Provenance v1.0 attestations. Check that the Version Control System prefix is the list of the supported VCS types in rule data (supported_vcs
key).
-
Rule type: FAILURE
-
FAILURE message:
The attested material contains no source code reference
-
Code:
slsa_source_correlated.attested_source_code_reference
24. SPDX SBOM
Checks different properties of the CycloneDX SBOMs associated with the image being validated.
-
Package name:
sbom_spdx
24.1. Allowed
Confirm the SPDX SBOM contains only allowed packages. By default all packages are allowed. Use the "disallowed_packages" rule data key to provide a list of disallowed packages.
Solution: Update the image to not use a disallowed package.
-
Rule type: FAILURE
-
FAILURE message:
Package is not allowed: %s
-
Code:
sbom_spdx.allowed
24.2. Allowed package external references
Confirm the SPDX SBOM contains only packages with explicitly allowed external references. By default all external references are allowed unless the "allowed_external_references" rule data key provides a list of type-pattern pairs that forbid the use of any other external reference of the given type where the reference url matches the given pattern.
Solution: Update the image to use only packages with explicitly allowed external references.
-
Rule type: FAILURE
-
FAILURE message:
Package %s has reference %q of type %q which is not explicitly allowed%s
-
Code:
sbom_spdx.allowed_package_external_references
24.3. Contains files
Check the list of files in the SPDX SBOM is not empty.
Solution: Verify the SBOM is correctly identifying the files in the image.
-
Rule type: FAILURE
-
FAILURE message:
The list of files is empty
-
Code:
sbom_spdx.contains_files
24.4. Contains packages
Check the list of packages in the SPDX SBOM is not empty.
Solution: Verify the SBOM is correctly identifying the package in the image.
-
Rule type: FAILURE
-
FAILURE message:
The list of packages is empty
-
Code:
sbom_spdx.contains_packages
24.5. Disallowed package external references
Confirm the SPDX SBOM contains only packages without disallowed external references. By default all external references are allowed. Use the "disallowed_external_references" rule data key to provide a list of type-pattern pairs that forbid the use of an external reference of the given type where the reference url matches the given pattern.
Solution: Update the image to not use a package with a disallowed external reference.
-
Rule type: FAILURE
-
FAILURE message:
Package %s has reference %q of type %q which is disallowed%s
-
Code:
sbom_spdx.disallowed_package_external_references
-
Effective from:
2024-07-31T00:00:00Z
24.6. Matches image
Check the SPDX SBOM targets the image being validated.
Solution: The SPDX SBOM associated with the image describes a different image. Verify the integrity of the build system.
-
Rule type: FAILURE
-
FAILURE message:
Image digest in the SBOM, %q, is not as expected, %q
-
Code:
sbom_spdx.matches_image
25. Schedule related checks
Rules that verify the current date conform to a given schedule.
-
Package name:
schedule
25.1. Date Restriction
Check if the current date is not allowed based on the rule data value from the key disallowed_dates
. By default, the list is empty in which case any day is allowed. This check is enforced only for a "release" pipeline, as determined by the value of the pipeline_intention
rule data.
Solution: Try again on a different day.
-
Rule type: FAILURE
-
FAILURE message:
%s is a disallowed date: %s
-
Code:
schedule.date_restriction
25.2. Rule data provided
Confirm the expected rule data keys have been provided in the expected format. The keys are disallowed_weekdays
and disallowed_dates
.
Solution: If provided, ensure the rule data is in the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
schedule.rule_data_provided
25.3. Weekday Restriction
Check if the current weekday is allowed based on the rule data value from the key disallowed_weekdays
. By default, the list is empty in which case any weekday is allowed. This check is enforced only for a "release" pipeline, as determined by the value of the pipeline_intention
rule data.
Solution: Try again on a different weekday.
-
Rule type: FAILURE
-
FAILURE message:
%s is a disallowed weekday: %s
-
Code:
schedule.weekday_restriction
26. Source image
This package is reponsible for verifying the source container image associated with the image being validated.
-
Package name:
source_image
26.1. Exists
Verify the source container image exists.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
source_image.exists
-
Effective from:
2024-06-05T00:00:00Z
27. Task bundle checks
To be able to reproduce and audit builds accurately it’s important to know exactly what happened during the build. To do this Enterprise Contract requires that all tasks are defined in a set of known and trusted task bundles. This package includes rules to confirm that the tasks that built the image were defined in task bundles, and that the task bundles used are from the list of known and trusted bundles.
-
Package name:
attestation_task_bundle
27.1. A trusted Tekton bundles list was provided
Confirm the trusted_tasks
rule data was provided, since it’s required by the policy rules in this package.
Solution: Create a lsit of trusted tasks. This is a list of task bundles with a top-level key of 'trusted_tasks'.
-
Rule type: FAILURE
-
FAILURE message:
Missing required trusted_tasks data
-
Code:
attestation_task_bundle.trusted_bundles_provided
27.2. Task bundle references not empty
Check that a valid task bundle reference is being used.
Solution: Specify a task bundle with a reference as the full digest.
-
Rule type: FAILURE
-
FAILURE message:
Pipeline task '%s' uses an empty bundle image reference
-
Code:
attestation_task_bundle.task_ref_bundles_not_empty
27.3. Task bundle references pinned to digest
Check if the Tekton Bundle used for the Tasks in the Pipeline definition is pinned to a digest.
Solution: Specify the task bundle reference with a full digest rather than a tag.
-
Rule type: WARNING
-
WARNING message:
Pipeline task '%s' uses an unpinned task bundle reference '%s'
-
Code:
attestation_task_bundle.task_ref_bundles_pinned
27.4. Task bundles are in trusted tasks list
For each Task in the SLSA Provenance attestation, check if the Tekton Bundle used is a trusted task.
Solution: For each Task in the SLSA Provenance attestation, check if the Tekton Bundle used is a trusted task.
-
Rule type: FAILURE
-
FAILURE message:
Pipeline task '%s' uses an untrusted task bundle '%s'
-
Code:
attestation_task_bundle.task_ref_bundles_trusted
27.5. Task bundles are latest versions
For each Task in the SLSA Provenance attestation, check if the Tekton Bundle used is the most recent.
Solution: A task bundle used is not the most recent. The most recent task bundles are defined in the data source of your policy config.
-
Rule type: WARNING
-
WARNING message:
Pipeline task '%s' uses an out of date task bundle '%s', new version of the Task must be used before %s
-
Code:
attestation_task_bundle.task_ref_bundles_current
27.6. Tasks defined using bundle references
Check for the existence of a task bundle. This rule will fail if the task is not called from a bundle.
-
Rule type: FAILURE
-
FAILURE message:
Pipeline task '%s' does not contain a bundle reference
-
Code:
attestation_task_bundle.tasks_defined_in_bundle
28. Tasks
Enterprise Contract expects that a set of tasks were included in the pipeline build for each image to be released. This package includes a set of rules to verify that the expected tasks ran in the pipeline when the image was built. Required tasks for a pipeline are specified in a data source provided at runtime. This data source features two primary rule data keys: pipeline-required-tasks and required-tasks. The pipeline-required-tasks key lists all required tasks broken down by pipeline name, while required-tasks details a default or baseline set of tasks. If your pipeline corresponds to an entry under pipeline-required-tasks, those tasks will be prioritized; otherwise, the system will default to the tasks listed under required-tasks. Required tasks are listed by the names given to them within the task definition. Optionally invocation parameter of a Task can be also mandated by including the name and the value in square brackets following the name of the task. For example: name[PARAM=val]. Only single parameter is supported, to assert multiple parameters repeat the required task definition for each parameter seperately.
-
Package name:
tasks
28.1. All required tasks are from trusted tasks
Ensure that the all required tasks are resolved from trusted tasks.
Solution: Make sure all required tasks in the build pipeline are resolved from trusted tasks.
-
Rule type: WARNING
-
WARNING message:
%s is required and present but not from a trusted task
-
Code:
tasks.required_untrusted_task_found
28.2. All required tasks were included in the pipeline
Ensure that the set of required tasks are included in the PipelineRun attestation.
Solution: Make sure all required tasks are in the build pipeline. The required task list is contained as data under the key 'required-tasks'.
-
Rule type: FAILURE
-
FAILURE message:
%s is missing
-
Code:
tasks.required_tasks_found
28.3. Data provided
Confirm the expected data keys have been provided in the expected format. The keys are pipeline-required-tasks
and required-tasks
.
Solution: If provided, ensure the data is in the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
tasks.data_provided
28.4. Future required tasks were found
Produce a warning when a task that will be required in the future was not included in the PipelineRun attestation.
Solution: There is a task that will be required at a future date that is missing from the build pipeline.
-
Rule type: WARNING
-
WARNING message:
%s is missing and will be required on %s
-
Code:
tasks.future_required_tasks_found
28.5. Pinned Task references
Ensure that all Tasks in the SLSA Provenance attestation use an immuntable reference to the Task definition.
Solution: Make sure the build pipeline uses Tasks via pinned references. For example, if the git resolver is used, use a commit ID instead of a branch name.
-
Rule type: FAILURE
-
FAILURE message:
Task %s is used by pipeline task %s via an unpinned reference.
-
Code:
tasks.pinned_task_refs
28.6. Pipeline run includes at least one task
Ensure that at least one Task is present in the PipelineRun attestation.
Solution: Make sure the build pipeline ran any tasks and that the build system is generating a proper attestation.
-
Rule type: FAILURE
-
FAILURE message:
No tasks found in PipelineRun attestation
-
Code:
tasks.pipeline_has_tasks
28.7. Required tasks list for pipeline was provided
Produce a warning if the required tasks list rule data was not provided.
Solution: The required task list is contained as data under the key 'required-tasks'. Make sure this list exists.
-
Rule type: WARNING
-
WARNING message:
Required tasks do not exist for pipeline
-
Code:
tasks.pipeline_required_tasks_list_provided
28.8. Required tasks list was provided
Confirm the required-tasks
rule data was provided, since it’s required by the policy rules in this package.
Solution: Make sure the data sources contains a key 'required-tasks' that contains a list of tasks that are required to run in the build pipeline.
-
Rule type: FAILURE
-
FAILURE message:
Missing required required-tasks data
-
Code:
tasks.required_tasks_list_provided
28.9. Successful pipeline tasks
Ensure that all of the Tasks in the Pipeline completed successfully. Note that skipped Tasks are not taken into account and do not influence the outcome.
Solution: Make sure the build pipeline is properly configured so all the tasks can be executed successfully.
-
Rule type: FAILURE
-
FAILURE message:
Pipeline task %q did not complete successfully, %q
-
Code:
tasks.successful_pipeline_tasks
28.10. Task version unsupported
The Tekton Task used is or will be unsupported. The Task is annotated with build.appstudio.redhat.com/expires-on
annotation marking it as unsupported after a certain date.
-
Rule type: FAILURE
-
FAILURE message:
Task %q is used by pipeline task %q is or will be unsupported as of %s. %s
-
Code:
tasks.unsupported
29. Test
Enterprise Contract requires that each build was subjected to a set of tests and that those tests all passed. This package includes a set of rules to verify that.
-
Package name:
test
29.1. Image digest is present in IMAGES_PROCESSED result
Ensure that task producing the IMAGES_PROCESSED result contains the digests of the built image.
Solution: Found an image not processed by a task. Make sure that the task processes and includes the image digest of all images in the IMAGES_PROCESSED
result.
-
Rule type: FAILURE
-
FAILURE message:
Test '%s' did not process image with digest '%s'.
-
Code:
test.test_all_images
-
Effective from:
2024-05-29T00:00:00Z
29.2. No informative tests failed
Produce a warning if any informative tests have their result set to "FAILED". The result type is configurable by the "failed_tests_results" key, and the list of informative tests is configurable by the "informative_tests" key in the rule data.
Solution: There is a test that failed. Make sure that any task in the build pipeline with a result named 'TEST_OUTPUT' does not fail. More information about the test should be available in the logs for the build Pipeline.
-
Rule type: WARNING
-
WARNING message:
The Task %q from the build Pipeline reports a failed informative test
-
Code:
test.no_failed_informative_tests
29.3. No tests erred
Produce a violation if any tests have their result set to "ERROR". The result type is configurable by the "erred_tests_results" key in the rule data.
Solution: There is a test that erred. Make sure that any task in the build pipeline with a result named 'TEST_OUTPUT' does not err. More information about the test should be available in the logs for the build Pipeline.
-
Rule type: FAILURE
-
FAILURE message:
The Task %q from the build Pipeline reports a test erred
-
Code:
test.no_erred_tests
29.4. No tests failed
Produce a violation if any non-informative tests have their result set to "FAILED". The result type is configurable by the "failed_tests_results" key, and the list of informative tests is configurable by the "informative_tests" key in the rule data.
Solution: There is a test that failed. Make sure that any task in the build pipeline with a result named 'TEST_OUTPUT' does not fail. More information about the test should be available in the logs for the build Pipeline.
-
Rule type: FAILURE
-
FAILURE message:
The Task %q from the build Pipeline reports a failed test
-
Code:
test.no_failed_tests
29.5. No tests produced warnings
Produce a warning if any tests have their result set to "WARNING". The result type is configurable by the "warned_tests_results" key in the rule data.
Solution: There is a task with result 'TEST_OUTPUT' that returned a result of 'WARNING'. You can find which test resulted in 'WARNING' by examining the 'result' key in the 'TEST_OUTPUT'. More information about the test should be available in the logs for the build Pipeline.
-
Rule type: WARNING
-
WARNING message:
The Task %q from the build Pipeline reports a test contains warnings
-
Code:
test.no_test_warnings
29.6. No tests were skipped
Produce a violation if any tests have their result set to "SKIPPED". A skipped result means a pre-requirement for executing the test was not met, e.g. a license key for executing a scanner was not provided. The result type is configurable by the "skipped_tests_results" key in the rule data.
Solution: There is a test that was skipped. Make sure that each task with a result named 'TEST_OUTPUT' was not skipped. You can find which test was skipped by examining the 'result' key in the 'TEST_OUTPUT'. More information about the test should be available in the logs for the build Pipeline.
-
Rule type: FAILURE
-
FAILURE message:
The Task %q from the build Pipeline reports a test was skipped
-
Code:
test.no_skipped_tests
-
Effective from:
2023-12-08T00:00:00Z
29.7. No unsupported test result values found
Ensure all test data result values are in the set of known/supported result values.
Solution: The test results should be of a known value. Values can be set as a data source.
-
Rule type: FAILURE
-
FAILURE message:
The Task %q from the build Pipeline has an unsupported test result %q
-
Code:
test.test_results_known
29.8. Rule data provided
Confirm the expected rule data keys have been provided in the expected format. The keys are supported_tests_results
, failed_tests_results
, informative_tests
, erred_tests_results
, skipped_tests_results
, and warned_tests_results
.
Solution: If provided, ensure the rule data is in the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
test.rule_data_provided
29.9. Test data found in task results
Ensure that at least one of the tasks in the pipeline includes a TEST_OUTPUT task result, which is where Enterprise Contract expects to find test result data.
Solution: Confirm at least one task in the build pipeline contains a result named TEST_OUTPUT.
-
Rule type: FAILURE
-
FAILURE message:
No test data found
-
Code:
test.test_data_found
29.10. Test data includes results key
Each test result is expected to have a results
key. Verify that the results
key is present in all of the TEST_OUTPUT task results.
Solution: There was at least one result named TEST_OUTPUT found, but it did not contain a key named 'result'. For a TEST_OUTPUT result to be valid, this key must exist.
-
Rule type: FAILURE
-
FAILURE message:
Found tests without results
-
Code:
test.test_results_found
30. Trusted Task checks
This package is used to verify all the Tekton Tasks involved in building the image are trusted. Trust is established by comparing the Task references found in the SLSA Provenance with a pre-defined list of trusted Tasks, which is expected to be provided as a data source that creates the data.trusted_tasks
in the format demonstrated at https://github.com/enterprise-contract/ec-policies/blob/main/example/data/trusted_tekton_tasks.yml. The list can be extended or customized using the trusted_tasks
rule data key which is merged into the trusted_tasks
data.
-
Package name:
trusted_task
30.1. Data format
Confirm the expected trusted_tasks
data keys have been provided in the expected format.
Solution: If provided, ensure the data is in the expected format.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
trusted_task.data_format
30.2. Task references are pinned
Check if all Tekton Tasks use a Task definition by a pinned reference. When using the git resolver, a commit ID is expected for the revision parameter. When using the bundles resolver, the bundle parameter is expected to include an image reference with a digest.
Solution: Update the Pipeline definition so that all Task references have a pinned value as mentioned in the description.
-
Rule type: WARNING
-
WARNING message:
Pipeline task %q uses an unpinned task reference, %s
-
Code:
trusted_task.pinned
-
Effective from:
2024-05-07T00:00:00Z
30.3. Task tracking data was provided
Confirm the trusted_tasks
rule data was provided, since it’s required by the policy rules in this package.
Solution: Create a, or use an existing, trusted tasks list as a data source.
-
Rule type: FAILURE
-
FAILURE message:
Missing required trusted_tasks data
-
Code:
trusted_task.data
-
Effective from:
2024-05-07T00:00:00Z
30.4. Tasks are trusted
Check the trust of the Tekton Tasks used in the build Pipeline. There are two modes in which trust is verified. The first mode is used if Trusted Artifacts are enabled. In this case, a chain of trust is established for all the Tasks involved in creating an artifact. If the chain contains an untrusted Task, then a violation is emitted. The second mode is used as a fallback when Trusted Artifacts are not enabled. In this case, all Tasks in the build Pipeline must be trusted.
Solution: If using Trusted Artifacts, be sure every Task in the build Pipeline responsible for producing a Trusted Artifact is trusted. Otherwise, ensure all Tasks in the build Pipeline are trusted. Note that trust is eventually revoked from Tasks when newer versions are made available.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
trusted_task.trusted
-
Effective from:
2024-05-07T00:00:00Z
30.5. Tasks using the latest versions
Check if all Tekton Tasks use the latest known Task reference. When warnings will be reported can be configured using the task_expiry_warning_days
rule data setting. It holds the number of days before the task is to expire within which the warnings will be reported.
Solution: Update the Task reference to a newer version.
-
Rule type: WARNING
-
WARNING message:
Pipeline task %q uses an out of date task reference, %s. A new version of the task must be used before %s
-
Code:
trusted_task.current
-
Effective from:
2024-05-07T00:00:00Z
30.6. Trusted Artifact produced in pipeline
All input trusted artifacts must be produced on the pipeline. If they are not the artifact could have been injected by a rouge task.
Solution: Audit the pipeline to make sure all inputs are produced by the pipeline.
-
Rule type: FAILURE
-
FAILURE message:
Code tampering detected, input %q for task %q was not produced by the pipeline as attested.
-
Code:
trusted_task.valid_trusted_artifact_inputs
30.7. Trusted parameters
Confirm certain parameters provided to each builder Task have come from trusted Tasks.
Solution: Update your build Pipeline to ensure all the parameters provided to your builder Tasks come from trusted Tasks.
-
Rule type: FAILURE
-
FAILURE message:
The %q parameter of the %q PipelineTask includes an untrusted digest: %s
-
Code:
trusted_task.trusted_parameters
-
Effective from:
2021-07-04T00:00:00Z
31. rpm-ostree Task
This package is responsible for verifying the rpm-ostree Tekton Task was executed with the expected parameters.
-
Package name:
rpm_ostree_task
31.1. Builder image parameter
Verify the BUILDER_IMAGE parameter of the rpm-ostree Task uses an image reference that is both pinned to a digest and starts with a pre-defined list of prefixes. By default, the list of prefixes is empty allowing any pinned image reference to be used. This is customizable via the allowed_rpm_ostree_builder_image_prefixes
rule data.
Solution: Make sure the rpm-ostree Task uses a pinned image reference from a pre-approved location.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
rpm_ostree_task.builder_image_param
-
Effective from:
2024-03-20T00:00:00Z
31.2. Rule data
Verify the rule data used by this package, allowed_rpm_ostree_builder_image_prefixes
, is in the expected format.
Solution: Make sure the allowed_rpm_ostree_builder_image_prefixes
rule data is in the expected format in the data source.
-
Rule type: FAILURE
-
FAILURE message:
%s
-
Code:
rpm_ostree_task.rule_data