What changed
FACT (source: docker.com blog): Docker is fully retiring Docker Content Trust and the Notary v1 service at notary.docker.io and has published guidance steering teams to Sigstore/Cosign and Notation.
Why now
HYPOTHESIS: there is a hard cutoff — when notary.docker.io is decommissioned, DCT-based sign/verify steps in CI start failing. The retirement is announced and terminal, which creates a time-boxed migration window. The exact decommission date is not in the provided source text, so the urgency is real but the deadline is unverified here.
Converging signals
Only ONE signal is provided (the Docker retirement blog). The 'convergence' is thin: a single vendor deprecation, not multiple independent signals meeting. The forced-chain framing is plausible but is inference, not corroborated by a second source.
Customer pain
HYPOTHESIS: teams whose CI still verifies images via DCT face a signing/verification gap at cutoff. No demand_evidence was supplied (empty array) — no complaints, no job postings, no mandate. Pain is asserted, not evidenced. Note also that DCT adoption was historically low; most teams already moved to Cosign or never signed at all.
Who pays
Engineering/platform/DevSecOps teams still on DCT. This is a self-selecting, likely SMALL population — the teams most locked into DCT are also the most capable of migrating themselves with free Sigstore tooling.
Solved today
FACT-adjacent: Sigstore/Cosign and Notation are free, open-source, well-documented, and backed by the CNCF/OpenSSF. Docker itself published the migration guidance. Teams can follow official docs, use `cosign sign`/`cosign verify`, and update policy in a day or two.
Why current solutions are bad
The gap is real but narrow: official docs cover the happy path; what's missing is bulk inventory of DCT-signed tags, automated re-signing at scale, and policy-swap templates for specific CI systems. That is a genuine but thin wedge — and one an open-source contributor could publish for free tomorrow.
Proposed product
A `dct2cosign` CLI that (1) inventories DCT/Notary v1 signatures across registries, (2) re-signs images with Cosign (keyless/OIDC or KMS) or Notation, (3) emits drop-in GitHub Actions / GitLab CI verification-policy templates, plus a fixed-price migration engagement for teams that want it done for them.
MVP version
Open-source CLI: read Notary v1 trust data, list signed repos/tags, batch `cosign sign` with a configured key/OIDC identity, and generate one GitHub Actions verify template. Ship in ~2-3 weeks.
30-day build
Build the CLI against a test registry with DCT-signed images; validate re-signing round-trips; publish OSS repo + a clear 'DCT is retiring, here's your migration path' landing page targeting the exact search terms.
60-day build
Add Notation output, GitLab/Jenkins templates, KMS/Vault key backends, and a hosted inventory scan. Offer a paid 'migration audit report' and a fixed-price done-for-you engagement.
90-day revenue plan
Revenue is service-led, not SaaS: 3-8 fixed-price migration engagements ($2k-$8k each) sourced from the OSS tool's users. Recurring SaaS revenue is unlikely — migration is one-and-done.
Distribution path
Content/SEO on 'Docker Content Trust retirement', posts in r/devops (note: Reddit ingestion is blocked here but posting is fine), Hacker News, CNCF/Sigstore Slack, and being the top OSS result for the migration query. This is demonstrated-value distribution, which fits the founder.
Pricing hypothesis
OSS CLI free (funnel); paid migration audit $500-$1,500; fixed-price done-for-you engagement $2,000-$8,000 depending on registry/image count.
Technical difficulty
Moderate-to-high: requires real DevSecOps depth in registry internals, Notary v1 trust data, Cosign keyless/OIDC, and multiple CI systems. Outside the founder's core (industrial ops, public records, government portals).
Legal / regulatory risk
Low. No licensure needed. Handling signing keys/OIDC identities is a security-sensitive responsibility but not a regulatory one.
Platform dependency
The trigger IS a platform deprecation, but the product submits to no platform that can deplatform it — no marketplace-approval or policy risk. The risk is the opposite: the whole opportunity depends on one vendor's timeline and evaporates once the migration window closes.
Founder fit
WEAK. This is not the founder's primary thesis (no public money, no forced government filer, no claimable money). It demands DevSecOps/supply-chain-security credibility he lacks, the buyer can DIY with free tooling, and the revenue is one-time services rather than per-filing recurring transactions. Surfaced honestly rather than forced into the portal pattern — but it does not fit.
Breakout potential
Low. One-time migration with a closing window; Sigstore momentum means the durable market is 'signing' broadly, which is already served by well-funded OSS. No compounding wedge.
Final recommendation
PASS / low priority. Real trigger, but thin single-signal convergence, zero supplied demand evidence, strong free incumbents, one-time non-recurring revenue, a closing window, and poor founder fit. If pursued at all, do it as a cheap 2-week OSS lead magnet for fixed-price services — not as a product bet — and only if a quick check shows a meaningful DCT-locked population still exists.
Next action
Spend 60 minutes validating population size before building: search GitHub/registries for active DCT/Notary v1 usage and check for existing 'dct to cosign' OSS migrators. If the installed base is negligible or a free migrator already exists, drop it.