Deprecation Policy — Plan

Context

CascadeGuard produces hardened container images that customers depend on in production. We need a published, predictable lifecycle policy so users know:

  1. How long an image version is supported
  2. When and how deprecation happens
  3. What action they need to take and by when
  4. How they will be notified

CEO Decision (2026-04-14): Rolling-Tag-Only Model

Confirmed: rolling-tag-only deprecation. No per-patch lifecycle tracking.

  • Every competitor (Chainguard, Docker Official, Ubuntu, Bitnami, AWS ECR) uses this model
  • Per-patch deprecation adds complexity with no market precedent
  • Differentiation comes from scan quality and actionable remediation, not lifecycle granularity

Lifecycle Model

Image Lifecycle States

StateMeaningVisible In
ActiveReceiving security patches, rebuilt on scheduleCatalog, Dashboard, Docs site
DeprecatedStill available but no longer rebuilt; migration recommendedCatalog (amber badge), Scan warnings, Docs site
EOL (End of Life)Removed from registry after grace periodRedirect to replacement, Docs site

Versioning: Release-Track/LTS Level

Lifecycle tracks at the release-track/LTS level (e.g. Node 20.x, Go 1.22.x). Minor/patch releases within a track are rolling — latest patch replaces previous with no separate deprecation.

Deprecation triggers only when:

  • The upstream track reaches EOL, or
  • A new LTS/release-track supersedes it

Mechanism: State File & Check

When the system discovers a new release track or LTS supersession:

  1. The published date is written into the state file
  2. The previous track is automatically marked deprecated from that date
  3. A scheduled check evaluates the state file and transitions to EOL based on tier timelines

Support Windows by Tier

Free Tier:

  • Current release track: Always active
  • Deprecated tracks: 90 days grace period from deprecation to EOL

Paid Tier:

  • Current release track: Always active
  • Deprecated tracks: 180 days grace period from deprecation to EOL
  • Extended support: Available on request beyond 180 days

Deprecation Timeline

  1. T-0: New LTS/track detected → previous track deprecated, date written to state file
  2. T+0: Amber badge in catalog and dashboard; notification to subscribers
  3. T+45 days: Midpoint reminder for free tier
  4. T+90 days (free): EOL
  5. T+90 days (paid): Midpoint reminder
  6. T+180 days (paid): EOL
  7. Post-EOL + 30 days: Removed from active registry (digest pullable for 90 days)

Upstream Deprecation (Docker Hub)

When Docker Hub officially deprecates an image (e.g., openjdk):

  • CascadeGuard marks it deprecated immediately
  • Provides recommended_replacement pointing to our hardened alternative
  • Scan worker flags DEPRECATED_BASE_IMAGE findings
  • 90-day grace period regardless of tier

Implementation Status

  1. Public policy pageCAS-511 done — merged to cascadeguard-docs
  2. Internal steering docCAS-512 done
  3. Strategy doc alignedCAS-538 done.ai/projects/cascadeguard/strategy/managed-image-deprecation.md merged
  4. 🔄 State file & check engineCAS-513 todo — Platform Engineer (policy now locked, unblocked)
  5. 🔄 Notification serviceCAS-514 todo — Full-Stack Engineer (policy now locked, unblocked)
  6. 🔴 Dashboard UX: free vs premiumCAS-515 blocked — blocked on CAS-450 (needs CLERK_SECRET_KEY added to GitHub preview environment by board)