Skip to content

Security Risk Management: Security Policies 18.3 Planning Issue

Previous planning issue: Security Risk Management: Security Policies 18.... (#549770 - closed)

Narrative

IMPORTANT: This is a DRAFT planning issue prepared in advance, contingent on successful delivery of our %18.2 commitments.

Assuming successful completion of our %18.2 milestone, our team will have delivered significant capabilities including Security Policy Audit Events (Security policy audit events (&15869 - closed)), Centralized Security Policy Management as a beta feature (Centralized Security Policy Management (Beta) (&17392 - closed)), Flexible Scan Execution Policy Trigger Conditions (Scan Execution Policy Templates (&11919 - closed)), and Exceptions/Bypasses functionality through Source Branch Pattern Exceptions (Source branch pattern exceptions for MR Approva... (&18113 - closed)) and Service Account & Access Token Exceptions (Service Account & Access Token Exceptions for M... (&18112 - closed)). These deliverables will significantly enhance our users' control and flexibility over their security policy workflows.

For %18.3, our primary focus will be on building upon this foundation with three key initiatives:

  • MR Approval Policies Warn Mode (MR Approval Policies Warn Mode (&15552)) - We'll begin implementation of this highly requested feature, starting with backend MVC development and initial frontend work to enable warn mode capabilities and enforcement level configuration
  • User and Group Exceptions in MR Approval Policies (User and Group Exceptions in MR Approval Policies (&18114)) - Continuing our exceptions work by adding user and group selection capabilities to policy bypass options, providing even more granular control for our users
  • Security Policies v2 Foundation (Organization-Level Security Policy Management w... (&16664)) - Starting our architectural exploration for the next generation of Security Policies with improved scalability and UX through a comprehensive spike and proof of concept

This plan assumes successful %18.2 delivery and may require adjustment based on actual delivery outcomes, user feedback, and design completion status. We'll need to remain flexible and adapt our priorities based on real-world results from our %18.2 features.

As always, we'll continue to improve the quality of our Security Policies features, address bugs, and ensure reliable performance as more customers adopt these capabilities. Let's work together to deliver these important enhancements while maintaining the high quality our users expect!

Priorities

To release

User and Group Exceptions in MR Approval Policies (&18114)

Target release: %18.3

BE DRI: @sashi_kumar Backend backup DRI: @imam_h
FE DRI: @arfedoro

Building on the foundation established in %18.2 with source branch and service account exceptions, we'll extend our policy bypass capabilities to include user and group selection options. This will provide administrators with comprehensive control over who can bypass security policy requirements.

To start/continue working on

MR Approval Policies Warn Mode (&15552)

Target release: %18.5

BE DRI: @Andyschoenen Backend backup DRI: @bauerdominic
FE DRI: @aturinske

We'll begin implementation of MR Approval Policies Warn Mode, starting with backend MVC development and initial frontend components. This feature will allow policies to operate in a warning-only mode, providing valuable feedback without blocking merge requests.

Organization-Level Security Policy Management w... (&16664)

Target release: %18.5 (PoC)

BE DRI: @mcavoj (initial phase), then @bauerdominic Backend backup DRIs: @mc_rocha, @sashi_kumar

We'll begin foundational work on Security Policies v2 with comprehensive architectural planning and proof of concept development. This initiative will establish the groundwork for next-generation security policy management with improved scalability and user experience.

  • Success criteria:

    • Foundation architecture blueprint is completed and reviewed
    • Proof of concept demonstrates key architectural concepts
    • Technical feasibility is validated for improved scalability
    • Implementation roadmap for future milestones is established

  • Tasks:

To investigate

We'll conduct several important investigations to inform our implementation approaches and ensure we're building on solid foundations:

Quality Improvements

As in every milestone, we'll dedicate time to improving the quality of our Security Policies features. This includes addressing bugs, refining user experiences, and ensuring our features work reliably at scale.

  • Success criteria:

    • Critical bugs from %18.2 features are addressed promptly
    • Performance optimizations are implemented based on %18.2 feedback
    • Documentation is enhanced for newly released features
    • User guidance reflects latest capabilities and best practices

  • Tasks:

    • Address critical bugs and usability issues (DRI: All team members)
    • Implement performance improvements based on %18.2 feedback (DRI: All team members)
    • Enhance documentation for %18.2 released features (DRI: All team members)

Say/Do

@sashi_kumar

@aturinske

@mcavoj

@Andyschoenen

@arfedoro

@imam_h

@bauerdominic

@mc_rocha

Risks and Mitigations

To help us proactively address potential challenges, we've identified key risks for this milestone and corresponding mitigation strategies:

1. Dependency on %18.2 Successful Delivery

Risk: This entire plan is contingent on successful delivery of %18.2 commitments. Delays or issues with %18.2 features could significantly impact %18.3 priorities.

Mitigation:

  • Monitor %18.2 progress closely and communicate any potential delays early
  • Prepare alternative %18.3 priorities if %18.2 items need to carry over
  • Schedule plan review meeting immediately after %18.2 completion
  • Maintain flexibility in %18.3 scope to accommodate %18.2 feedback

2. Design Completion Risk for Warn Mode

Risk: MR Approval Policies Warn Mode currently has only basic designs generated using Claude. Lack of proper GitLab-standard designs could block frontend implementation progress.

Mitigation:

  • Prioritize design completion with UX team early in the milestone
  • Schedule design review sessions with stakeholders promptly
  • Prepare backend work to proceed independently while designs are finalized
  • Consider scope reduction if design completion is significantly delayed

3. Feedback Integration from %18.2 Features

Risk: User feedback from newly released %18.2 features may require immediate attention and could impact %18.3 planned work.

Mitigation:

  • Allocate buffer time for addressing %18.2 feedback
  • Establish clear criteria for what feedback requires immediate vs. future milestone attention
  • Maintain communication channels with early adopters of %18.2 features
  • Plan for potential scope adjustments based on user needs

4. Timeline Considerations

Risk: Starting planning one month early may result in outdated assumptions by the time %18.3 actually begins.

Mitigation:

  • Schedule mandatory plan review and update session after %18.2 completion
  • Document assumptions clearly so they can be validated later
  • Prepare for potential re-prioritization based on actual %18.2 outcomes
  • Maintain regular check-ins on external dependencies and design progress

Extra

Metrics

Release post items

Release post items related to current work in the format Epic | Release post | Milestone.

Epic Release post Milestone
&18114 [TBD] %18.3
Edited by Imam Hossain