Thanks, will hold off for now then.

@sming-gitlab Hmm. Yeah, that is tricky. Would it be accurate to say this (or do you think it's confusing to say it hasn't started yet if the pipeline is pending?):

No pipelines started yet. Results will appear when a pipeline completes.

If not, your wording would work, just change "once" to "when".

👋 @khornergit. Looks great. Just left some wording suggestions, mostly. The only major thing I noted is the need to update features.yml if we want this to be a primary item. (optional if it's secondary.)

        This feature is available for Ultimate customers with Duo Agent Platform. The feature must be enabled in your group or project settings.

It's a little unclear what needs to be enabled here. Would break it up for clarity.

        - Automatic analysis: False positive detection runs automatically after each security scan with no manual intervention required.
        - Manual option: Users can manually run false positive detection for individual vulnerabilities on the vulnerability details page for on-demand analysis.
        - Focus on high-impact findings: Limiting the analysis to critical and high severity SAST vulnerabilities cuts through the noise where it matters most.
        - Contextual AI reasoning: Each assessment explains why a finding may or may not be a false positive, factoring in code context, data flow, and vulnerability characteristics specific to static analysis.
        - Seamless workflow integration: Results surface directly in the vulnerability report alongside existing severity, status, and remediation information — no changes to existing workflows required.

This is a high-level overview, so I would avoid the terms "trigger" and "true positive" where we can write around it.

        The assessment appears directly in the vulnerability report, giving security engineers the context they need to triage with confidence rather than uncertainty.

Guesswork isn't usually a adverb.

        SAST false positive detection, which was first introduced as a beta in 18.7, is now generally available in GitLab 18.10. 

We've transitioned to making this lowercase.

For primary features, we also need to update features.yml.

I think we can remove the GA part as well. We typically only tag beta items (and the initials "GA" aren't necessarily meaningful to users). Plus we explain the beta > GA transition in the first sentence.

    - name: "SAST False Positive Detection with GitLab Duo"

Hi @nrosandich. Just one adjustment to identify the offerings in the history. From the default_enabled field in the flag MR, it looks to me like this is enabled on all three, but I should probably get you to confirm that before merging.

@m-omokoh , @or-gal this looks good to me (I made a couple minor formatting tweaks, but the pipeline is still green), so this is good to go from my perspective. Docs changes are merged.

Thanks @arfedoro.

1. Hmm. Yeah, it's a bit hard to explain, but when we say "If any of the following apply:" and then we have several headings after it, it looks like each of the sections is part of the OR condition. (But they're not. They're nested under the "If all of the following" AND condition). So visually, it looks like if any of the subheadings apply, then the policies applies. It also doesn't help that the AND condition is not very visible hidden in a large text block. I'm not sure if you have any way of nesting the layers visually, for example:

If any of the following apply:

When...targeting any protected branch

And all of the following apply:

API Fuzzing

...

Secret Detection

• New and needs triage

Ryan Lehmann (a629f712) at 12 Mar 20:41

... and 1 more commit

Ryan Lehmann (f9f62f58) at 12 Mar 20:41

What does this MR do?

This merge request simplifies the security configuration profiles documentation by reducing technical depth while maintaining essential information.

Changes

• Replace inheritance explanation with clearer group/project application description
• Simplify secret detection profile description by removing detailed scan trigger list
• Rename and streamline profile details section (Scan triggers → Active Triggers)
• Remove detailed coverage status indicator explanations
• Reduce technical depth while maintaining essential information

Related issues

Applies PM feedback on documentation clarity and simplification.

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