Shift as far left as you can... but you trust the shifter?

Source: Dev.to

Key Themes in Customer Conversations

• Developer experience is a top priority for global enterprises.
• Trust is paramount. It is built on track record, credibility, and the assurance that financial transactions are backed by reliable partners.

Zero Trust and the “Shift‑Left” Movement

The concept of Zero Trust (or Never Trust, Always Verify) emphasizes evaluating risk management and incident handling. Blind trust in any tool is unrealistic; instead, we aim for pseudo‑trust built through transparency.

The shift‑left approach for security pushes scanning and exploitation analysis earlier in the Software Development Life Cycle (SDLC). Benefits include:

• Early detection of insecure code patterns and known CVEs in dependencies.
• Generation of build‑time (or cook‑time) SBOMs that document the software “recipe.”
• Continuous scanning, dynamic attack simulations, and frequent checks within IDEs and staging environments.
• Enforced code‑review policies (e.g., two approvers on a PR, blocked commits).

Securing the Software Supply Chain

Supply‑chain security is a complex puzzle composed of countless components from diverse contributors. Two core concepts help establish trust:

• Authenticity – confirming that a component truly originates from its claimed source.
• Integrity – ensuring the component has not been tampered with.

Tools such as cosign enable keyless cryptographic signing of files tied to an identity, allowing verification that a container image comes from a trusted provider (e.g., “Olive Garden”) rather than an unknown source.

Verifying Base Images

When using multi‑stage Dockerfiles, it’s essential to verify that base images are signed by a trusted source. A practical workflow:

1. Identify the base image in the Dockerfile.
2. Check its OCI signature against an allowlist of vetted providers.
3. If the signature is valid, the build proceeds; otherwise, it fails.

Note: Today this often resembles a denylist (rejecting known‑bad sources). As signatures become ubiquitous, it can evolve into a true allowlist model.

Looking Deeper into the Image Chain

Beyond the immediate base image, the software supply chain includes the base image’s own base image, and so on. As OCI image signatures mature, tools can recursively analyze Dockerfiles to verify the entire chain of dependencies.

TL;DR

• We operate with pseudo‑trust but should adopt a zero‑trust mindset.
• Sign your images and verify signatures against trusted sources.
• Treat the software supply chain as a chain, not just a single link.
• Consume components responsibly and tread optimistically.

Try It Out

Explore the Integrity‑Check tool on GitHub: