Project: Capsule (Orchestration & Management / Scheduling & Orchestration)
File: SECURITY.md

The Capsule community has adopted this security disclosures and response policy to ensure we responsibly handle critical issues. For information regarding the security of this project please join our . When we say "a security vulnerability in capsule" we mean a security issue in any repository under the . This reporting process is intended only for security issues in the capsule project itself, and doesn't apply to applications using capsule or to issues which do not affect security. Don't use this process if: You have issues with your capsule installation or configuration Your issue is not security related We do not accept reports which amount to copy and pasted output from a vulnerability scanning tool unless work has specifically been done to confirm that a vulnerability reported by the tool actually exists in capsule. To report a security issue or vulnerability, to the repository maintainers with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Describe the issue in English, ideally with some example configuration or code which allows the issue to be reproduced. Explain why you believe this to be a security issue in capsule, if that's not obvious. should contain the following: description of the problem precise and detailed steps (include screenshots) the affected version(s). This may also include environment relevant versions. any possible mitigations If the issue is confirmed as a vulnerability, we will open a Security Advisory and acknowledge your contributions as part of it. Response times could be affected by weekends, holidays, breaks or time zone differences. That said, the security response team will endeavour to reply as soon as possible, ideally within 5 working days. of this project are responsible for the security of the project as outlined in this

To verify artifacts you need to have . This guide assumes you are using v2.x of cosign. All of the signatures are created using . We have a seperate repository for all the signatures for all the artifacts released under the projectcapsule - `ghcr.io/projectcapsule/signatures`. You can set the environment variable `COSIGN_REPOSITORY` to point to this repository. For example: export COSIGN_REPOSITORY=ghcr.io/projectcapsule/signatures To verify the signature of the docker image, run the following command. Replace `<release_tag>` with an : COSIGNREPOSITORY=ghcr.io/projectcapsule/signatures cosign verify ghcr.io/projectcapsule/capsule:<releasetag> \ --certificate-identity-regexp="https://github.com/projectcapsule/capsule/.github/workflows/docker-publish.yml@refs/tags/*" \ --certificate-oidc-issuer="https://token.actions.githubusercontent.com" | jq To verify the signature of the helm image, run the following command. Replace `<release_tag>` with an : COSIGNREPOSITORY=ghcr.io/projectcapsule/signatures cosign verify ghcr.io/projectcapsule/charts/capsule:<releasetag> \ --certificate-identity-regexp="https://github.com/projectcapsule/capsule/.github/workflows/helm-publish.yml@refs/tags/*" \ --certificate-oidc-issuer="https://token.actions.githubusercontent.com" | jq Capsule creates and attests to the provenance of its builds using the and meets the specification. The attested provenance may be verified using the cosign tool. Verify the provenance of the docker image. Replace `<release_tag>` with an ```bash cosign verify-attestation --type slsaprovenance \ --certificate-identity-regexp="https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generatorcontainerslsa3.yml@refs/tags/*" \ --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \ ghcr.io/projectcapsule/capsule:<release_tag> | jq .payload -r | base64 --decode | jq ``` Verify the provenance of the helm image. Replace `<release_tag>` with an ```bash cosign verify-attestation --type slsaprovenance \ --certificate-identity-regexp="https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generatorcontainerslsa3.yml@refs/tags/*" \ --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \ ghcr.io/projectcapsule/charts/capsule:<release_tag> | jq .payload -r | base64 --decode | jq ``` An SBOM (Software Bill of Materials) in CycloneDX JSON format is published for each Kyverno release, including pre-releases. Like signatures, SBOMs are stored in a separate repository at `ghcr.io/projectcapsule/sbom`. You can set the environment variable `COSIGN_REPOSITORY` to point to this repository. For example: export COSIGN_REPOSITORY=ghcr.io/projectcapsule/sbom To inspect the SBOM of the docker image, run the following command. Replace `<release_tag>` with an : COSIGNREPOSITORY=ghcr.io/projectcapsule/sbom cosign download sbom ghcr.io/projectcapsule/capsule:<releasetag> To inspect the SBOM of the helm image, run the following command. Replace `<release_tag>` with an : COSIGNREPOSITORY=ghcr.io/projectcapsule/sbom cosign download sbom ghcr.io/projectcapsule/charts/capsule:<releasetag> Our Security Policy and Workflows are based on the work of the and community.