DOCS-10634: Remove preview banners from Automation Pipelines docs

content/en/security/automation_pipelines/_index.md

@@ -14,15 +14,7 @@ further_reading:
     text: "Set Due Date Rules"
 ---
 
-{{< callout btn_hidden="true">}}
-  Automation Pipelines is in Preview. To enroll and access the automated rules, you must register for each set of rules separately:
-  <ul><li><a href="https://www.datadoghq.com/product-preview/security-automation-pipelines/">Mute and Assign Due Date</a></li>
-  <li><a href="https://www.datadoghq.com/product-preview/customize-your-security-inbox/">Add to Security Inbox</a></li></ul>
-{{< /callout >}} 
-
-Automation Pipelines allows you to set up automated rules for newly discovered vulnerabilities, thus accelerating triage and remediation efforts at scale.
-
-{{< img src="security/automation_pipelines/vulnerabilities_settings.png" alt="Automation Vulnerabilities Settings page" width="100%">}}
+Automation Pipelines allows you to set up automated rules for newly discovered findings, thus accelerating triage and remediation efforts at scale.
 
 ## Availability
 
@@ -32,43 +24,44 @@ Automation Pipelines is available for:
 - Attack paths
 - Identity risks
 - Vulnerabilities
+- Application Code Vulnerability
+- Application Library Vulnerability
+- Container Image Vulnerability
+- API Security Finding
+- Host Vulnerability
 
 ## How it works
 
-Automation Pipelines operates through a rules-based system that allows you to automate how new vulnerabilities are managed. Here's how it works:
+Automation Pipelines operates through a rules-based system that allows you to automate how new findings are managed. Here's how it works:
 
-- **Rule configuration**: Each rule consists of multiple criteria, designed to filter vulnerabilities based on specific attributes. Within a rule, the combination of these criteria operates as a logical AND; however, if any criteria include multiple values, those values operate as a logical OR. This structure gives you the flexibility to create rules that precisely target your needs.
-- **Rule matching**: Automation Pipelines evaluates vulnerabilities against your rules in the order you've listed them. As each vulnerability is processed, Automation Pipelines moves through the list until it finds a matching rule, at which point the specified action—such as muting non-urgent issues or highlighting critical threats—is triggered.
+- **Rule configuration**: Each rule consists of multiple criteria, designed to filter findings based on specific attributes. Within a rule, the combination of these criteria operates as a logical AND; however, if any criteria include multiple values, those values operate as a logical OR. This structure gives you the flexibility to create rules that precisely target your needs.
+- **Rule matching**: Automation Pipelines evaluates findings against your rules in the order you've listed them. As each finding is processed, Automation Pipelines moves through the list until it finds a matching rule, at which point the specified action—such as muting non-urgent issues or highlighting critical threats—is triggered. Automation Pipeline rules apply immediately to new findings. For existing findings, updates can take up to two hours.
 
 ## Use cases
 
-### Mute non-urgent findings so you can prioritize immediate threats
+### Mute non-urgent findings to focus on what matters
 
-Mitigate information overload by muting non-urgent findings, so you can focus on critical threats. This allows you to:
+Reduce alert fatigue and prioritize critical threats by automatically muting non-urgent findings. This allows you to:
 
-- **Proactively discard non-urgent findings**: Automatically filter out known scenarios that don't require immediate action, such as false positives or accepted risks, without manual intervention.
-- **Focus on true risks**: Prioritize and address genuine threats, ensuring your attention is directed towards remediating real and pressing issues.
-- **Streamline security alerts**: Eliminate noise from security alerts related to:
-  - Known false positives
-  - Resources deemed non-critical or unimportant
-  - Intentional vulnerabilities in controlled environments
-  - Ephemeral resources that naturally flag without posing long-term concerns
+- **Automatically ignore low-priority issues**: Suppress known false positives, accepted risks, and other findings that don't require immediate action. No manual review is needed.
+- **Prioritize real threats**: Keep your attention on high-impact alerts that demand investigation and remediation.
+- **Declutter your alert stream**: Eliminate noise from false positives, non-critical resources, test or staging environments, and short-lived resources that trigger alerts but pose no long-term risk.
 
 ### Customize the Security Inbox to highlight what's important to your organization
 
 Customize the Security Inbox by defining specific conditions that determine which security issues are highlighted. This allows you to:
 
-- **Resurface issues not captured by default**: Highlight issues that might be missed by out-of-the-box or custom detection rules, ensuring no critical issue is overlooked.
+- **Resurface issues not captured by default**: Highlight issues that might be missed by out-of-the-box or custom detection rules to ensure critical issues are not overlooked.
 - **Strengthen compliance and address key system concerns**: Address concerns affecting regulatory compliance or important business systems, regardless of severity.
-- **Prioritize current risks**: Focus on immediate threats, such as identity risks after an incident, or industry-wide vulnerabilities.
+- **Prioritize current risks**: Focus on immediate threats, such as identity risks after an incident, or industry-wide findings.
 
-### Set due dates for vulnerabilities to align with your security SLOs
+### Set due dates for findings to align with your security SLAs
 
-Assign deadlines for vulnerability remediation to ensure compliance and improve team accountability. This allows you to:
+Assign remediation deadlines to findings to improve accountability and stay compliant with your security policies. This allows you to:
 
-- **Align with compliance frameworks**: Automatically set due dates that conform to industry regulations like FedRAMP or PCI.
-- **Enhance accountability**: Utilize security SLOs to hold teams responsible for timely vulnerability remediation, reducing the administrative burden of follow-ups and status checks.
-- **Facilitate proactive risk management**: Encourage prompt action on vulnerabilities to mitigate the risk of exploitation, leveraging SLOs as a strategic tool to prioritize and expedite security tasks.
+- **Stay compliant by design**: Automatically apply due dates that align with industry standards, such as FedRAMP, PCI, and others.
+- **Drive accountability across teams**: Use SLAs to ensure timely remediation without constant follow-ups, giving security and engineering clear expectations.
+- **Promote proactive risk management** Encourage faster response times and reduce exposure by using SLAs to prioritize and track remediation efforts.
 
 ## Further reading
 

content/en/security/automation_pipelines/mute.md

@@ -8,22 +8,23 @@ further_reading:
     text: "Automation Pipelines"
 ---
 
-{{< callout url="https://www.datadoghq.com/product-preview/security-automation-pipelines/" >}}
-  Automation Pipelines is in Preview. To enroll in the Preview for mute rules, click <strong>Request Access</strong>.
-{{< /callout >}}
-
 Configure mute rules to streamline security alerts by automatically filtering out non-urgent findings. This approach helps reduce noise from known false positives and accepted risks, allowing you to focus on addressing the most critical threats.
 
 ## Create a mute rule
 
 1. On the [Automation Pipelines][2] page, click **Add a New Rule** and select **Mute**.
-1. Enter a descriptive name for the rule, for example, **Cloud Infrastructure Anomaly Warnings**.
+1. Enter a descriptive name for the rule, for example, **Compensating control in place for account payment-prod**.
 1. Use the following boxes to configure the rule criteria:
     - **Any of these types**: The types of findings that the rule should check for. Available types include:
       - **Misconfiguration**
       - **Attack Path**
       - **Identity Risk**
       - **API Security Finding**
+      - **Application Code Vulnerability**
+      - **Application Library Vulnerability**
+      - **Container Image Vulnerability**
+      - **API Security Finding**
+      - **Host Vulnerability**
     - **Any of these tags or attributes**: The resource tags or attributes that must match for the rule to apply.
 1. To add severity criteria to the rule, click **Add Severity**.
 1. Specify the mute reason and duration:
@@ -40,7 +41,7 @@ Configure mute rules to streamline security alerts by automatically filtering ou
 
 ## Rule matching order
 
-When Datadog identifies a vulnerability, it evaluates the vulnerability against your sequence of mute rules. Starting with the first rule, if there's a match, Datadog mutes the vulnerability for the specified duration and stops evaluating further. If no match occurs, Datadog moves to the next rule. This process continues until a match is found or all rules are checked without a match.
+When Datadog identifies a finding, it evaluates the finding against your sequence of mute rules. Starting with the first rule, if there's a match, Datadog mutes the finding for the specified duration and stops evaluating further. If no match occurs, Datadog moves to the next rule. This process continues until a match is found or all rules are checked without a match.
 
 ## Further reading
 

content/en/security/automation_pipelines/security_inbox.md

@@ -11,10 +11,6 @@ further_reading:
     text: "Automation Pipelines"
 ---
 
-{{< callout url="https://www.datadoghq.com/product-preview/customize-your-security-inbox/" >}}
-  Automation Pipelines is in Preview. To enroll in the Preview for Add to Security Inbox rules, click <strong>Request Access</strong>.
-{{< /callout >}} 
-
 Configure inbox rules to manage your Security Inbox effectively, ensuring only the most relevant security issues are highlighted. By customizing conditions, you can focus on critical concerns, prioritize key risks, support compliance, and bring attention to issues that might otherwise be overlooked.
 
 ## Create an inbox rule
@@ -27,13 +23,18 @@ Configure inbox rules to manage your Security Inbox effectively, ensuring only t
       - **Attack Path**
       - **Identity Risk**
       - **API Security Finding**
+      - **Application Code Vulnerability**
+      - **Application Library Vulnerability**
+      - **Container Image Vulnerability**
+      - **API Security Finding**
+      - **Host Vulnerability**
     - **Any of these tags or attributes**: The resource tags or attributes that must match for the rule to apply.
 1. To add severity criteria to the rule, click **Add Severity**.
 1. Click **Save**. The rule applies to new findings immediately and starts checking existing findings within the next hour.
 
 ## Rule matching order
 
-When Datadog identifies a vulnerability, it evaluates the vulnerability against your sequence of inbox rules. Starting with the first rule, if there's a match, Datadog adds the vulnerability to the Security Inbox and stops evaluating further. If no match occurs, Datadog moves to the next rule. This process continues until a match is found or all rules are checked without a match.
+When Datadog identifies a finding, it evaluates the finding against your sequence of inbox rules. Starting with the first rule, if there's a match, Datadog adds the finding to the Security Inbox and stops evaluating further. If no match occurs, Datadog moves to the next rule. This process continues until a match is found or all rules are checked without a match.
 
 ## Further reading
 

content/en/security/automation_pipelines/set_due_date.md

@@ -6,11 +6,7 @@ further_reading:
     text: "Automation Pipelines"
 ---
 
-{{< callout url="https://www.datadoghq.com/product-preview/security-automation-pipelines/" >}}
-  Automation Pipelines is in Preview. To enroll in the Preview for due date rules, click <strong>Request Access</strong>.
-{{< /callout >}} 
-
-Configure due date rules to ensure vulnerabilities are addressed within your specified SLO time frames. By setting these due dates, you can automate accountability, meet compliance requirements, and prioritize the prompt remediation of security issues, thereby preventing potential exploitation.
+Configure due date rules to ensure findings are addressed within your specified SLO time frames. By setting these due dates, you can automate accountability, meet compliance requirements, and prioritize the prompt remediation of security issues, thereby preventing potential exploitation.
 
 ## Create a due date rule
 
@@ -25,8 +21,9 @@ Configure due date rules to ensure vulnerabilities are addressed within your spe
       - **Attack Path**
       - **Identity Risk**
       - **API Security Finding**
+      - **Host Vulnerability**
     - **Any of these tags or attributes**: The resource tags or attributes that must match for the rule to apply.
-1. Set a due date for each severity level that requires one, effective from the discovery of a matching severity vulnerability.
+1. Set a due date for each severity level that needs one. The due date starts from when the matching finding was discovered, not when the rule was created.
 1. Click **Save**. The rule applies to new findings immediately and starts checking existing findings within the next hour.
 
 ## Where due dates appear
@@ -41,16 +38,16 @@ When a finding has a due date, you can see it in these locations:
 
 ## Rule matching order
 
-When Datadog identifies a vulnerability, it evaluates the vulnerability against your sequence of due date rules. Starting with the first rule, if there's a match, Datadog sets a due date on the vulnerability for the specified duration and stops evaluating further. If no match occurs, Datadog moves to the next rule. This process continues until a match is found or all rules are checked without a match.
+When Datadog identifies a finding, it evaluates the finding against your sequence of due date rules. Starting with the first rule, if there's a match, Datadog sets a due date on the finding for the specified duration and stops evaluating further. If no match occurs, Datadog moves to the next rule. This process continues until a match is found or all rules are checked without a match.
 
 ## Removing due dates
 
-When managing vulnerabilities, due dates can be removed under various conditions, such as:
+When managing findings, due dates can be removed under various conditions, such as:
 
-- The detection rule that triggered the vulnerability passes successfully.
-- The vulnerability is muted, either manually or automatically through a mute rule.
-- The due date rule associated with the vulnerability is disabled or deleted.
-- The associated due date rule is modified so that its criteria no longer match the vulnerability.
+- The detection rule that triggered the finding passes successfully.
+- The finding is muted, either manually or automatically through a mute rule.
+- The due date rule associated with the finding is disabled or deleted.
+- The associated due date rule is modified so that its criteria no longer match the finding.
 
 ## Further reading
 

content/en/security/security_inbox.md

@@ -69,10 +69,6 @@ Key features include:
 
 ## Customize Security Inbox to highlight crucial issues
 
-{{< callout url="https://www.datadoghq.com/product-preview/customize-your-security-inbox/" >}}
-  Automation Pipelines is in Preview. To enroll in the Preview for Add to Security Inbox rules, click <strong>Request Access</strong>.
-{{< /callout >}}
-
 Automation Pipelines enables you to configure rules that customize your Security Inbox, allowing you to highlight issues that are critical to your organization. By setting up these automated rules, you can streamline the management of newly discovered vulnerabilities, enhancing triage and remediation efforts at scale. Leveraging both the Automation Pipelines and Add to Security Inbox rules, you can optimize your security operations in the following ways:
 
 - **Resurface issues not captured by default**: Highlight issues that might be missed by default or custom detection rules, ensuring no critical issue is overlooked.