Security in CICD for Platforms

Welcome. This lesson covers security in CI/CD for platform engineering: common internal and external vulnerabilities, practical controls, and how to balance protection with developer velocity. We focus on supply-chain integrity, runtime conformance, and operational controls you can adopt on any CI/CD platform (GitHub Actions, GitLab CI, Jenkins, Tekton, etc.). Attack surface is every path an adversary could use to compromise your systems — from malicious dependencies and compromised tools to exposed developer environments and infrastructure misconfigurations. Understanding the attack surface helps you prioritize defensive controls and continuously detect anomalous activity.

The image outlines different aspects of the attack surface, including malicious dependencies, compromised tools, developer environments, and infrastructure vulnerabilities. Each aspect provides examples like npm packages, build tools, stolen credentials, and registry poisoning.

Threat vectors commonly include registry poisoning, man-in-the-middle attacks, social engineering, and compromised developer machines. With a mapped attack surface you can implement three complementary classes of controls:

Preventive guardrails (policies, least privilege).
Continuous visibility and detection (scanning, observability).
Conformance and enforcement (attestations, admission policies).

A practical maturity model for securing your software supply chain is SLSA.

SLSA (Supply-chain Levels for Software Artifacts) is a vendor-neutral maturity and attestation model for software supply chain security. It focuses on provenance, build integrity, and progressive cryptographic guarantees that apply across CI/CD platforms. Learn more at the SLSA project: https://slsa.dev.

The image illustrates the SLSA supply-chain levels for software artifacts, highlighting features like industry standard, maturity model, attestation-based security, and vendor neutrality.

SLSA levels (summary)

Level	Main guarantee	Practical focus
0	No guarantees	Traditional CI/CD with no provenance or signing
1	Provenance	Produce metadata linking artifacts to source and build recipe
2	Trusted build	Verified, controlled build environments (no laptop builds)
3	Protected source	Branch protections, reviews, signed commits
4	Hermetic builds	Fully isolated, reproducible builds producing identical artifacts

The image displays a diagram of SLSA security levels with progressive requirements from Level 0 (no guarantees) to Level 4 (hermetic builds with maximum isolation and reproducibility). Each level describes a different aspect of software build security and integrity.

Implementing SLSA on a platform — four practical steps

Start simple: implement Level 1 by generating build metadata and provenance that link artifacts to source (initially not cryptographically signed).
Progressive enhancement: lock down build environments and provide isolation for runners (move toward Level 2).
Tool integration: adopt signing/attestation tooling such as Sigstore/Cosign, Tekton Chains, and provenance stores.
Policy enforcement: validate attestations at runtime and enforce SLSA-related policies through admission controllers or deployment gates.

The image outlines the "Platform SLSA Implementation Approach," highlighting four steps: Start Simple, Progressive Enhancement, Tool Integration, and Policy Enforcement, with specific actions for each step.

Practical tooling and capabilities

Container and artifact scanning

Vulnerability scanning: detect known CVEs in images and packages.
Configuration analysis: spot insecure container or OS settings.
Malware detection: flag suspicious binaries or behaviors.
License compliance: identify problematic open-source licenses.

The image outlines four components of container security scanning in CI/CD: Vulnerability Scanning, Configuration Analysis, Malware Detection, and License Compliance, each with a brief description.

Trivy is a popular open-source scanner that covers vulnerabilities, misconfigurations, and IaC checks. Example GitHub Actions step to run Trivy on a built image and fail the pipeline when high/critical findings are detected:

# GitHub Actions: Trivy security scanning
- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'registry.spr.com/pony-spawner:${{ github.sha }}'
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'
    exit-code: '1' # Fail build on critical/high vulnerabilities

Supply chain transparency with SBOMs

Generate a Software Bill of Materials (SBOM) to list components for traceability and license checks.
Syft (Anchore / CNCF) produces SBOMs in SPDX and CycloneDX formats.

The image describes three CNCF tools for generating SBOMs: Syft, CycloneDX, and SPDX, each with their respective standards and functions.

Cryptographic signing and attestations

Sigstore provides signing and transparency without owning a full PKI.
Cosign (part of Sigstore tooling) signs container images and can verify signatures before deployment.
Tekton Chains automates provenance attestation for Tekton Pipelines and integrates with Sigstore.

Example: sign and verify with Cosign

# Sign an image (local private key)
cosign sign --key cosign.key registry.spr.com/pony-spawner:v2.1.0

# Verify signature before deployment (local public key)
cosign verify --key cosign.pub registry.spr.com/pony-spawner:v2.1.0

Enforce signed images at admission with Kyverno (verifyImages using an inline public key):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: enforce
  background: false
  rules:
    - name: verify-signature
      match:
        resources:
          kinds: [Pod]
      verifyImages:
        - imageReferences:
            - "registry.spr.com/*"
          key: |
            -----BEGIN PUBLIC KEY-----
            MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
            -----END PUBLIC KEY-----

This policy blocks pod creation if the image signature cannot be verified with the configured key.

The image is an infographic titled "Automated Attestation With Tekton Chains" highlighting features like automatic attestation, multiple formats, cryptographic signing, and Kubernetes native integration. It emphasizes integration with Tekton Pipelines and support for SLSA provenance.

The image is an infographic about "Automated Attestation With Tekton Chains," highlighting features like automatic attestation, support for multiple formats, cryptographic signing, and Kubernetes native integration.

Policy gates in the CI/CD lifecycle

Pre-commit: prevent secrets and obvious policy violations before code lands.
CI pipeline: run security scans, dependency checks, SBOM generation, and policy validation.
Registry/artifact scanning: re-scan images and artifacts after push.
Admission control: enforce policies at deploy time (image signing, vulnerability thresholds, resource limits).

The image illustrates the stages of Security Policy Gates in a CI/CD pipeline: Pre-Commit, CI Pipeline, Registry, and Admission Control.

Secrets handling — critical best practices

Never commit secrets to Git or bake them into container images. Use external secret stores (Vault, ExternalSecrets, or cloud provider secret managers) and inject secrets at runtime. Rotate secrets automatically and maintain an audit trail.

Anti-patterns to avoid (examples shown in the diagram):

Embedding API keys in code or Dockerfiles.
Using environment variables in Dockerfiles that bake secrets into images.
Storing plaintext DB passwords in manifests.

The image lists common anti-patterns in securing secrets for Platform CI/CD, including using environment variables in Dockerfiles, hardcoding API keys in application configurations, and storing database passwords in Kubernetes manifests.

Secret detection tooling (examples)

Pre-commit scanners and GitHub secret scanning.
TruffleHog, GitLeaks, and KICS to detect secrets in commits and repos.

Example GitHub Actions step for TruffleHog:

# GitHub Actions: Secret scanning
- name: Run TruffleHog secret scan
  uses: trufflesecurity/trufflehog@main
  with:
    path: ./
    base: main
    head: HEAD
    extra_args: --debug --only-verified

Infrastructure-as-Code (IaC) security

Treat IaC as code: run static checks, policy validations, and compliance scans before deployment.
Tools: Checkov, tfsec, KICS, and Terrascan detect misconfigurations and policy violations.

The image is a pyramid diagram titled "Securing Infrastructure Code in Platform Pipelines," highlighting four levels: Compliance, Cost Implications, Policy Violations, and Misconfiguration, each with corresponding descriptions and icons.

Two widely used open-source IaC security options:

The image presents two open-source IaC security tools: Checkov, for multi-platform static analysis, and tfsec, a Terraform-specific security scanner with custom rules.

Example Terraform snippet (useful for testing scanners):

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "MyWebServer"
  }
}

Application security testing

SAST: static analysis for code issues and insecure patterns.
DAST/RST: dynamic or runtime testing of running services (e.g., OWASP ZAP, Nuclei).
Integrate SAST and DAST into CI and staging environments to catch issues prior to production.

The image outlines four components of runtime security testing in platform deployments: OWASP ZAP, Nuclei, Custom Tests, and Staging Integration, each with brief descriptions.

Platform multi-tenancy and workload isolation

Enforce namespace boundaries and Role-Based Access Control (RBAC).
Apply resource quotas to avoid noisy-neighbor or resource exhaustion issues.
Use NetworkPolicies for deny-by-default, zero-trust networking between tenants.
Enforce Pod Security Standards to prevent insecure runtime contexts.

CI/CD runner and build environment hardening

Use ephemeral, isolated runners for builds (dedicated namespaces and networks).
Enforce least privilege for runner identities and tokens.
Scan artifacts immediately after build and scan running containers post-deployment.
Level 2 SLSA depends on attesting to and protecting the build environment.

The image outlines four key components for securing CI/CD pipeline infrastructure: Isolated Runners, Least Privilege, Network Isolation, and Image Scanning.

Runner security best practices

The image is a slide titled "Securing CI/CD Pipeline Infrastructure" featuring key points on "Self-Hosted Runner Security," including Kubernetes-based runners, network policies, and automatic runner cleanup and rotation.

Dependency management and update discipline

Modern applications include many third-party libraries; dependency confusion and malicious packages are real threats.
Maintain inventories, track versions, and perform risk-based updates.
Use caching, parallel scanning, and deduplication to reduce scanning overhead while preserving developer velocity.

The image illustrates "Platform CI/CD – Managing Dependencies" with four key aspects: Vulnerability Scanning, License Compliance, Update Management, and Dependency Confusion surrounding Dependency Security Challenges.

Balancing security with development velocity

Use progressive scanning based on risk (full scans for changed or new components; cached results for unchanged signed artifacts).
Consolidate toolchains where it makes sense to reduce tool sprawl.
Auto-scale scanning infrastructure so security checks do not become a pipeline bottleneck.

Operational strategies that work

Scan deduplication: skip rescans for verified, signed artifacts.
Tool consolidation: select a small set of integrated scanners and attestation tools.
Resource scaling: ensure scanners and pipelines scale with demand to maintain throughput.

The image illustrates three strategies for balancing security with development velocity: scan deduplication, tool consolidation, and resource scaling, each with a brief explanation.

Runtime networking and service mesh security

Service meshes (Istio, Linkerd) provide automatic mTLS, identity-based policies, traffic monitoring, and enforcement controls — useful primitives for runtime segmentation and observability.

The image illustrates four aspects of service mesh security in a CI/CD platform: Automatic mTLS, Identity-Based Policies, Traffic Monitoring, and Policy Enforcement, each represented with unique icons.

Observability and incident response

Maintain audit logs, security metrics, and automated alerting.
Integrate detection and response into platform tooling so incidents can be triaged and traced end-to-end.

Compliance and evidence collection

Keep Policy-as-Code, audit trails, and retained evidence to satisfy SOC2, GDPR, and other regulations.
Use encryption in transit and at rest, secure logs, and preserve signed artifacts and SBOMs as compliance evidence.

The image presents a diagram outlining "Platform Compliance" components for SOC2, GDPR, and regulatory requirements, including Policy as Code, Audit Trails, Evidence Collection, and Data Protection.

End-to-end platform security Protect the full lifecycle: source code, build process, artifact storage, deployment, and runtime. SLSA gives a progressive model to harden and attest these stages and enable verification at deploy time.

The image illustrates "Platform Engineering – End-to-End Security" with five components: Source Code, Build Process, Artifact Storage, Deployment, and Runtime, each represented by a colored icon and label.

Key takeaways

Adopt SLSA progressively: start with provenance (Level 1), harden build environments (Level 2), protect source and signing (Level 3), and aim for hermetic builds (Level 4) where feasible.
Use multi-layer scanning: vulnerabilities, secrets, IaC, SAST/DAST, and runtime checks.
Generate SBOMs and integrate cryptographic signing (Sigstore/Cosign, Tekton Chains) so artifacts can be verified at deploy time.
Secure runners, isolate build networks, apply least privilege, and inject secrets at runtime from external secret stores.
Balance security with developer velocity using caching, deduplication, and scalable scanning infrastructure.

Supply chain protection and cryptographic verification transform security from a compliance burden into a competitive advantage. Apply layered controls across CI/CD to protect the full lifecycle from source to runtime. Links and references

SLSA: https://slsa.dev
Trivy: https://github.com/aquasecurity/trivy
Syft (SBOM): https://github.com/anchore/syft
Sigstore / Cosign: https://sigstore.dev
Tekton Chains: https://tekton.dev/docs/chains
Kyverno: https://kyverno.io
Kubernetes concepts: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

Pre-requisites

Domain 1 - Platform Engineering Core Fundamentals

Domain 2 - Platform Observability, Security, and Conformance

Domain 3 - Continuous Delivery & Platform Engineering

Domain 4 - Platform APIs and Provisioning Infrastructure

Domain 5 - Internal Developer Platforms & Developer Experience

Domain 6 - Measuring Your Platform

Mock Exams & Final Prep

Security in CICD for Platforms

Watch Video