Or Gal (718caefe) at 12 Mar 22:56

... and 1 more commit

Or Gal (580ff351) at 12 Mar 22:55

Team members for review and approval: Engineer(s): `` | Product Marketing: @PMM | Tech Writer: `@rlehmann1` | Product Designer(s): `@mfangman`

Engineering Manager to merge when the feature is deployed and enabled: @or-gal

Important note on tier labels: Until further notice, due to change management reasons, please leverage label core to indicate 'free' tier in all code and templates.

Please review the guidelines for content block creation at https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#content-blocks. They are frequently updated, and everyone should make sure they are aware of the current standards (PM, PMM, EM, and TW). There are separate (and slightly different) templates for primary and secondary features, bugs, removals, and upgrade notes. Please make sure to use the right template!

Please be aware deprecations follow a different process in a different project and you should not be using this MR template unless you are making edits to a release post prior to 14.4.

Links

• Feature Issue (required): gitlab-org#19802
• Pricing theme MR (required for primary features in Premium or Ultimate only):
• Feature MR (optional):
• Feature Flag Issue (optional):

Release Post

---
features:
  secondary:
  - name: "Pipeline secret detection in security configuration profiles"
    available_in: [ultimate]
    documentation_link: 'https://docs.gitlab.com/ee/user/application_security/configuration/security_configuration_profiles.html'
    gitlab_com: true
    self_managed: true
    gitlab_dedicated: true
    gitlab_dedicated_for_government: true
    add_ons: []
    reporter: m-omokoh
    stage: security_risk_management
    categories:
    - 'Vulnerability Management'
    image_url: '/images/unreleased/security-platform-management-pipeline-sd-profiles.png'
    issue_url:
    - 'https://gitlab.com/groups/gitlab-org/-/work_items/19802'
    description: |
      In GitLab 18.9, we introduced security configuration profiles with the Secret Detection - Default profile, starting with push protection. You can now apply standardized secret scanning enablement across hundreds of projects without touching a single CI/CD configuration file.

      The Secret Detection - Default profile now extends to cover pipeline-based scanning, completing a unified control surface for secret detection across your entire development workflow.

      The profile activates three scan triggers:

      - **Push Protection**: Scans all Git push events and blocks pushes where secrets are detected, preventing secrets from ever entering your codebase.
      - **Merge Request Pipelines**: Automatically runs a scan each time new commits are pushed to a branch with an open merge request. Results are scoped to new vulnerabilities introduced by the merge request.
      - **Branch Pipelines (default only)**: Runs automatically when changes are merged or pushed to the default branch, providing a complete picture of your default branch's secret detection posture.

      Applying the profile requires no YAML configuration. The profile can be applied at the group level to propagate coverage across all projects in scope, or at the project level for more granular control.

Key dates

• By Monday of the week the milestone ends: PMs should draft/submit for review ALL release post item content, whether they are feature or recurring blocks, earlier and no later than the Monday of the week the milestone ends.
• By Thursday, the day before the milestone ends: All required TW reviews as well as any optional PMM and PM Director/Group Manager reviews and resulting revisions should get done no later than Thursday, the day before the milestone ends.
• By the Friday the milestone ends: Release post items need to be marked with the Ready label in order to be merged for the current release post.
• By the end of the Friday the milestone ends: EMs will merge RP items with the Ready label by the end of day 11:59PM PT on the Friday the milestone ends. Any MRs merged into master after 11:59PM PT will not make the release post and need to follow this process:

If you need to make a change or addition to a release post item after 11:59PM PT on the Friday the milestone ends, open a new MR targeting the release-X-Y branch and assign to the Release Post Manager, with @mention of the lead Tech Writer and PMM. Please do not re-target the existing MR. Revisions for content in the release post branch should be made with new MRs targeted to the release post branch. It is important you follow the instructions on how to create a new MR to the release X-Y branch in Adding, editing, or removing merged content blocks after the Monday of release week and before the release date. It's highly recommended the PM connect with the release post manager to make sure content can still be added prior to creating the new MR.

Notes: Drafting release post content well in advance of the Monday of the week the milestone ends is highly recommended so reviews/revisions can happen in a rolling fashion and not bottleneck against the merge due date which is the Friday the milestone ends.

Getting ready for merge

Reminder: Make sure any feature flags have been enabled or removed!

Once all content is reviewed and complete, add the Ready label and set the Engineering Manager (EM) as the Assignee. The EM is responsible for merging as soon as the implementing feature is deployed to GitLab.com, after which this content will appear on the GitLab.com Release page and can be included in the next release post. All release post items must be merged on or before the Friday the milestone ends. If a feature is not ready by the due date of the Friday the milestone ends the EM should push the release post item to the next milestone.

PM release post item checklist

Pricing theme updates for Premium and Ultimate primary features

This is required as part of the release post workflow. However, since review/alignment on this may take longer than the release post allows, please use a separate MR to de-couple timeline dependencies.

Review

When the above is complete and the content is ready for review, it must be reviewed by Tech Writing. It can also be reviewed by Product Marketing, Product Design, and the Product Leader for this area.

Use the Reviewers for Merge Requests feature in GitLab when adding team members for content reviews. Reviewers will then approve the MR and remove themselves from Reviewers when their review is complete.

Tip: Try using the Review App in this MR to see exactly how the release post item is rendered.

• (Required) Tech Writer reviewed and approved
• (Recommended) PMM reviewed and approved
• (Optional) Product Designer reviewed and approved
• (Optional) Group Manager or Director reviewed and approved (ensuring the why is clearly explained: what is the problem we are solving for the user, and what value are we delivering.)
• PM adds Ready label and sets EM as Assignee for merge

Tech writer review

PMM review

PMM Review is Optional

EM release post item checklist

@vpedak1 Looks great, thanks! Looking forward to seeing the MR 🙏

@gkatz1 @rossfuhrman Please provide @vpedak1 some background knowledge about the various feature categories and he will take this issue

Or Gal (cb9cff7e) at 08 Mar 17:39

... and 1 more commit

Or Gal (21d9c268) at 08 Mar 17:38

Why is this change being made?

💡 Provide a detailed answer to the question on why this change is being proposed, in accordance with our value of Transparency.

Please add the details saying why, not just what in this section. Example: We have discussed the topic in Slack - (copy of Slack conversation). The current process is not efficient, this MR makes the description of X more clear, and helps move Y forward.

Update my team info according to the canonical approach: include link to the role

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• Update my team info according to canonical approach

@m-omokoh we are aligned 👍

Why is this change being made?

💡 Provide a detailed answer to the question on why this change is being proposed, in accordance with our value of Transparency.

Please add the details saying why, not just what in this section. Example: We have discussed the topic in Slack - (copy of Slack conversation). The current process is not efficient, this MR makes the description of X more clear, and helps move Y forward.

Update my team info according to the canonical approach: include link to the role

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• Update my team info according to canonical approach

FYI @ccharnolevsky