Release Policy

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.

Confirm at least one PipelineRun attestation is present.

Solution: Make sure the attestation being verified was generated from a Tekton pipelineRun.

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.

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.

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.

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.

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

Solution: Make sure the buildah task has a parameter named '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.

Validates the cryptographic signature of the attestation.

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

Validates the syntax of the attestation.

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

Validates the cryptographic signature of the image.

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

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

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

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

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

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

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.

Verify the PipelineRun did not use any pre-existing PersistentVolumeClaim workspaces.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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

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

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.

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.

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.

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.

Warn if the expected source code reference is not provided.

Solution: Provide the expected source code reference in inputs.

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

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.

Confirm a CycloneDX SBOM exists.

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

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.

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

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

Confirm an SPDX SBOM attestation exists.

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

Check the SPDX SBOM has the expected format.

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

Check the list of packages in the SPDX SBOM is not empty.

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

Check the list of files in the SPDX SBOM is not empty.

Solution: Verify the SBOM is correctly identifying the files in the 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.

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.

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.

Confirm that each step in each TaskRun ran on a container image with a url that matches one of the prefixes in the provided list of allowed step image registry prefixes.

Solution: Make sure the container image used in each step of the build pipeline comes from an approved registry. The approved list is under 'allowed_step_image_registry_prefixes' in the data sources.

Confirm the allowed_step_image_registry_prefixes rule data was provided, since it’s required by the policy rules in this package.

Solution: Make sure the data sources contains a key 'allowed_step_image_registry_prefixes' that contains a list of approved registries that can be used to run tasks in the build pipeline.

Check for the existence of a task bundle. This rule will fail if the task is not called from a bundle.

Check that a valid task bundle reference is being used.

Solution: Specify a task bundle with a reference as the full 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.

For each Task in the SLSA Provenance attestation, check if the Tekton Bundle used is the most recent acceptable bundle.

Solution: A task bundle used is not the most recent. The most recent task bundles are defined as in acceptable bundles list.

For each Task in the SLSA Provenance attestation, check if the Tekton Bundle used is an acceptable bundle given the tracked effective_on date.

Solution: For each Task in the SLSA Provenance attestation, check if the Tekton Bundle used is an acceptable bundle.

Confirm the task-bundles rule data was provided, since it’s required by the policy rules in this package.

Solution: Create an acceptable bundles list. This is a list of task bundles with a top-level key of 'task-bundles'. More information can be found at acceptable bundles.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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