# Quarterly Product Security Review — Worked Example > **Scenario:** Northstar Cloud, Q2 FY2026\ > **Audience:** Product Security leadership, VP Engineering, platform leadership, CTO, CFO observer\ > **Goal:** show what changed, where risk remains concentrated, and what needs leadership help this quarter ## 1. Executive summary **Risk direction:** improving, with one material concentration risk still unresolved. **Why:** Release confidence improved in the highest-criticality product lines, exception debt fell, and identity hardening reduced static credential exposure in CI/CD and cloud operations. The main unresolved concern is that risk is becoming more concentrated in a small set of multi-tenant services and shared platform dependencies. **Leadership ask:** approve one additional platform engineer for shared control work in Q3 and prioritize the tenant-isolation backlog in the core data services portfolio. ## 2. Quarter commitments vs delivery | Commitment | Planned outcome | Result | Notes | | ---------------------------------------- | ------------------------------------------------------------------------ | ----------------------- | ---------------------------------------------------- | | Expand release gates to Tier 1 services | 80% of Tier 1 production releases require evidence-backed security gates | **Completed at 83%** | Main gap is legacy reporting services. | | Reduce exception debt | Reduce active high-risk exceptions by 20% | **Completed at 27%** | Expired exceptions now enforced more consistently. | | Remove static cloud credentials from CI | Eliminate long-lived deployment credentials in default pipelines | **Mostly completed** | 92% migrated to federation; two legacy repos remain. | | Standardize threat model refresh cadence | Refresh top 15 critical service models | **Partially completed** | 11 completed; 4 slipped due to org changes. | | Improve runtime visibility | Raise production cluster coverage for runtime detection | **Completed** | Falco/Tetragon coverage increased on EKS clusters. | ## 3. Scope and coverage snapshot | Coverage lens | Q1 FY2026 | Q2 FY2026 | Direction | | ------------------------------------------------------ | --------: | --------: | -------------------------- | | Tier 1 apps under security release gates | 61% | 83% | Improving | | Services with current threat model (<12 months) | 48% | 67% | Improving | | CI/CD repositories using OIDC/workload federation | 54% | 92% | Strong improvement | | Production EKS clusters with runtime detection enabled | 50% | 88% | Strong improvement | | Critical findings older than 30 days | 39 | 24 | Improving | | High-risk active exceptions | 22 | 16 | Improving | | Tier 1 services with signed-image enforcement | 31% | 58% | Improving but still uneven | ## 4. What changed materially this quarter ### Positive developments 1. **Release control is now more trustworthy in the most important services.**\ The most meaningful improvement is not the raw finding count. It is that a larger share of the highest-materiality releases now passes through evidence-backed gates before production deployment. 2. **Credential exposure risk in delivery paths is down.**\ Moving from long-lived credentials to GitHub Actions OIDC and short-lived cloud roles materially reduced one of the most common breach-enabling patterns in build and deployment pipelines. 3. **Exception discipline improved.**\ Exceptions are now shorter, more traceable, and more often paired with compensating controls. ### Regressions or concerns 1. **Risk concentration increased in shared platform services.**\ We have fewer unresolved high-risk issues overall, but a larger fraction now sits in multi-tenant data and identity-adjacent services. 2. **Threat-model refresh still depends too heavily on a small number of reviewers.**\ We are better at starting reviews than finishing them on time across reorganizing teams. 3. **Runtime telemetry is broader but not yet equally actionable everywhere.**\ Coverage improved faster than investigation maturity in two clusters. ## 5. Top risk themes ### Theme 1 — Multi-tenant service concentration risk Three services support tenant boundary enforcement, entitlement checks, or reporting paths for multiple large customers. They are not broadly broken, but when controls are weak in shared services, the **blast radius per defect is higher** than in isolated services. **What changed this quarter** * tenant-boundary review completed for 2 of 3 priority services * one legacy reporting path still lacks full authorization consistency checks * compensating detective controls exist, but preventive controls are incomplete **Business implication** This is not a volume problem; it is a **concentration-of-impact** problem. A small number of defects could affect high-value enterprise tenants. ### Theme 2 — Shared platform dependency risk Control rollout still depends on central platform work for admission policies, image trust, runtime instrumentation, and egress restrictions. **Business implication** Product Security progress can stall even when individual product teams are cooperative. ### Theme 3 — Incomplete modernization in legacy delivery paths Two legacy repositories and one internal deployment path still rely on older assumptions around credentials, branch protection, and artifact trust. **Business implication** These are likely attack-entry points with worse assurance than the rest of the fleet. ## 6. Incidents, near misses, and lessons ### Near miss — public image with debug tooling A non-production container image with unnecessary tooling was pushed to an internal registry and later promoted into a staging path. The issue was caught before production deployment due to a registry policy check. **Why this matters** The near miss demonstrated that image policy guardrails now catch issues earlier than they did two quarters ago. **What changed because of it** * hardened-image policy made stricter for promotion paths * platform team added a clearer deny reason in CI so developers understand remediation faster ### Investigation — suspicious workload egress A production workload attempted egress to an unapproved destination. Investigation showed a misconfigured observability sidecar rather than malicious activity. **Lesson** Telemetry improved faster than runbook maturity. The signal was valuable, but the team needed clearer triage procedures. ## 7. Operating health | Operating metric | Q1 | Q2 | Commentary | | ------------------------------------------ | --------------: | --------------: | ---------------------------------------------------------- | | Median security review lead time (Tier 1) | 8 business days | 6 business days | Better coordination with platform and architecture review. | | Median exception approval time | 11 days | 7 days | Better templates and ownership rules. | | False-positive complaints on release gates | High | Moderate | Still a concern in Python worker repos. | | Open architecture reviews older than SLA | 9 | 5 | Improved, but still fragile if headcount changes. | ## 8. Decisions requested ### Decision 1 — prioritize tenant-isolation remediation in shared reporting services **Ask:** assign one staff engineer from core platform and one senior engineer from the reporting team to close the remaining authorization consistency gap in Q3. **Reason:** this is our clearest concentration-of-impact risk. ### Decision 2 — fund one additional platform-focused security engineer or platform engineer capacity **Ask:** fund one role or equivalent platform allocation to accelerate shared control rollout. **Reason:** the next plateau in improvement depends more on platform leverage than on ad hoc service reviews. ### Decision 3 — accept a constrained timeline for long-tail modernization **Ask:** explicitly classify two legacy deployment paths as modernization backlog items with bounded interim controls rather than treating them as surprise debt every quarter. ## 9. Suggested verbal close > We are in a better position than last quarter because our strongest controls now apply to more of the business-critical release paths. The unresolved risk is not broad chaos. It is concentration in a few shared services and platform dependencies. With targeted platform support in Q3, we can reduce material exposure faster than by spreading review time thinly across the entire fleet. ## Adaptation notes This worked example pairs well with: * [Quarterly Product Security Review Template](/metrics-audit-risk-evidence-and-compliance/index/quarterly-product-security-review-template.md) * [Roadmap, Investment, and Headcount Ask — Worked Example](/metrics-audit-risk-evidence-and-compliance/index-2/roadmap-investment-and-headcount-request-worked-example.md) * [Executive Risk Themes and Decisions — Worked Example](/metrics-audit-risk-evidence-and-compliance/index-2/executive-risk-themes-and-decisions-worked-example.md) *** *Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.* ## Sample packaged artifact * [Quarterly Product Security Review - PDF Sample](https://github.com/D3One/Product-Security-Gitbook/blob/main/assets/report-samples/quarterly-product-security-review-sample.pdf) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.product-security.expert/metrics-audit-risk-evidence-and-compliance/index-2/quarterly-product-security-review-worked-example.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.