Hardening and Security Tracker

[Ornias1993]

This issue tracks the steps we can take to increase security of our project.
It's mostly supplied as a way to inform users that we're aware improvements could be made and is not intended as a discussion platform (please use the dev channel on discord for that)

• Add signing of Helm Charts (lowers MITM/spoofing supply-chain attack-surface)
• Add signing of docker images (lowers MITM/spoofing supply-chain attack-surface)
• Ensure provenance generation for Helm Charts
• Add automatic SBOM generation to docker build process (using syft for example, ensures SLSA L1 compliance)
• Add provenance generation to docker build process (ensures SLSA L1 compliance))
• Validate helm dependency signatures in chart testing pipeline
• Move bot to user with less privileges (decreases the scope when the bot gets compromised)
• Move org-wide admin access to dedicated account (decreases the scope when maintainers get compromised)
• Validate container signatures in chart testing pipeline
• Validate container signatures prior to SCALE catalog release in CI
• Move helm deps train to immutable repo
• Validate helm dependency signatures prior in catalog repo staging
• Validate helm dependency signatures in helm-staging repo staging
• Add copyright header to all files (lower potential copyright issues)
• Move more complicated charts to use our BSL license (prevents other projects/iX rebranding)
• Publish common helm security scan results on website (ensures users are informed on security practices)
• Publish common container security scan results on website (ensures users are informed on security practices)
• Write guides to help users setup signed commits (enables us to enforced signed commits in the future)
• Move to enforcing signed commits (decreases the chance of contributor spoofing injecting bad-actor code)
• host our own github actions instead of relying on upstreams (lowers potential supply-chain attack surface)
• Add mandatory basic security scanning prior to publication (to prevent bad code making it to releases)
• Move away from manifest manager where we can (directly loading code from the internet is a security risk)
• Move signing/release pipelines to private repositories (prevents chances of key leakage)
• Add virus scanning to container build pipeline where possible
• Add automatic SBOM generation to Helm charts themselves (ensures SLSA L1 compliance))
• Remove dependency on bitnami helm charts as they are unsigned (so we can enforce signature on deps)
• Move Helm Registry to OCI registry, under main "truecharts" account
• Remove docker containers from main quay account "truecharts"
• Move Container Base images to different OCI account (tccrbase)
• Move Container mirror to different OCI account (tccrmirror)
• Move Container non-mirror (self-build) to different OCI account (tccr)

For provenance and SBOM for docker images see:
https://marcofranssen.nl/secure-your-software-supply-chain-using-sigstore-and-github-actions

Proposed flow:

• PR commits (signed)
• Tests verify signature of both dependencies and containers
• 1 (preferably 2) reviews for non-automatic PR's from users with Write but not Admin access and 2FA enabled

After merge:

• Validate on fetching deps again for catalog repo
• Don't validate before sending to helm-staging (as it gets (re)build there anyway)

On catalog-repo (not accepting PR's, locked down repo):

• Validate again in staging branch
• publish from main branch

On helm-staging (not accepting PR's, locked down repo):

• Validate again in a staging branch
• Sign from main branch before publish
• publish deps seperately

Bottom line: Signatures get checked during PR testing AND right before the build is finalised