Zero-Trust Fundamentals

The traditional security model follows a "trust by default, verify if suspected" approach. Resources inside the corporate network are trusted by default, while resources outside are untrusted. However, this model has fundamental problems: most attacks actually originate from within trusted networks, there's a detection lag between when attacks occur and when they're discovered, and attackers often operate undetected for weeks before being discovered.

The zero-trust model flips this entirely: "Never trust, always verify." Every request, access, and artifact must be verified first. User identity requires cryptographic proof, application identity is verified through signed attestations, data is verified through cryptographic hashes, and all network traffic is encrypted and verified. The result is that attacks are detected immediately with no dwell time—the attacker's work is blocked at the moment verification fails.

CleanStart applies these zero-trust principles throughout the software supply chain.

CleanStart applies zero-trust principles to software supply chain.

Four Pillars of Zero-Trust Supply Chain

Pillar 1: Identity Verification

Every component in the software supply chain must cryptographically prove its identity through unforgeable evidence. Consider code claiming to be version 4.18.2 of the express package. The proof is a cryptographic signature created by the expressjs maintainer using their GPG key X. Verification queries public key servers to retrieve the public key corresponding to key X, uses that public key to verify the signature on the code, and produces either a trust or reject decision. Similarly, a builder claiming to be CleanStart Factory v2.0 must provide proof via a signature from the CleanStart service account using a cryptographic key stored in Google Cloud KMS. Verification queries GCP KMS to validate the signature. A package claiming to be a binary compiled from source provides proof through reproducible build verification: the binary is rebuilt from source using the official build process, the hash of the rebuilt binary is computed, and this hash is compared to the published hash. If they match, the proof is valid. If they differ, the binary is rejected as potentially trojaned.

Pillar 2: Source Verification

Every artifact must provide an unbroken chain of evidence tracing back to verifiable source code. A compiled binary is traced to source code stored in a GitHub repository. The source code must have been committed by the original developer, and that commit must be cryptographically signed. The developer's GPG key must be published on public key servers, the key fingerprint must match the known maintainer's published fingerprint, and the key must be consistent with entries in the original package registry where the code was published. A reproducible build verification confirms that the published binary actually came from this source code by rebuilding the source and comparing the hash. Only when every piece of evidence lines up—when the source matches the commit, the commit is signed by the correct key, the key is verified to belong to the maintainer, the key matches the registry entry, and the reproducible build succeeds—is the artifact trusted. Any mismatch at any step results in immediate artifact rejection.

Pillar 3: Build Integrity

The entire build process must be verifiable and auditable from start to finish, with cryptographic proof of every step. When source code enters the build process, multiple verification steps occur in sequence. Source code signatures are fetched from the version control system and verified using the developer's key. All transitive dependencies are resolved through the dependency graph and each one is verified individually. The compilation toolchain (compiler, build tools, runtime) is verified to be legitimate and unmodified. Automated tests are run and must pass, with test results captured. Software Bills of Materials (SBOMs) are generated documenting every component in the built artifact. Cryptographic attestations are created providing SLSA L4 provenance proof. And all artifacts are signed with the build system's private key, proving they came from this specific build system.

The output is a cryptographically signed artifact accompanied by comprehensive evidence: a SLSA L4 attestation cryptographically proving the build process was secure and hermetic, an SBOM in standard format documenting every software component, and a VEX (Vulnerability Exploitability) document assessing which known vulnerabilities actually pose a risk in this specific context. During deployment, multiple verification checks occur: the attestation is verified to confirm the build process met high security standards, the SBOM is verified to document dependencies, the VEX is examined to assess vulnerability impact, and the signature is verified to prove the artifact hasn't been modified since it was built.

Pillar 4: Runtime Verification

Zero-trust verification doesn't stop at deployment—it continues throughout the container's entire lifetime in production. During the deployment phase, image content is verified: the image digest in the Kubernetes manifest is verified to match the actual image in the registry, the image signature is verified before the image is pulled, the image is checked to ensure no layers have been modified since the build completed, and all image layers are verified to confirm they haven't been corrupted or tampered with. During the runtime phase, continuous verification monitors the running container: every process is monitored to verify it matches expected behavior, all network calls are verified against network policies, all file system access is verified against allowed paths, and any code execution not authorized by the manifest is detected. If any verification check fails—whether during deployment or at runtime—an immediate alert is raised to the security team and automated remediation procedures are triggered to contain and investigate the issue.

Applied Zero-Trust: The Complete Flow

Step 1: Application Development

Application development begins with a developer writing code and committing it to GitHub. However, this simple action is protected by comprehensive zero-trust verification at multiple levels. The commit itself must be cryptographically signed using the developer's GPG key, providing proof of authorship and preventing commit impersonation. The code must pass automated checks including linters to catch style violations, type checkers to detect type errors, and security scanners to identify obvious vulnerabilities. Code review must occur with at least one other developer reviewing and approving the changes, providing human verification that the code is appropriate. All reviewers must be verified to belong to the organization and have active, healthy credentials—no review from compromised accounts is accepted. Branch protection must be enabled on the main branch, preventing force-pushes that could rewrite history or bypass review. If any requirement is missing—if a commit is unsigned, if automated checks fail, if review is skipped, if a reviewer's account shows signs of compromise, if branch protection is disabled—the deployment is blocked and the issue is escalated to the security team. This ensures that every line of code entering the build system has been vetted at multiple levels.

Step 2: Dependency Resolution

When the build process declares that it needs express@4.18.2, zero-trust verification immediately activates. The package is fetched from the npm registry along with its signature and published cryptographic hash. The source code is fetched from the official expressjs/express repository on GitHub. The npm registry's public key is queried and used to verify the package signature, proving the package came from npm. The expressjs maintainer's GPG key is queried and used to verify that the git commit is signed, proving the source code came from the maintainer. The maintainer's GPG key is verified against public key servers to ensure it belongs to the claimed maintainer and has not been revoked. The package is then rebuilt locally from source using the official build process (npm build for JavaScript). The hash of the rebuilt output is computed and compared to the hash published by npm. If all hashes match and all signatures are valid, the package is verified and trusted. If any hash differs or any signature fails to verify, the package is rejected as a potential attack, an alert is raised to the security team, and the build is blocked. This multi-step verification catches trojaned packages, compromised registries, and impersonated maintainers.

Step 3: Build Process

The factory builds the application using only verified dependencies from Step 2. The build process follows a rigorous, verifiable sequence. First, the toolchain (compiler, build tools, runtimes) must be verified—every binary that will be used to compile code must be cryptographically verified to be legitimate and unmodified. Second, only verified dependencies from Step 2 are used—no external package downloads or registry queries happen during the build. Third, the application code is compiled using the verified toolchain. Fourth, the complete test suite is run and all tests must pass, with failures triggering immediate build failure. Fifth, comprehensive SBOM and cryptographic attestation documents are generated, capturing every input and step. Sixth, all build artifacts are signed with the build system's private key, cryptographically proving they came from this specific build system and have not been modified. Seventh, the results are published to an immutable registry where they cannot be modified, overwritten, or deleted. The output is a signed artifact with complete cryptographic proof of its provenance and integrity.

Step 4: Image Assembly

The image factory assembles the final production container image from the verified packages built in Step 3. The assembly process begins with selecting a verified base image—typically a distroless image that has been pre-verified for security and minimal surface area. Packages are copied only from the verified registry, with signature verification enabled for each package. All packages are verified to be in the approved list, preventing unexpected dependencies from being included. The image is assembled using multi-stage Docker builds that separate the compilation stage from the runtime stage, ensuring development dependencies don't leak into the final image. Security hardening is applied at the image level: the root filesystem is made read-only to prevent runtime modification of code, the container is configured to run as a non-root user to limit privilege escalation, and all unnecessary Linux capabilities are dropped. Security tests are run including vulnerability scanning to identify any known CVEs and behavioral analysis to detect unexpected behavior. Comprehensive SBOM and VEX documents are generated, and cryptographic attestations are created proving the build process was secure. The entire image is signed with the Image Vault's signing key, creating an artifact that can be cryptographically verified at deployment time. Finally, the signed image is published to an immutable registry, where it cannot be deleted, modified, or overwritten. The output is a signed container image with complete provenance metadata and security documentation.

Step 5: Deployment

When an organization wants to deploy the image to Kubernetes, the deployment does not proceed automatically. Instead, comprehensive zero-trust verification checks occur. The image digest in the Kubernetes manifest is verified to match the actual image in the registry, catching any substitution attacks. The image signature is verified using the Image Vault's public key, proving the image hasn't been modified since it was signed. The SLSA L4 attestation is verified to confirm the build process was secure and hermetic. The SBOM is verified to confirm all dependencies are documented and known. The VEX is examined to understand how known vulnerabilities have been assessed and mitigated. The image is checked to confirm no layer has been tampered with or corrupted since it was built. Only if all these checks pass does the deployment proceed with high confidence. If any check fails, the deployment is blocked, an alert is raised to the security team, and the issue is investigated before deployment is attempted. This comprehensive pre-deployment verification ensures that only verified, unmodified images reach production.

Kubernetes policy enforcement:

apiVersion: admissionregistration.k8s.io/v1kind: ValidatingWebhookConfigurationmetadata:  name: image-verificationwebhooks:- name: verify-image.cleanstart.dev  admissionReviewVersions: ["v1"]  clientConfig:    service:      name: verifier      namespace: security      path: "/verify"  rules:  - operations: ["CREATE", "UPDATE"]    apiGroups: [""]    apiVersions: ["v1"]    resources: ["pods"]  failurePolicy: Fail  # ← Deny deployment if verification fails # This webhook verifies every pod deployment:# ✓ Image signature valid# ✓ Attestation present and valid# ✓ SBOM present and valid# ✓ Image digest matches manifest

Step 6: Runtime Monitoring

The container is now running in production, yet zero-trust verification does not stop at deployment—it continues continuously throughout the container's entire lifetime. Five continuous monitoring checks operate in parallel, providing real-time verification that the container is behaving as expected. Network policy enforcement ensures only connections to explicitly allowed destinations can be made; any attempt to connect to an unauthorized destination is blocked. File system integrity monitoring watches for any changes to files and alerts if unexpected modifications occur. Process monitoring confirms that only expected processes are running, alerting if unexpected processes spawn. Behavior monitoring at the system call level triggers alerts on unexpected activity like attempts to load kernel modules, modify system configuration, or access sensitive files. Log verification ensures that all audit logs are cryptographically signed and tamper-evident, making it impossible to cover up attack evidence by modifying logs. These five verification layers create a comprehensive monitoring posture.

If any verification check fails, an immediate incident response is triggered. An alert is raised to the security team with all relevant details for human review and investigation. Based on the investigation, three response paths are possible. If the activity is legitimate and represents a normal operational pattern that the policy didn't account for, the root cause is investigated to understand why the activity wasn't anticipated, and the policy is updated to reflect this legitimate activity in the future. If the activity is determined to be an attack, the affected pod is terminated immediately to stop the attack, affected users are notified, the security team escalates the incident, and a forensic investigation begins. If the activity is determined to be a misconfiguration where the application is functioning correctly but the policy was too strict, the policy is updated to allow the legitimate activity, or the application configuration is corrected to avoid triggering the check in the future.

Zero-Trust Implementation Details

Cryptographic Verification

Every artifact is cryptographically signed. When an artifact signed by Key 1 arrives at a deployment that has the corresponding public key 1, the verification process checks that the signature is valid for the artifact. If the artifact is authentic and unmodified, the verification succeeds. If an attacker modifies the artifact, the same verification check fails because the signature no longer matches the modified content. The deployment is blocked, preventing the attacker's modified artifact from being used.

Supply Chain Levels for Software (SLSA) L4

CleanStart targets SLSA L4, the highest maturity level. SLSA L0 provides no verifiable provenance. SLSA L1 adds source control and a trusted build service with versioned source and a trusted build environment, but without cryptographic proof. SLSA L2 adds build provenance with signed commits (git), available build logs, and signed provenance metadata, though the provenance is still incomplete. SLSA L3 adds hardened source and build controls: code review is required, the build environment is isolated, and hermetic builds are enforced to prevent external changes.

SLSA L4, which CleanStart implements, is the highest level. It requires all dependencies to be pinned, reproducible builds that produce byte-for-byte identical outputs when rebuilt, builds in isolated, sandboxed environments, complete tracking of all inputs and outputs, and cryptographic proof of every step in the build process.

CleanStart publishes SLSA L4 attestations for all artifacts.

Transparency Logs

All signing events are logged to immutable transparency logs (similar to Certificate Transparency in the TLS ecosystem). For example: express@4.18.2 was signed at 2024-03-20T14:30:00Z; myapp@1.0.0 was built using express@4.18.2; image myapp:1.0.0 was signed at 2024-03-20T14:35:00Z; and image was deployed to production at 2024-03-20T14:40:00Z. All events in the log are cryptographically signed, immutable (cannot be deleted or modified), queryable (any artifact's history can be audited), and tamper-evident (any modification is immediately detected).

This provides an auditable chain of all artifacts.

Zero-Trust Policies

CleanStart enforces comprehensive zero-trust policies across all stages of the software supply chain, creating a consistent security posture from development through production. The dependency policy governs which external packages can be used. It specifies allowed sources with full repository URLs like github.com/expressjs/express, pinning version ranges to prevent unexpected upgrades. All dependencies must have cryptographic signatures that can be verified using known maintainer keys. Dependencies must pass reproducible build verification, ensuring the published binary matches the source code. Generic entries from public registries are denied—every dependency must come from a verified source with a pinned version. The build policy governs the build environment and process. It requires an isolated build environment with no external network access except to fetch verified dependencies, preventing the build system from downloading untrusted code. Reproducible builds are mandated, ensuring identical output every time the same source is built with the same inputs, making any tampering immediately detectable. Signing keys must be stored in hardware security modules, preventing key theft or loss. All build outputs must include SLSA L4 attestation documenting the entire build process. The deployment policy specifies requirements before images can run in production. Every image must have valid cryptographic signatures proving its authenticity. Complete SBOMs (Software Bills of Materials) must document all dependencies. VEX documents must assess the exploitability of known vulnerabilities. All automated tests must pass, and code coverage must be at least 80%, indicating reasonable test coverage. Security scans must show zero critical vulnerabilities. The runtime policy enforces constraints while the application is running. Default-deny network policies block all external traffic except explicitly allowed destinations. Pod security policies prevent privileged container execution, preventing containers from gaining root on the host. Memory and CPU limits are enforced to prevent denial-of-service attacks. Read-only filesystems are required for production containers, preventing attackers from modifying code at runtime.

Benefits of Zero-Trust Supply Chain

The difference between traditional trust models and zero-trust is dramatically visible when a compromise occurs. In traditional trust models, an attack occurring on day 0 might not be detected until day 7, when unusual activity is finally noticed. Remediation doesn't complete until day 14, when all affected systems have been identified, patched, and verified. This creates a 14-day dwell time during which attackers operate undetected in production systems, potentially exfiltrating data, modifying code, or establishing persistence mechanisms. The blast radius can affect millions of users and months of work to recover from.

With zero-trust supply chain, a compromise on day 0 is detected on day 0 when verification fails. If an attacker tries to inject malicious code, the signature verification fails because the malicious code doesn't match the expected signature. If an attacker tries to modify a package, the hash verification fails. If an attacker tries to deploy a malicious image, the attestation verification fails. Remediation is complete on day 0—the malicious artifact is simply rejected and never deployed. Dwell time is measured in minutes rather than days, and the blast radius is limited to the single artifact version that was compromised. Attackers get no opportunity to operate in production systems.

Real-world examples illustrate the difference. The SolarWinds Orion compromise (2020) involved malicious code injected into the SolarWinds build system. The compromised software remained undetected for 18 months before discovery, affecting thousands of organizations and government agencies. With zero-trust supply chain, the build attestation verification would have failed immediately, detected within minutes, and the malicious code never deployed. The Log4j vulnerability (CVE-2021-44228) took weeks to fully patch across the ecosystem due to the manual work required for each organization to discover, patch, and verify their systems. With zero-trust supply chain, the automated patching cascade would identify all affected images, rebuild them with patched dependencies, test them, and stage them for deployment in hours. The Codecov compromise (2021) involved malicious code injected into Codecov's build scripts, allowing attackers to steal credentials. With zero-trust supply chain, attestation verification would have detected the unexpected build behavior, failing the build and blocking deployment entirely.

Challenges and Limitations

Zero-trust supply chain is strict and introduces real challenges that organizations must address. The first challenge is speed: traditional approaches allow immediate deployment with trust by default, while zero-trust adds minutes of verification overhead to every build and deployment. The solution involves caching verification results so repeated verification of the same artifact is instant, and performing verification in parallel for multiple artifacts so builds don't serialize verification steps. The second challenge is legacy tooling: many traditional development tools don't support cryptographic verification mechanisms or SBOM generation. The solution is building new tooling that integrates zero-trust concepts, and gradually migrating away from legacy systems that can't support verification. The third challenge is human processes: developers prefer quick iteration cycles where code flows from laptop to production in minutes, but zero-trust requires more discipline and slower cycles with additional verification steps. The solution is education about why the discipline matters for security, and automated enforcement to make verification happen automatically without manual steps that developers can skip. The fourth challenge is open source maintainers: many do not sign releases with GPG keys or publish SBOMs for their packages. The solution is partnering with maintainers to encourage adoption of best practices like signed releases and SBOMs, and providing tools that make signing and publishing SBOMs easier for maintainers.

Industry Adoption

Zero-trust supply chain is rapidly becoming the industry standard for security-conscious organizations. The National Institute of Standards and Technology (NIST) recommends zero-trust architecture as the foundational security model. US Executive Order 14028 on Cybersecurity mandates secure software development practices, including supply chain verification. The Linux Foundation has developed the SLSA framework, which is gaining adoption across the industry. The cloud-native ecosystem is standardizing on the Sigstore project, which provides standardized tooling for software signing and verification. Major enterprises are actively adopting zero-trust models as part of their security strategies. CleanStart implements these best practices as standard functionality, not as optional or advanced hardening features. This means every image built with CleanStart has complete zero-trust verification from source to production, without any additional configuration required.

Conclusion

Zero-trust supply chain flips the security model: instead of trusting code until proven malicious, you trust only code that's been cryptographically verified.

This requires more work upfront but prevents entire categories of attacks. For organizations building critical infrastructure, this model is essential.

CleanStart makes zero-trust supply chain practical and scalable.