# Repo sync notes Ensure SLSA level 1 (later 2 and 3) ![CNCF Secure Software Factory Whitepaper.pdf](https://hackmd.io/_uploads/S1CHCpckT.png) [CNCF Secure Software Factory Whitepaper.pdf](https://github.com/cncf/tag-security/blob/main/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf) ### Features - Minimum viable product - Unit test (yay!) - Coverage test (yay!!) - Coding style guide (yay!!!) - Generate inventory of tags in repository - Sync based on inventory - Modify manifests - Filter platforms - Add annotation ([image-spec](https://github.com/opencontainers/image-spec/blob/v1.1.0-rc5/annotations.md), [Artifact Hub](https://artifacthub.io/docs/topics/repositories/container-images/)) - Modify blobs - Patch helm charts - Patch containers - Rebuild - Sign manifests - Attach signed attestation (**in-toto**) - Inform about changes to manifest - Inform about original signature - Inform about original SBOM - Inform about our generated SBOM - Inform about where the content originated from - Attach signed SBOM - Export metadata to central server - Patch image - Build images from source - Archive blobs, manifests and other artifacts to object storage - Pull request to repository.yaml when new versions is released - Pull from private registry - Handeling credentials when resolving versions - Handeling credentials when building/pulling new releases ## Goal 1, SLSA lv. 1 The build process must be fully scripted/automated and generate provenance. | # | # | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Version controlled | Every change to the source is tracked in a version control system that meets the following requirements | | Scripted build | All build steps were fully defined in some sort of “build script”. The only manual command, if any, was to invoke the build script. | | Available | 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. | | Identifies artifact | The provenance MUST identify the output artifact via at least one cryptographic hash. | | Identifies builder | The provenance identifies the entity that performed the build and generated the provenance. This represents the entity that the consumer must trust. | | Identifies build instructions | The provenance identifies the top-level instructions used to execute the build. The identified instructions SHOULD be at the highest level available to the build | ## Insight into repository structure ![](https://hackmd.io/_uploads/H1H9C0cla.png) Source: https://containers.gitbook.io/build-containers-the-hard-way/ ![](https://hackmd.io/_uploads/ByVqjhkMp.png) Source: https://oras.land/docs/concepts/artifact/#the-anatomy-of-an-oci-artifact ![](https://hackmd.io/_uploads/SJUD5TcxT.png) Source: https://cd.foundation/blog/community/2022/12/20/no-more-additional-network-requests-enter-oci-image-layout/ ```mermaid classDiagram class Tag { +placeholder } class Index { +manifests []descriptor } class Manifest { +schema string +artifactType string +config descriptor +annotations map +subject descriptor } class Blobs { +configBlob +layerBlobs +... } Tag --> Index Tag --> Manifest Index --> Manifest Manifest --> Blobs ``` ![](https://hackmd.io/_uploads/BJ5f3h1fp.png) Source: https://oras.land/blog/oras-artifacts-draft-specification-release/ # Simple and shared tags Support for managed shared tags to make the life of developers easier. This could be based on some custom code or by inspection what tags/sha is part of a given shared tag external and making the same available internal using our verified images > Some images have separated "Simple Tags" and "Shared Tags" sections under "Supported tags and respective Dockerfile links" (see the mongo image for an example). > > "Simple Tags" are instances of a "single" Linux or Windows image. It is often a manifest list that can include the same image built for other architectures; for example, mongo:4.0-xenial currently has images for amd64 and arm64v8. The Docker daemon is responsible for picking the appropriate image for the host architecture. > > "Shared Tags" are tags that always point to a manifest list which includes some combination of potentially multiple versions of Windows and Linux images across all their respective images' architectures -- in the mongo example, the 4.0 tag is a shared tag consisting of (at the time of this writing) all of 4.0-xenial, 4.0-windowsservercore-ltsc2016, 4.0-windowsservercore-1709, and 4.0-windowsservercore-1803 Source: https://github.com/docker-library/faq#whats-the-difference-between-shared-and-simple-tags ## Good stuff [threat-model.md @ github.com/external-secrets](https://github.com/external-secrets/external-secrets/blob/v0.9.4/docs/guides/threat-model.md) Distroless images SLSA level 2 https://security.googleblog.com/2021/09/distroless-builds-are-now-slsa-2.html Kubernetes SLSA Compliance Assessment https://docs.google.com/spreadsheets/d/1fNdJJZZdEJAJU0ZaCnYcIlZA3L-bwT7vY7ZesqW3WEs/edit#gid=0 Kubernetes reach SLSA level 1 https://www.chainguard.dev/unchained/kubernetes-meets-slsa Kubernetes SLSA level 3 plans https://github.com/kubernetes/enhancements/issues/3027 KubeEdge reach SLSA level 3 https://kubeedge.io/blog/reach-slsa-l3/ Factory for Repeatable Secure Creation of Artifacts (FRSCA) - https://buildsec.github.io/frsca/ - https://buildsec.github.io/frsca/docs/slsa/frsca-slsa/ [CNCF Secure Software Factory Whitepaper.pdf](https://github.com/cncf/tag-security/blob/main/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf) [CNCF Software Supply Chain Best Practices.pdf](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) Kata Containers with Cilium https://docs.cilium.io/en/latest/network/kubernetes/kata/ Kerckhoffs's principle https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle Backend for backup systems for build files perhaps https://github.com/dpc/rdedup Rust OCI registry https://github.com/mcronce/oci-registry Rust Docker Registry lib https://github.com/mcronce/dkregistry-rs P2P OCI mirror https://github.com/XenitAB/spegel OCI registry benchmark tool https://github.com/project-zot/zot/tree/v2.0.0-rc6/cmd/zb Flux verify Helm Charts stored in OCI-compliant https://fluxcd.io/blog/2022/11/verify-the-integrity-of-the-helm-charts-stored-as-oci-artifacts-before-reconciling-them-with-flux/ Flux verify Git commits https://fluxcd.io/flux/components/source/gitrepositories/#verification Tekton is putting in a lot of work for supply chain security - https://tekton.dev/docs/chains/ - https://tekton.dev/docs/chains/signed-provenance-tutorial/ - https://tekton.dev/docs/chains/slsa-provenance/ - https://github.com/tektoncd/pipeline/blob/main/docs/hermetic.md Supply chain security framework https://in-toto.io/ Databaseless strictly OCI complient registry https://zotregistry.io