Release Policy

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

1. Available rule collections

Name

Description

github

A set of policy rules to validate artifacts built on GitHub.

Rules included:

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

Include policy rules responsible for validating rule data.

Rules included:

redhat

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

Rules included:

redhat_rpms

Include the set of policy rules required for building Red Hat RPMs.

Rules included:

rhtap-multi-ci

A set of policy rules to validate artifacts built using RHTAP Multi-CI pipelines.

Rules included:

slsa3

Includes policy rules required to meet SLSA Level 3.

Rules included:

2. Available Packages

Package Name

Description

attestation_type

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

base_image_registries

This package is responsible for verifying the base (parent) images reported in the SLSA Provenace or the SBOM are allowed.

buildah_build_task

This package is responsible for verifying the buildah build task

cve

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.

Example rule data

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

external_parameters

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

git_branch

Check that the build was done from an expected git branch. The specific branches permitted are specified as a list of regexes in the allowed_branch_patterns rule data.

github_certificate

Verify attributes on the certificate involved in the image signature when using slsa-github-generator on GitHub Actions with Sigstore Fulcio

hermetic_build_task

This package verifies the build task in the attestation was invoked with the expected parameters to perform a hermetic build.

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.

olm

Checks for Operator Lifecycle Manager (OLM) bundles.

provenance_materials

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

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.

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

rpm_packages

Rules used to verify different properties of specific RPM packages found in the SBOM of the image being validated.

rpm_pipeline

This package provides rules for verifying the RPMs are built in an approved pipeline

rpm_repos

This package defines rules to confirm that all RPM packages listed in SBOMs specify a known and permitted repository id.

rpm_signature

This package provides rules for verifying the signatures of RPMs identified in the the SLSA Provenance attestation.

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.

sbom_cyclonedx

Checks different properties of the CycloneDX SBOMs associated with the image being validated.

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.

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.

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.

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.

slsa_source_correlated

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.

sbom_spdx

Checks different properties of the CycloneDX SBOMs associated with the image being validated.

schedule

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

source_image

This package is reponsible for verifying the source container image associated with the image being validated.

attestation_task_bundle

To be able to reproduce and audit builds accurately it’s important to know exactly what happened during the build. To do this Conforma 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.

tasks

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

test

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

trusted_task

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/conforma/policy/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.

rpm_ostree_task

This package is responsible for verifying the rpm-ostree Tekton Task was executed with the expected parameters.