Release Policy
These rules are applied to pipeline run attestations associated with container images built by Konflux.
1. Available rule collections
2. Available Packages
Package Name |
Description |
Sanity checks related to the format of the image build’s attestation. |
|
This package is responsible for verifying the base (parent) images reported in the SLSA Provenace or the SBOM are allowed. |
|
This package is responsible for verifying the buildah build task |
|
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
|
|
Verify the attribute .predicate.buildDefinition.externalParameters of a SLSA Provenance v1.0 matches the expectation. |
|
Check that the build was done from an expected git branch. The specific branches permitted are specified as a list of regexes in the |
|
Verify attributes on the certificate involved in the image signature when using slsa-github-generator on GitHub Actions with Sigstore Fulcio |
|
This package verifies the build task in the attestation was invoked with the expected parameters to perform a hermetic build. |
|
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. |
|
Checks for Operator Lifecycle Manager (OLM) bundles. |
|
This package provides rules for verifying the contents of the materials section of the SLSA Provenance attestation. |
|
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. |
|
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 |
|
Rules used to verify different properties of specific RPM packages found in the SBOM of the image being validated. |
|
This package provides rules for verifying the RPMs are built in an approved pipeline |
|
This package defines rules to confirm that all RPM packages listed in SBOMs specify a known and permitted repository id. |
|
This package provides rules for verifying the signatures of RPMs identified in the the SLSA Provenance attestation. |
|
Checks general properties of the SBOMs associated with the image being validated. More specific rules for SPDX and CycloneDX SBOMs are in separate packages. |
|
Checks different properties of the CycloneDX SBOMs associated with the image being validated. |
|
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. |
|
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. |
|
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. |
|
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 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. |
|
Checks different properties of the CycloneDX SBOMs associated with the image being validated. |
|
Rules that verify the current date conform to a given schedule. |
|
This package is reponsible for verifying the source container image associated with the image being validated. |
|
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. |
|
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. |
|
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. |
|
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 |
|
This package is responsible for verifying the rpm-ostree Tekton Task was executed with the expected parameters. |