The CDK Threat Model
Abstract
This document enumerates the threats CDK's evidence model is designed to resist, the assumptions it depends on, and what remains explicitly out of scope. It complements the Security Architecture, which describes the mechanisms; this document describes what those mechanisms are for — and where they stop.
1. Scope
This document covers threats to the integrity of a single attestation and the Trust Graph built from it. It does not cover the security of the systems that produce the underlying events — CDK observes and attests; it does not harden the CI/CD platforms, cloud infrastructure, or identity providers it sits alongside.
2. Threats & Mitigations
Attestation Forgery
An attacker creates a fake attestation claiming an event occurred that didn't.
Every attestation requires a valid Sigstore signature tied to a verified OIDC identity. Forged attestations fail verification immediately.
Evidence Tampering
An attacker modifies a stored attestation after the fact.
Hash-chained storage breaks verifiably if any record changes. Rekor's independent log provides a reference point outside CDK's own database.
Replay
A valid, old attestation is resubmitted to claim a new event occurred.
Every attestation is bound to a specific artifact digest and timestamp. Replayed attestations reference stale digests and fail policy checks expecting current ones.
Identity Spoofing
An attacker impersonates a legitimate approver or signer.
Signing requires a live OIDC token from the identity provider itself. CDK never accepts a bare claim of identity without cryptographic proof behind it.
Compromised CI Runner
A build system is compromised and produces a legitimate-looking but malicious artifact.
This is explicitly out of scope for the Evidence Model alone — CDK attests to what a system reported, not whether that system was trustworthy. The digest binding still matters here: a compromised build produces a verifiable record of exactly what shipped, enabling detection after the fact even though it can't be prevented beforehand.
3. Assumptions
- OIDC Provider
- Assumed trustworthy — its tokens are not compromised or issued for spoofed identities.
- Sigstore Infrastructure
- Fulcio and Rekor are assumed available and uncompromised at time of signing.
- Source Platform Access
- The CI/CD platform enforces its own basic access controls; CDK does not replace them.
4. Out of Scope
- Securing the CI/CD platform itself
- Vetting the identity provider's own security practices
- Preventing a compromised build from producing a malicious artifact — only ensuring its provenance stays traceable afterward