KCSA — Image Assurance & Pipeline Security
Secure CI/CD Pipeline Overview
A secure software supply chain ensures that every artifact deployed to your Kubernetes cluster has been built, scanned, signed, and verified. Security must be embedded at every stage of the pipeline — not bolted on at the end.
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Source │───▶│ Build │───▶│ Test │───▶│ Scan │───▶│ Sign │───▶│ Deploy │
│ │ │ │ │ │ │ │ │ │ │ │
│ • Code │ │ • Docker│ │ • Unit │ │ • CVE │ │ • Cosign│ │ • K8s │
│ • Deps │ │ • Build │ │ • SAST │ │ • SBOM │ │ • Notary│ │ • GitOps│
│ • Config│ │ • OCI │ │ • DAST │ │ • Config│ │ • Sigstr│ │ • Verify│
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
▲ ▲ ▲ ▲ ▲ ▲
Gate 1 Gate 2 Gate 3 Gate 4 Gate 5 Gate 6
Code review Secure build Tests pass No critical Signed Signature
Signed commit Reproducible Coverage met CVEs artifact verified
Each gate is a security checkpoint — if a condition is not met, the pipeline stops.
Security Gates at Each Pipeline Stage
| Stage | Security Gate | Tools / Mechanism |
|---|---|---|
| Source | Signed commits, branch protection, code review required | Git GPG signing, GitHub/GitLab protected branches |
| Build | Reproducible builds, pinned base images, no latest tags |
Multi-stage Dockerfiles, digest-pinned base images |
| Test | SAST (static analysis), unit tests, dependency audit | Semgrep, SonarQube, npm audit, pip-audit |
| Scan | Vulnerability scanning, SBOM generation, config lint | Trivy, Grype, Snyk, Syft (SBOM), Checkov (IaC) |
| Sign | Cryptographic image signing, attestation | cosign, Notary v2, Sigstore |
| Deploy | Signature verification at admission, policy enforcement | Kyverno verifyImages, Connaisseur, Binary Authorization |
A vulnerability found at the Scan stage is 100x cheaper to fix than one discovered in production. Shift security left.
Image Scanning in CI/CD
Image scanning identifies known vulnerabilities (CVEs) in container image layers, OS packages, and application dependencies.
Popular Image Scanning Tools
| Tool | Type | Key Features |
|---|---|---|
| Trivy | Open-source (Aqua Security) | Scans images, filesystems, IaC, Kubernetes manifests; supports SBOM output |
| Grype | Open-source (Anchore) | Fast vulnerability scanner; pairs with Syft for SBOM |
| Snyk Container | Commercial (free tier) | Developer-friendly; integrates with IDEs and CI/CD |
| Clair | Open-source (Quay) | Static analysis of container images; used by Quay registry |
Trivy in a CI/CD Pipeline
# Example: GitHub Actions workflow step
- name: Scan image for vulnerabilities
uses: aquasecurity/trivy-action@master
with:
image-ref: myregistry.io/myapp:$
format: table
exit-code: 1 # Fail the pipeline if vulnerabilities found
severity: CRITICAL,HIGH # Only fail on critical and high severity
What Image Scanners Check
| Layer | What Is Scanned | Example Findings |
|---|---|---|
| OS packages | apt, yum, apk packages in the image | OpenSSL CVE, glibc vulnerability |
| Language dependencies | npm, pip, go.mod, Maven packages | Log4Shell in Java deps, prototype pollution in npm |
| Image configuration | Dockerfile best practices | Running as root, unnecessary capabilities |
| Secrets | Hardcoded credentials in image layers | AWS keys, API tokens embedded in layers |
Always scan the final built image — not just the Dockerfile. Build-time and runtime dependencies may differ.
Image Signing and Verification
Image scanning tells you if an image has known vulnerabilities. Image signing tells you if an image is authentic and untampered. Both are needed for a secure supply chain.
The Image Signing Workflow
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Build Image │────▶│ Sign Image │────▶│ Push to │────▶│ Verify at │
│ │ │ (cosign) │ │ Registry │ │ Admission │
│ myapp:v1.0 │ │ │ │ │ │ │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
│ │
Uses signing key Checks signature
(KMS, file, OIDC) (webhook / policy)
cosign — The Standard Tool for Image Signing
cosign (part of the Sigstore project) is the most widely used tool for signing and verifying container images.
# Generate a key pair
cosign generate-key-pair
# Sign an image
cosign sign --key cosign.key myregistry.io/myapp:v1.0
# Verify an image
cosign verify --key cosign.pub myregistry.io/myapp:v1.0
Keyless Signing with Sigstore
cosign also supports keyless signing using OIDC identity providers (GitHub Actions, Google, Microsoft):
# Keyless signing — uses OIDC identity (no key management needed)
cosign sign myregistry.io/myapp:v1.0
# Signer authenticates via browser or CI OIDC token
# Signature and certificate are stored in Rekor transparency log
Keyless signing eliminates key management overhead while providing verifiable identity through certificate transparency logs.
Verifying Signatures at Admission
Signing images is only useful if you enforce verification before deployment. This is done at the admission control layer.
Kyverno — Verify Image Signatures:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: verify-image-signature
spec:
validationFailureAction: Enforce
rules:
- name: verify-cosign-signature
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "myregistry.io/*"
attestors:
- entries:
- keys:
publicKeys: |-
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
-----END PUBLIC KEY-----
This policy rejects any pod whose image from myregistry.io is not signed with the specified public key.
Binary Authorization and Image Integrity
Major cloud providers offer managed image verification services:
| Service | Cloud Provider | Description |
|---|---|---|
| Binary Authorization | Google Cloud (GKE) | Enforces deploy-time security policies requiring images to be signed by trusted authorities |
| Image Integrity | Azure (AKS) | Verifies image signatures using Notary v2 before allowing deployment |
| Signer | AWS (EKS) | AWS Signer can sign container images; verified via admission controllers |
These services integrate directly with the cloud provider’s Kubernetes offering and can be enforced at the cluster level without installing third-party tools.
SLSA Framework
SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) is a security framework that defines increasing levels of supply chain integrity.
SLSA Levels
| Level | Requirements | What It Prevents |
|---|---|---|
| SLSA 0 | No guarantees | Nothing — no supply chain security |
| SLSA 1 | Build process is documented and automated | Ad-hoc builds, no provenance |
| SLSA 2 | Version-controlled source, authenticated build service, provenance generated | Tampering after source control |
| SLSA 3 | Hardened build platform, non-falsifiable provenance, source verified | Compromised build process |
SLSA Concepts
| Concept | Description |
|---|---|
| Provenance | Metadata describing how an artifact was built (source, builder, steps) |
| Attestation | A signed statement about an artifact (e.g., “this image was built from commit abc123”) |
| Build platform | The system that produces artifacts (GitHub Actions, Jenkins, Tekton) |
| Source integrity | Guarantee that the source code has not been tampered with |
For the KCSA exam, know what SLSA is and understand the progression from Level 0 to Level 3. You will not need to implement SLSA compliance.
GitOps Security
GitOps uses Git as the single source of truth for declarative infrastructure and workloads. Tools like Flux and ArgoCD continuously reconcile cluster state with the desired state in Git.
Security Benefits of GitOps
| Benefit | Description |
|---|---|
| Audit trail | Every change is a Git commit with author, timestamp, and diff |
| Code review | All changes go through pull requests before being applied |
| Signed commits | GPG-signed commits ensure authenticity of changes |
| No direct cluster access | Developers push to Git, not to the cluster — reduces blast radius |
| Drift detection | GitOps controllers detect and reconcile unauthorized manual changes |
GitOps Security Best Practices
| Practice | Description |
|---|---|
| Signed commits | Require GPG/SSH commit signatures on the GitOps repository |
| Branch protection | Require code reviews and status checks before merging |
| Image update automation | Use Flux/ArgoCD image automation to update manifests when new signed images are available |
| Sealed Secrets | Encrypt Secrets in Git using Sealed Secrets or SOPS — never store plaintext Secrets |
| RBAC for GitOps controller | Give the GitOps controller only the permissions it needs — not cluster-admin |
| Multi-repo separation | Separate application repos from infrastructure repos for blast radius reduction |
Pipeline Security Best Practices
| Practice | Why It Matters |
|---|---|
| No secrets in CI environment variables | Environment variables can be leaked in logs, core dumps, or error messages |
| Use OIDC for cloud authentication | Short-lived tokens instead of long-lived service account keys |
| Pin dependency versions | Avoid supply chain attacks via compromised latest versions |
| Use digest-pinned base images | FROM nginx@sha256:abc... instead of FROM nginx:latest |
| Isolate build environments | Each build runs in an ephemeral, clean environment |
| Minimal build context | Use .dockerignore to exclude secrets, test files, git history |
| Multi-stage builds | Keep build tools out of the final image |
| Scan before and after build | Scan dependencies before build, scan the final image after |
| Rotate signing keys | Use short-lived keys or keyless signing via Sigstore |
| SBOM for every release | Generate and publish a Software Bill of Materials for transparency |
Key Takeaways for the Exam
| Concept | What to Remember |
|---|---|
| Pipeline stages | Source → Build → Test → Scan → Sign → Deploy — security gate at each stage |
| Image scanning | Trivy, Grype, Snyk — scan for CVEs in OS packages, language deps, and configs |
| Image signing | cosign (Sigstore) — sign images, verify at admission; keyless signing uses OIDC |
| Admission verification | Kyverno verifyImages, Binary Authorization — reject unsigned images |
| SLSA | Supply chain integrity framework — Levels 0–3, provenance, attestations |
| GitOps | Flux/ArgoCD — Git as source of truth, signed commits, no direct cluster access |
| SBOM | Software Bill of Materials — list of all components in an artifact |
- The KCSA exam emphasizes the conceptual workflow — Source → Build → Scan → Sign → Verify → Deploy
- Know what cosign does and how keyless signing works (OIDC + transparency log)
- Understand why image signing and scanning are complementary (scanning = vulnerability check, signing = authenticity check)
- SLSA levels describe increasing maturity of supply chain security — Level 3 is the highest
