<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Replacement for Docker Content Trust (DCT)]]></title><description><![CDATA[<p dir="auto">What do others use for ensuring the authenticity of images after downloading them with <code>docker pull</code>?</p>
<p dir="auto">We’ve setup our CI build process to use docker for consistent, cross-platform builds. To ensure that our builds don’t use a malicious docker image (because the surface area of attack with TLS is <em>enormous</em> if you’re using X.509), we’ve been using DCT (Docker Content Trust).</p>
<p dir="auto">Unfortunately, I just discovered that the official docker documentation says that DCT is being deprecated. Apparently this was announced last year, and in June this blog post was published with advice:</p>
<ul>
<li><a href="https://www.docker.com/blog/docker-content-trust-retirement-and-migration-guidance/" rel="nofollow ugc">https://www.docker.com/blog/docker-content-trust-retirement-and-migration-guidance/</a></li>
</ul>
<h1>Cosign is not secure</h1>
<p dir="auto">We spent some time looking into cosign, but we discovered that the private keys aren't actually in the hands of the developer.</p>
<p dir="auto">Rather, they use <a href="https://docs.sigstore.dev/" rel="nofollow ugc">this complicated setup</a> using <a href="https://security.stackexchange.com/questions/234052/where-can-i-find-a-list-of-all-government-agencies-with-cas-in-pki-root-stores" rel="nofollow ugc">very insecure X.509</a> to issue temporary certificates.</p>
<p dir="auto">The result is that the OIDC identity provider (e.g., GitHub) <a href="https://medium.com/@raihanshamnad93/cosigns-keyless-verification-didn-t-match-our-threat-model-021da5cb121c" rel="nofollow ugc">extends the vector of attack <em>significantly</em></a> -- to probably <a href="https://devops.stackexchange.com/a/21734/22501" rel="nofollow ugc">tens of thousands of people</a> -- that can publish a malicious image that will be accepted by cosign as "trusted"</p>
<h1>Notation (Notary v2)</h1>
<p dir="auto">I also looked at Notation (aka “Notary v2”), but there’s no way to bootstrap the software safely, since (perplexingly) their tool for verifying the authenticity of images using cryptographic signatures itself <a href="https://github.com/notaryproject/notation/issues/1355" rel="nofollow ugc">can’t be verified using a cryptographic signature</a>.</p>
<h1>Alternatives</h1>
<p dir="auto">Are there any other alternatives that I can use to replace DCT to ensure the authenticity (using cryptography) of the container images that I download -- where the keys are actually held by the developer (thus significantly reducing the "insider threat" risk)?</p>
<p dir="auto">What do you (or does your org do) to ensure that you’re not using maliciously-modified containers after pulling a new docker image?</p>
]]></description><link>https://forum.ieu.app/topic/14e1ac3e-337c-4957-ac9a-6d8f348c4bce/replacement-for-docker-content-trust-dct</link><generator>RSS for Node</generator><lastBuildDate>Sat, 05 Sep 2026 23:26:13 GMT</lastBuildDate><atom:link href="https://forum.ieu.app/topic/14e1ac3e-337c-4957-ac9a-6d8f348c4bce.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 25 Aug 2026 18:02:26 GMT</pubDate><ttl>60</ttl></channel></rss>