Release Policy

These rules are applied to pipeline run attestations associated with container images built by Konflux.

1. Available rule collections

Name

Description

builtin

Includes a set of always on builtin policies. Note that builtin policies are always included and cannot be skipped regardless of your policy configuration.

Rules included:

github

minimal

Includes a minimal set of policy rules to ensure the build pipeline is functioning as expected, and able to produce signed attestations of the expected type.

Rules included:

policy_data

redhat

Include the set of policy rules required for Red Hat products.

Rules included:

slsa3

2. Attestation type

Sanity checks related to the format of the image build’s attestation.

  • Package name: attestation_type

  • Package full path: policy.release.attestation_type

2.1. 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

  • Source

2.2. 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

  • Source

2.3. 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

  • Source

2.4. 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

  • Source

3. Base image checks

This package is responsible for verifying the base (parent) images reported in the attestation are acceptable.

  • Package name: base_image_registries

  • Package full path: policy.release.base_image_registries

3.1. 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.

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

  • Source

3.2. Base image task result was provided

Verify the attestation provides the expected information about which base images were used during the build process. The base image information is expected to be found in a task result called BASE_IMAGES_DIGESTS.

Solution: A Tekton task must exist that emits a result named BASE_IMAGES_DIGESTS.

  • Rule type: FAILURE

  • Failure message: Base images result is missing

  • Code: base_image_registries.base_image_info_found

  • Source

3.3. 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

  • Source

4. Buildah build task

This package is responsible for verifying the buildah build task

  • Package name: buildah_build_task

  • Package full path: policy.release.buildah_build_task

4.1. Buildah task has Dockerfile param defined

Verify that a DOCKERFILE parameter was provided to the buildah task.

Solution: Make sure the buildah task has a parameter named 'DOCKERFILE'.

  • Rule type: FAILURE

  • Failure message: The pipeline task %q does not contain the DOCKERFILE param. This is a requirement for the underlying task %q

  • Code: buildah_build_task.buildah_task_has_dockerfile_param

  • Source

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

  • Source

5. Builtin attestation policies

This package is responsible for validating attestation signature and syntax. Note that builtin policies are always included and cannot be skipped regardless of your policy.

  • Package name: builtin_attestation

  • Package full path: policy.release.builtin.attestation

5.1. Attestation signature

Validates the cryptographic signature of the attestation.

Solution: Examine the signature of the attestation, provided key material or trust chain for verification.

  • Rule type: FAILURE

  • Failure message: No image attestations found matching the given public key. Verify the correct public key was provided, and one or more attestations were created.

  • Code: builtin_attestation.signature_check

  • Source

5.2. Attestation syntax

Validates the syntax of the attestation.

Solution: Make sure that the attestation is well formed and syntactically correct.

  • Rule type: FAILURE

  • Failure message: Attestation syntax check failed: %s

  • Code: builtin_attestation.syntax_check

  • Source

6. Builtin image policies

This package is responsible for validating image signature. Note that builtin policies are always included and cannot be skipped regardless of your policy configuration.

  • Package name: builtin_image

  • Package full path: policy.release.builtin.image

6.1. Image signature

Validates the cryptographic signature of the image.

Solution: Examine the signature of the image, provided key material or trust chain for verification.

  • Rule type: FAILURE

  • Failure message: No image signatures found matching the given public key. Verify the correct public key was provided, and a signature was created.

  • Code: builtin_image.signature_check

  • Source

7. 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.

  • Package name: cve

  • Package full path: policy.release.cve

7.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.

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 `CLAIR_SCAN_RESULT`.

  • Rule type: FAILURE

  • Failure message: Found %d CVE vulnerabilities of %s security level

  • Code: cve.cve_blockers

  • Source

7.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.

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 `CLAIR_SCAN_RESULT`.

  • Rule type: FAILURE

  • Failure message: Found %d unpatched CVE vulnerabilities of %s security level

  • Code: cve.unpatched_cve_blockers

  • Source

7.3. 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 `CLAIR_SCAN_RESULT`.

  • Rule type: WARNING

  • Warning message: Found %d non-blocking CVE vulnerabilities of %s security level

  • Code: cve.cve_warnings

  • Source

7.4. 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 `CLAIR_SCAN_RESULT`.

  • Rule type: WARNING

  • Warning message: Found %d non-blocking unpatched CVE vulnerabilities of %s security level

  • Code: cve.unpatched_cve_warnings

  • Source

7.5. 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 `CLAIR_SCAN_RESULT`.

  • Rule type: FAILURE

  • Failure message: Clair CVE scan results were not found

  • Code: cve.cve_results_found

  • Source

7.6. 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

  • Source

7.7. Deprecated CVE result name for unpatched vulnerabilities

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, including for unpached vulnerabilities.

  • Rule type: WARNING

  • Warning message: CVE scan uses deprecated result name

  • Code: cve.deprecated_unpatched_cve_result_name

  • Source

7.8. 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

  • Source

8. External parameters

Verify the attribute .predicate.buildDefinition.externalParameters of a SLSA Provenance v1.0 matches the expectation.

  • Package name: external_parameters

  • Package full path: policy.release.external_parameters

8.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

  • Source

8.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

  • Source

8.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

  • Source

9. 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

  • Package full path: policy.release.github_certificate

9.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

  • Source

9.2. 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

  • Source

9.3. 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

  • Source

9.4. 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

  • Source

9.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

  • Source

9.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

  • Source

10. 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

  • Package full path: policy.release.hermetic_build_task

10.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

  • Source

11. 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

  • Package full path: policy.release.java

11.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

  • Source

11.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

  • Source

12. 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

  • Package full path: policy.release.labels

12.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

  • Source

12.2. 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: The required %q label is missing. Label description: %s

  • Code: labels.required_labels

  • Source

12.3. 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

  • Source

12.4. 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

  • Source

12.5. 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

  • Source

13. Olm

Checks for Operator Lifecycle Manager (OLM) bundles.

  • Package name: olm

  • Package full path: policy.release.olm

13.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

  • Source

13.2. 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

  • Source

13.3. 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

  • Source

13.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

  • Source

14. Provenance Materials

This package provides rules for verifying the contents of the materials section of the SLSA Provenance attestation.

  • Package name: provenance_materials

  • Package full path: policy.release.provenance_materials

14.1. 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

  • Source

14.2. 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

  • Source

15. Red Hat manifests

Red Hat images are expected to include certain manifest files. This package verifies this requirement is met.

  • Package name: redhat_manifests

  • Package full path: policy.release.redhat_manifests

15.1. Missing Red Hat manifests

Verify the expected Red Hat manifests are available in the image.

  • Rule type: FAILURE

  • Failure message: Missing Red Hat manifest %q

  • Code: redhat_manifests.redhat_manifests_missing

  • Source

16. 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

  • Package full path: policy.release.slsa_build_build_service

16.1. 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

  • Source

16.2. 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

  • Source

16.3. 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

  • Source

17. 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

  • Package full path: policy.release.slsa_build_scripted_build

17.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

  • Source

17.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

  • Source

17.3. 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

  • Source

17.4. 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

  • Source

18. 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

  • Package full path: policy.release.slsa_provenance_available

18.1. 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

  • Source

18.2. 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

  • Source

19. 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

  • Package full path: policy.release.slsa_source_version_controlled

19.1. 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

  • Source

19.2. Material uri is a git repo

Ensure each entry in the predicate.materials array of the attestation uses a git URI.

Solution: Make sure the format of the URI in the materials section of the attestation is a valid URI. This information comes from the 'CHAINS-GIT_URL' result 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

  • Source

19.3. Materials include git commit shas

Ensure each entry in the predicate.materials array of the attestation includes a SHA1 digest which corresponds to a git commit.

Solution: Make sure the format of the digest.sha1 in the materials section of the attestation is a valid commit sha. This information comes from the 'CHAINS-GIT_COMMIT' result 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

  • Source

20. 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

  • Package full path: policy.release.slsa_source_correlated

20.1. Source code reference provided

Warn if the expected source code reference is not provided.

Solution: Provide the expected source code reference in inputs.

  • Rule type: WARNING

  • Warning message: Expected source code reference was not provided for verification

  • Code: slsa_source_correlated.source_code_reference_provided

  • Source

20.2. 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

  • Source

20.3. 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

  • Source

20.4. 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

  • Source

21. Sbom cyclonedx

Checks different properties of the CycloneDX SBOMs associated with the image being validated. The SBOMs are read from multiple locations: a file within the image, and a CycloneDX SBOM attestation.

  • Package name: sbom_cyclonedx

  • Package full path: policy.release.sbom_cyclonedx

21.1. Found

Confirm a CycloneDX SBOM exists.

Solution: Make sure the build process produces a CycloneDX SBOM.

  • Rule type: FAILURE

  • Failure message: No CycloneDX SBOM found

  • Code: sbom_cyclonedx.found

  • Source

21.2. 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

  • Source

21.3. Contains components

Check the list of components in the CycloneDX SBOM is not empty.

Solution: Verify the SBOM is correctly identifying the components in the image.

  • Rule type: FAILURE

  • Failure message: The list of components is empty

  • Code: sbom_cyclonedx.contains_components

  • Source

21.4. 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

  • Source

21.5. Disallowed packages list is provided

Confirm the disallowed_packages rule data was provided, since it is required by the policy rules in this package.

Solution: Provide a list of disallowed packages in the expected format.

  • Rule type: FAILURE

  • Failure message: %s

  • Code: sbom_cyclonedx.disallowed_packages_provided

  • Source

22. Sbom spdx

Checks different properties of the SPDX SBOM attestation.

  • Package name: sbom_spdx

  • Package full path: policy.release.sbom_spdx

22.1. Found

Confirm an SPDX SBOM attestation exists.

Solution: Make sure the build process produces an SPDX SBOM attestation.

  • Rule type: FAILURE

  • Failure message: No SPDX SBOM attestations found

  • Code: sbom_spdx.found

  • Source

22.2. Valid

Check the SPDX SBOM has the expected format.

Solution: Make sure the build process produces a valid SPDX SBOM.

  • Rule type: FAILURE

  • Failure message: SPDX SBOM at index %d is not valid

  • Code: sbom_spdx.valid

  • Source

22.3. 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

  • Source

22.4. 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

  • Source

22.5. 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

  • Source

23. Schedule related checks

Rules that verify the current date conform to a given schedule.

  • Package name: schedule

  • Package full path: policy.release.schedule

23.1. 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.

Solution: Try again on a different weekday.

  • Rule type: FAILURE

  • Failure message: %s is a disallowed weekday: %s

  • Code: schedule.weekday_restriction

  • Source

23.2. 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.

Solution: Try again on a different day.

  • Rule type: FAILURE

  • Failure message: %s is a disallowed date: %s

  • Code: schedule.date_restriction

  • Source

23.3. 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

  • Source

24. 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

  • Package full path: policy.release.attestation_task_bundle

24.1. 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

  • Source

24.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

  • Source

24.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

  • Source

24.4. 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'

  • Code: attestation_task_bundle.task_ref_bundles_current

  • Source

24.5. 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_acceptable

  • Source

24.6. An acceptable 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.acceptable_bundles_provided

  • Source

25. 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 are listed by the names given to them within the Tekton Bundle image. 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

  • Package full path: policy.release.tasks

25.1. 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

  • Source

25.2. 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

  • Source

25.3. 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

  • Source

25.4. 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_task_unacceptable_found

  • Source

25.5. 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

  • Source

25.6. 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

  • Source

25.7. 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

  • Source

25.8. 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

  • Source

25.9. 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.

Solution: Upgrade to a newer version of the Task.

  • Rule type: FAILURE

  • Failure message: Task %q is used by pipeline task %q is or will be unsupported as of %s.

  • Code: tasks.unsupported

  • Source

26. 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

  • Package full path: policy.release.test

26.1. 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

  • Source

26.2. 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

  • Source

26.3. 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: Test '%s' has unsupported result '%s'

  • Code: test.test_results_known

  • Source

26.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.

  • Rule type: FAILURE

  • Failure message: Test %q failed

  • Code: test.no_failed_tests

  • Source

26.5. 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.

  • Rule type: WARNING

  • Warning message: Informative test %q failed

  • Code: test.no_failed_informative_tests

  • Source

26.6. 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.

  • Rule type: FAILURE

  • Failure message: Test %q erred

  • Code: test.no_erred_tests

  • Source

26.7. 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'.

  • Rule type: FAILURE

  • Failure message: Test %q was skipped

  • Code: test.no_skipped_tests

  • Effective from: 2023-12-08T00:00:00Z

  • Source

26.8. 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'.

  • Rule type: WARNING

  • Warning message: Test %q returned a warning

  • Code: test.no_test_warnings

  • Source

26.9. 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

  • Source

27. 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 the pre-defined list of trusted Tasks. The list is customized via the trusted_tasks rule data key.

  • Package name: trusted_task

  • Package full path: policy.release.trusted_task

27.1. 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

  • Source

27.2. Current

Check if all Tekton Tasks use the latest known Task reference.

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

  • Code: trusted_task.current

  • Source

27.3. Trusted

Check if all Tekton Tasks use a trusted Task reference.

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 %q uses an untrusted task reference, %s

  • Code: trusted_task.trusted

  • Source

27.4. Data

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

  • Source

28. 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

  • Package full path: policy.release.rpm_ostree_task

28.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

  • Source

28.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

  • Source