Skip to content

Draft: Update Support for features in different stages of development

Julie Davilarequested to merge
juliedavila-master-patch-f358 into master

Overview

This MR strengthens security requirements for features at different maturity stages (Experimental, Beta, Limited Availability, Generally Available) to ensure production-ready features meet consistent security standards while allowing safe experimentation during development.

Changes

New Security Requirements

Experimental & Beta:

  • Must be disabled by default (explicit opt-in required)
  • Must maintain tenant isolation on multi-tenant platforms
  • Require documented plans for security release processes and audit logging before moving to GA

Limited Availability & Generally Available:

  • Must have operational security release processes and audit logging
  • Must complete security review before GA
  • Cannot ship with S1/S2 vulnerabilities without E-Group risk acceptance

Clarity Improvements

Terminology section defines:

  • Explicit opt-in vs. enabled by default
  • Production use (customer workloads + GitLab infrastructure)
  • Internal testing (Customer Zero)

Maturity transition principle introduces the "incident response test":

"If this risk would trigger urgent patching post-GA, it's blocking for GA"

Exception governance establishes approval authorities:

  • VP approval for Experimental→Beta exceptions
  • E-Group approval for Beta→GA exceptions

Rationale

These requirements operationalize "production-ready" with concrete criteria while supporting incremental security capability development. Teams can plan security capabilities during Beta and implement before GA, avoiding early-stage development bottlenecks.

Exception processes ensure urgent business needs can be balanced against security risk with appropriate executive oversight and documentation.

Edited by Julie Davila

Merge request reports