epic: enterprise hardening — trustworthy v0.4 release

Goal

Make the next OpenShield release trustworthy, secure and operable for an enterprise deployment without adding product features for their own sake.

The current rule inventory is 95 unique rules with 95 matching playbooks. Rule count is not the release KPI: verified evidence coverage, explicit uncertainty, false-positive control and safe operation are.

Product boundary for this release

Recommended default: ship and document a securely enforced single-tenant enterprise deployment first. Do not claim multi-tenant SaaS until identity, ownership, tenant-scoped persistence and cross-tenant isolation tests exist.

Do not claim certification or "full compliance." Reports should describe versioned technical evidence coverage.

Phase 0 — containment and trust blockers

These block restoring or calling the current deployment enterprise-ready:

• #294 — remove the public demo bearer; establish real authorization/subscription boundaries
• #297 — remove the browser PAT flow and restore safe website rendering
• #298 — enforce required checks and two-person branch promotion
• #296 — fix the public readiness database-pool leak
• #299 — make the image bootable and deployment verification non-skippable
• #263 — persist explicit PASS/FAIL/ERROR/NOT_APPLICABLE evaluations
• #295 — make CRITICAL consistent across the full stack
• #300 — replace broken AZ-NET-012 with VNet flow-log evidence
• #301 — repair ACR rules against real Azure SDK models
• #302 — make framework reports current, evidence-based and non-certifying
• #265 — publish the collector permission/evidence manifest

Phase 1 — durable enterprise core

• #303 — transactions, leases, fencing, idempotency and durable background work
• #304 — one reproducible deployment and operations baseline
• #264 — tenant/subscription-safe inventory and real drift history
• #266 — approval, idempotency, audit and rescan gate for remediation
• #281 — recoverable dashboard error/empty/auth states
• #282 — frontend timeout and cancellation
• #199 — OpenSSF Silver work, aligned with the actual release design
• Establish cursor pagination, retention/purge and immutable scan/ruleset provenance
• Add PostgreSQL-backed transaction/concurrency tests and browser contract/e2e/a11y/XSS tests
• Align MAINTAINERS, CODEOWNERS, security contacts and access-continuity evidence with the real three-lead team

Phase 2 — validate, then expand scanner coverage

Existing rule-pack work should remain reviewable, but it must consume the Phase 0 evaluation and collector contracts before merge:

• #253 — network/perimeter
• #254 — application identity/OAuth
• #255 — AKS/workload
• #257 — governance/tenant controls
• #258 — privileged identity
• #259 — DevSecOps/supply chain/AI
• #261 — data protection/database
• #268 — compute quality pass

Every repaired or new rule must include:

• explicit applicability and PASS/FAIL/UNKNOWN/NOT_APPLICABLE behavior;
• required permissions and 403/429/5xx/partial-collection tests;
• real Azure SDK model contract tests and pagination coverage;
• authoritative evidence source, version, timestamp and fingerprint;
• false-positive analysis, exceptions and suppression expiry;
• versioned framework mapping rationale;
• preview-first, target-verified remediation with rollback and validation.

Enterprise release gates

The release stays blocked until all of the following are demonstrated:

• No reusable credential is present in public frontend or website assets.
• Authentication, RBAC and authorized subscription boundaries are integration-tested.
• Failed or incomplete evidence cannot produce PASS, a clean scan, or score 100.
• CRITICAL is consistent in scanner, database, APIs, reports and frontend.
• The published image starts, reaches database-aware readiness, and completes a worker-backed real scan.
• Required GitHub checks and two-person promotion are effective, not just documented.
• Framework editions/mappings are versioned, reviewed and presented as technical evidence coverage.
• SLOs, alerts, on-call ownership, backup restore and rollback drills have recorded evidence.
• Existing 95 rules have an evidence/permission/SDK validation matrix.
• No unresolved P0; every accepted P1 has named owner, rationale and expiry.

review model

• Programme/risk/claim gate: named lead plus cross-stream reviewer.
• Platform/release gate: named lead plus independent backup.
• Scanner/evidence gate: named lead plus cross-stream reviewer.
• Auth, scoring, compliance, infrastructure and release changes require review from two leads; authors do not self-approve.

Delivery order

1. Contain credentials and unsafe public surfaces.
2. Restore enforced merge controls.
3. Repair scanner truth and severity semantics.
4. Prove the runtime/deployment path end-to-end.
5. Harden persistence, operations and evidence provenance.
6. Validate all 95 rules.
7. Resume rule expansion in small quality-gated batches.

Start by reviewing the Phase 0 issues (#294, #297, #298, #296, #299 and the other blockers) and the stated release gates; this issue names no implementation files or tests. The work is done only when the documented enterprise release gates are demonstrated, including secure authorization, trustworthy evidence, a working deployment path and operational readiness.