ISACA SV Chapter: Securing Software Supply Chains
0 likes439 views
Software supply chain attacks increased 650% in 2021. Learn why software supply chains are vulnerable, the types of attacks, and how to prevent them using OSS tools like Sigstore cosign and CNCF Kyverno!
![Image signing and verification
PEP*
OCI Registry Policy Administration Point [PAP]
Attestations
Provenance data
Vulnerability scan
SBOM
Image
CI/CD Pipeline
*PEP: Policy Enforcement Point
Kubernetes
Clusters
1. Admin sets up policies for clusters
2. Developers
trigger a build
3. Image and attestations
are pushed to the OCI
registry
4. Image data is verified
at admission controls
5. Image data is verified
via runtime scans](https://image.slidesharecdn.com/isacasvsecuringsoftwaresupplychainsfeb2022-220304235516/85/ISACA-SV-Chapter-Securing-Software-Supply-Chains-24-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to ISACA SV Chapter: Securing Software Supply Chains (20)
Ad
More from Jim Bugwadia (12)
Ad
Recently uploaded (20)
ISACA SV Chapter: Securing Software Supply Chains
- 1. Securing Software Supply Chains Jim Bugwadia March 3rd, 2022
- 2. 2 Topics • A modern software supply chain • Software supply chain attacks • Supply Chain Levels for Software Artifacts (SLSA) • Signing and verification with sigstore • Provenance and in-toto attestations • Policy checks with Kyverno • Summary and Q&A
- 3. 3 About me • Co-founder and CEO, Nirmata • Kyverno Maintainer • Co-chair, Kubernetes Policy WG • Lead, Kubernetes Multi-tenancy WG @JimBugwadia
- 4. Software has changed! • Monoliths in VMs • Release every 3-6 months • Manual installation • Containers in Kubernetes • Released several times a day • Continuous delivery across hundreds of installations
- 5. Modern applications are composed • Applications can use 100s of OSS and commercial packages • Each package has its own set of dependencies • Managed Services and SaaS are also widely used
- 6. Continuous delivery pipelines push to prod • CI/CD environments are highly automated and use declarative principles like IaC and GitOps • CI/CD environments often have access to production systems • CI/CD environments may not be as secure as production
- 7. Software Supply Chain Attacks Tripled in 2021 Three types of attacks: 1. Exploit vulnerabilities in dependencies 2. Compromised CI/CD systems and tools 3. Code/artifact integrity Source: Argon
- 8. Supply chain threats Source: https://slsa.dev/ 8 threats across three categories
- 9. What is SLSA? Source: https://slsa.dev/
- 11. SLSA Level 1 The build process must be fully scripted/automated and generate provenance. • Provenance is metadata about how an artifact was built, including the build process, top-level source, and dependencies. • Knowing the provenance allows software consumers to make risk- based security decisions. • Provenance at SLSA 1 does not protect against tampering, but it offers a basic level of code source identification and can aid in vulnerability management.
- 12. SLSA Level 2 Requires using version control and a hosted build service that generates authenticated provenance. • These additional requirements give the software consumer greater confidence in the origin of the software. • At this level, the provenance prevents tampering to the extent that the build service is trusted. • SLSA 2 also provides an easy upgrade path to SLSA 3. Source: https://slsa.dev/
- 13. SLSA Level 3 The source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance respectively. • We envision an accreditation process whereby auditors certify that platforms meet the requirements, which consumers can then rely on. • SLSA 3 provides much stronger protections against tampering than earlier levels by preventing specific classes of threats, such as cross- build contamination. Source: https://slsa.dev/
- 14. SLSA Level 4 Requires two-person review of all changes and a hermetic, reproducible build process. • Two-person review is an industry best practice for catching mistakes and deterring bad behavior. • Hermetic builds guarantee that the provenance’s list of dependencies is complete. Reproducible builds, though not strictly required, provide many auditability and reliability benefits. • Overall, SLSA 4 gives the consumer a high degree of confidence that the software has not been tampered with. Source: https://slsa.dev/
- 15. SLSA Requirements – Source Code Source: https://slsa.dev/
- 16. SLSA Requirements – Build System Source: https://slsa.dev/
- 17. SLSA Requirements – Provenance Source: https://slsa.dev/
- 18. SLSA Requirements – Common Source: https://slsa.dev/
- 19. Signing and Verification with sigstore sigstore is a Linux Foundation project that provides: • cosign: signing and verification • rekor: tamper proof transparency log • fulcio: OIDC based key automation
- 20. Provenance and in-toto attestations • Attestations are signed metadata for software artifacts • Produced by a build system • Consumed by policy engines • The in-toto attestation format provides a flexible standard • Attestations can be used to capture: • Provenance data • Vulnerability scan reports • SBOMs • Scorecards • Some attestations (scans) should be generated periodically
- 22. Kyverno • Kyverno is a Kubernetes native policy engine with integrations for sigstore and in-toto • Kyverno policies are used to verify signatures and attestations • Policies are applied at: • Admission controls • Runtime scans
- 23. What policies can verify Verify that the container image: 1. Is signed by the expected approvers 2. Was built using the expected service or machine (provenance) 3. Has a signed SBOM in the expected format 4. Has a signed vulnerability scan report that: • was updated in the last 24 hours • has no vulnerability > 8.0 • has no vulnerabilities other than the expected set 5. Has other required metadata such as code reviews, etc.
- 24. Image signing and verification PEP* OCI Registry Policy Administration Point [PAP] Attestations Provenance data Vulnerability scan SBOM Image CI/CD Pipeline *PEP: Policy Enforcement Point Kubernetes Clusters 1. Admin sets up policies for clusters 2. Developers trigger a build 3. Image and attestations are pushed to the OCI registry 4. Image data is verified at admission controls 5. Image data is verified via runtime scans
- 25. Sample pipeline with GitHub Actions
- 26. Kyverno policy example 1. Check for provenance data 2. Check for SBOM in CycloneDX format 3. Check for vulnerability scan: a) Created by Trivy b) Up to 24 hours old c) No critical or high vulnerabilities
- 27. Nirmata Kubernetes Policy Management any infrastructure or cloud Kubernetes Clusters Build Deploy Run Confidential 27 Containerized Workloads SecOps DevOps FinOps
- 28. 28 Summary 1. Software supply chain security is critical 2. OSS tools like sigstore, in-toto, and Kyverno are leading the way 3. Nirmata (creators of Kyverno) provides a multi-cluster Kubernetes policy management for supply chain security