DOCS-9659: Set due date rules (DataDog#26634)

drichards-87 · janine-c · web-flow · commit da7f596d0fa0 · 2025-02-13T17:06:14.000Z
* Add new article

* Rename article

* Add use case

* Minor edits

* Update instructions for due date rules

* Add Removing due dates section

* Add additional reason to removing due dates section

* Update types

* Add reviewer feedback

* Add further reading partial

* Move section to correct article

* Apply suggestions from code review

Co-authored-by: Janine Chan &lt;64388808+janine-c@users.noreply.github.com&gt;

* Apply suggestions from code review

Co-authored-by: Janine Chan &lt;64388808+janine-c@users.noreply.github.com&gt;

---------

Co-authored-by: Janine Chan &lt;64388808+janine-c@users.noreply.github.com&gt;
diff --git a/config/_default/menus/main.en.yaml b/config/_default/menus/main.en.yaml
@@ -5704,6 +5704,11 @@ menu:
       parent: automation_pipelines
       identifier: automation_pipelines_inbox
       weight: 10002
+    - name: Set Due Date Rules
+      url: security/automation_pipelines/set_due_date
+      parent: automation_pipelines
+      identifier: automation_pipelines_due_date
+      weight: 10003
     - name: Security Inbox
       url: security/security_inbox
       parent: security_platform
diff --git a/content/en/security/automation_pipelines/_index.md b/content/en/security/automation_pipelines/_index.md
@@ -9,6 +9,9 @@ further_reading:
   - link: "/security/automation_pipelines/security_inbox"
     tag: "Documentation"
     text: "Add to Security Inbox Rules"
+  - link: "/security/automation_pipelines/set_due_date"
+    tag: "Documentation"
+    text: "Set Due Date Rules"
 ---
 
 {{< callout btn_hidden="true">}}
@@ -19,6 +22,8 @@ further_reading:
 
 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%">}}
+
 ## Availability
 
 Automation Pipelines is available for:
@@ -57,6 +62,14 @@ Customize the Security Inbox by defining specific conditions that determine whic
 - **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.
 
+### Set due dates for vulnerabilities to align with your security SLOs
+
+Assign deadlines for vulnerability remediation to ensure compliance and improve team accountability. 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.
+
 ## Further reading
 
 {{< partial name="whats-next/whats-next.html" >}}
diff --git a/content/en/security/automation_pipelines/mute.md b/content/en/security/automation_pipelines/mute.md
@@ -2,6 +2,10 @@
 title: Mute Rules
 aliases:
   - /security/vulnerability_pipeline/mute
+further_reading:
+  - link: "/security/automation_pipelines"
+    tag: "Documentation"
+    text: "Automation Pipelines"
 ---
 
 {{< callout url="https://www.datadoghq.com/product-preview/security-automation-pipelines/" >}}
@@ -13,19 +17,33 @@ Configure mute rules to streamline security alerts by automatically filtering ou
 ## 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, **Cloud Infrastructure Anomaly Warnings**.
 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**, and **API Security Finding**.
+    - **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**
     - **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:
-    - **Reason for muting**: The reason for muting the finding. Available reasons include **False Positive**, **Risk Accepted**, **Pending Fix**, **No Fix**, **Duplicate**, and **Other**.
+    - **Reason for muting**: The reason for muting the finding. Available reasons include:
+      - **False Positive**
+      - **Risk Accepted**
+      - **Pending fix**
+      - **No Fix**
+      - **Duplicate**
+      - **Other**
     - **Rule expiration**: The date on which the rule expires. 
     - **Further description for muting reason**: Optional box for additional details.
-1. Click **Save**.
+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 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.
 
+## Further reading
+
+{{< partial name="whats-next/whats-next.html" >}}
+
 [2]: https://app.datadoghq.com/security/configuration/pipeline-vulnerability
diff --git a/content/en/security/automation_pipelines/security_inbox.md b/content/en/security/automation_pipelines/security_inbox.md
@@ -6,6 +6,9 @@ further_reading:
   - link: "/security/security_inbox"
     tag: "Documentation"
     text: "Security Inbox"
+  - link: "/security/automation_pipelines"
+    tag: "Documentation"
+    text: "Automation Pipelines"
 ---
 
 {{< callout url="https://www.datadoghq.com/product-preview/customize-your-security-inbox/" >}}
@@ -17,12 +20,16 @@ Configure inbox rules to manage your Security Inbox effectively, ensuring only t
 ## Create an inbox rule
 
 1. On the [Automation Pipelines][2] page, click **Add a New Rule** and select **Add to Security Inbox**.
-1. Enter a descriptive name for the rule, for example, Cloud Infrastructure Anomaly Warnings.
+1. Enter a descriptive name for the rule, for example, **Cloud Infrastructure Anomaly Warnings**.
 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**, and **API Security Finding**.
+    - **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**
     - **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**.
+1. Click **Save**. The rule applies to new findings immediately and starts checking existing findings within the next hour.
 
 ## Rule matching order
 
diff --git a/content/en/security/automation_pipelines/set_due_date.md b/content/en/security/automation_pipelines/set_due_date.md
@@ -0,0 +1,59 @@
+---
+title: Set Due Date Rules
+further_reading:
+  - link: "/security/automation_pipelines"
+    tag: "Documentation"
+    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.
+
+## Create a due date rule
+
+1. On the [Automation Pipelines][2] page, click **Add a New Rule** and select **Set Due Date**.
+1. Enter a descriptive name for the rule, for example, **Cloud Infrastructure Anomaly Warnings**.
+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:
+      - **Application Code Vulnerability**
+      - **Application Library Vulnerability**
+      - **Container Image Vulnerability**
+      - **Misconfiguration**
+      - **Attack Path**
+      - **Identity Risk**
+      - **API Security Finding**
+    - **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. Click **Save**. The rule applies to new findings immediately and starts checking existing findings within the next hour.
+
+## Where due dates appear
+
+When a finding has a due date, you can see it in these locations:
+
+- Explorer facets
+- Findings side panel
+- Notifications
+- Jira ticket descriptions
+- Reporting metrics (as an "overdue" Boolean) to identify teams or repositories with the most overdue vulnerabilities
+
+## 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.
+
+## Removing due dates
+
+When managing vulnerabilities, 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.
+
+## Further reading
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[2]: https://app.datadoghq.com/security/configuration/pipeline-vulnerability
diff --git a/static/images/security/automation_pipelines/vulnerabilities_settings.png b/static/images/security/automation_pipelines/vulnerabilities_settings.png
