[SEC-31367] Document Ticket Creation Rules for Automation Pipelines

config/_default/menus/main.en.yaml

@@ -7288,6 +7288,11 @@ menu:
       parent: automation_pipelines
       identifier: automation_pipelines_due_date
       weight: 10003
+    - name: Create Tickets
+      url: security/automation_pipelines/create_ticket
+      parent: automation_pipelines
+      identifier: automation_pipelines_create_ticket
+      weight: 10004
     - name: Security Inbox
       url: security/security_inbox
       parent: security_platform

content/en/security/automation_pipelines/_index.md

@@ -12,6 +12,9 @@ further_reading:
   - link: "/security/automation_pipelines/set_due_date"
     tag: "Documentation"
     text: "Set Due Date Rules"
+  - link: "/security/automation_pipelines/create_ticket"
+    tag: "Documentation"
+    text: "Ticket Creation Rules"
   - link: "https://www.datadoghq.com/blog/datadog-iac-security/"
     tag: "Blog"
     text: "Prevent cloud misconfigurations from reaching production with Datadog IaC Security"
@@ -25,17 +28,17 @@ Automation Pipelines allows you to set up automated rules for newly discovered f
 
 Automation Pipelines is available for:
 
-- Misconfigurations
-- Attack paths
-- Identity risks
-- Secrets
-- Infrastructure as Code
 - Runtime Code Vulnerabilities
 - Static Code Vulnerabilities
 - Library Vulnerabilities
+- Secrets
+- Infrastructure as Code
 - Container Image Vulnerabilities
-- API Security findings
 - Host Vulnerabilities
+- Misconfigurations
+- Attack Paths
+- Identity Risks
+- API Security
 
 ## How it works
 
@@ -68,7 +71,15 @@ Assign remediation deadlines to findings to improve accountability and stay comp
 
 - **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.
+- **Promote proactive risk management**: Encourage faster response times and reduce exposure by using SLAs to prioritize and track remediation efforts.
+
+### Automatically create tickets to route findings into engineering workflows
+
+Route security findings directly into Jira or Case Management as soon as they are discovered. This allows you to:
+
+- **Eliminate manual triage**: Automatically generate tickets for findings that match your criteria, removing the need for security teams to create tickets by hand.
+- **Integrate with existing engineering workflows**: Meet engineering teams where they already work by routing security work into the same tools they use for other tasks.
+- **Reduce time to remediation**: Get findings into engineering queues immediately after detection, eliminating the delay between discovery and assignment.
 
 ## Further reading
 

content/en/security/automation_pipelines/create_ticket.md

@@ -0,0 +1,98 @@
+---
+title: Ticket Creation Rules
+site_support_id: case_management
+products:
+  - name: Cloud Security
+    url: /security/cloud_security_management/
+    icon: cloud-security-management
+  - name: Code Security
+    url: /security/code_security/
+    icon: security-code-security
+  - name: App and API Protection
+    url: /security/application_security/
+    icon: app-sec
+further_reading:
+  - link: "/security/automation_pipelines"
+    tag: "Documentation"
+    text: "Automation Pipelines"
+  - link: "/security/ticketing_integrations"
+    tag: "Documentation"
+    text: "Ticketing Integrations"
+  - link: "/incident_response/case_management"
+    tag: "Documentation"
+    text: "Case Management"
+---
+
+{{< product-availability >}}
+
+Configure ticket creation rules to automatically create tickets in Jira or Case Management when new findings are discovered. This approach tracks security issues in your existing engineering workflows without manual triage, helping teams respond quickly to new threats at scale. For more information about ticketing integrations with security findings, see [Ticketing Integrations][3].
+
+## Create a ticket creation rule
+
+1. In Datadog, go to **Security** > **Settings** > [Findings Automation][2]. Click **Add a New Rule**, then select **Create Ticket**. The Create a New Rule page opens.
+1. Under **Rule name**, enter a descriptive name for the rule; for example, "Critical vulnerabilities for engineering team".
+1. Add your rule criteria into the following fields:
+    - **Any of these types**: The types of findings that the rule should check for. Available types include:
+      - Runtime Code Vulnerability
+      - Static Code Vulnerability
+      - Library Vulnerability
+      - Secret
+      - Infrastructure as Code
+      - Container Image Vulnerability
+      - Host Vulnerability
+      - Misconfiguration
+      - Attack Path
+      - Identity Risk
+      - API Security
+    - **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. Select the ticketing system and configure the ticket destination:
+   - **Jira**
+     - **Jira Account**: Select the Atlassian instance to use.
+     - **Space**: Select the Jira project. Verify that this space is added to the [Jira Webhook][5].
+     - **Ticket Type**: Select the type of Jira issue to create, for example, **Task**.
+     - **Assignee** (optional): Specify a user to assign automatically created tickets to.
+     - To add more fields to the Jira ticket Datadog creates, use **Add Optional Field**.
+     - Expand **Data Sync Settings** to review or update the linked Case Management project and bidirectional sync configuration.
+   - **Case Management**
+     - **Case Management Project**: Select an existing Case Management project, or create one.
+     - **Assignee** (optional): Specify a user to assign automatically created cases to.
+1. Under **Rate limit**, enter the [maximum number of tickets](#daily-ticket-limit) this rule can create per UTC day.
+1. To test the rule before saving, click **Test Rule**, select a matching finding, and click **Run Test**. After the test completes, you can view the created ticket or detach the test ticket from the finding.
+1. Click **Save**. The rule applies to new findings only. It can take up to a few minutes after a finding is detected to create the corresponding ticket.
+
+**Note**: Ticket creation rules only create tickets for new findings. Datadog does not create retroactive tickets for existing findings when you create a rule.
+
+## Identify automatically created tickets
+
+{{< img src="security/automation_pipelines/ticket_creation_lightning_indicator.png" alt="Case Management ticket popup showing a case created by an Automation Rule, indicated with a lightning bolt icon, and a link to view all findings with tickets that were created from the same rule" style="width:60%;" >}}
+
+Tickets created by a rule are marked with a lightning bolt indicator in the findings side panel and explorer views. Hovering over the indicator shows the automation rule responsible for the ticket and provides a link to the rule.
+
+## Rule matching order
+
+When Datadog identifies a finding, it evaluates the finding against your sequence of ticket creation rules. Starting with the first rule, if there's a match, Datadog creates a ticket using that rule's configuration 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.
+
+## Daily ticket limit
+
+Each rule has a configurable daily ticket limit that resets at midnight UTC. When the limit is reached, Datadog creates one final ticket in the same project explaining that the rule hit its daily limit, then stops creating tickets for the remainder of that day. Findings that exceed the limit are not retroactively ticketed when the limit resets, but you can create tickets for them manually.
+
+## Broken rules
+
+If a project configuration error prevents ticket creation—for example, if the connected Jira project is no longer valid—Datadog automatically disables the rule and marks it as broken.
+
+{{< img src="security/automation_pipelines/ticket_creation_broken_rule.png" alt="Automation Pipelines list showing a ticket creation rule with a warning tooltip that says 'Rule auto-disabled due to a ticketing integration error'" style="width:100%;" >}}
+
+To resume automatic ticket creation, fix the project configuration and re-enable the rule.
+
+## Disabled or deleted rules
+
+When you disable or delete a ticket creation rule, tickets that were previously created by the rule remain attached to their findings. They are not detached or deleted.
+
+## Further reading
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[2]: https://app.datadoghq.com/security/configuration/findings-automation?opened-sections=create_ticket
+[3]: /security/ticketing_integrations/
+[5]: /integrations/jira/#configure-a-jira-webhook

content/en/security/automation_pipelines/mute.md

@@ -2,6 +2,16 @@
 title: Mute Rules
 aliases:
   - /security/vulnerability_pipeline/mute
+products:
+  - name: Cloud Security
+    url: /security/cloud_security_management/
+    icon: cloud-security-management
+  - name: Code Security
+    url: /security/code_security/
+    icon: security-code-security
+  - name: App and API Protection
+    url: /security/application_security/
+    icon: app-sec
 further_reading:
   - link: "/security/automation_pipelines"
     tag: "Documentation"
@@ -11,36 +21,38 @@ further_reading:
     text: "Prevent cloud misconfigurations from reaching production with Datadog IaC Security"
 ---
 
+{{< product-availability >}}
+
 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, **Compensating control in place for account payment-prod**.
-1. Use the following boxes to configure the rule criteria:
+1. In Datadog, go to **Security** > **Settings** > [Findings Automation][2]. Click **Add a New Rule**, then select **Mute**. The Create a New Rule page opens.
+1. Under **Rule name**, enter a descriptive name for the rule; for example, "Compensating control in place for account payment-prod".
+1. Add your rule criteria into the following fields:
     - **Any of these types**: The types of findings that the rule should check for. Available types include:
-      - **Runtime Code Vulnerability**
-      - **Static Code Vulnerability**
-      - **Library Vulnerability**
-      - **Secret**
-      - **Infrastructure as Code**
-      - **Container Image Vulnerability**
-      - **Host Vulnerability**
-      - **Misconfiguration**
-      - **Attack Path**
-      - **Identity Risk**
-      - **API Security**
+      - Runtime Code Vulnerability
+      - Static Code Vulnerability
+      - Library Vulnerability
+      - Secret
+      - Infrastructure as Code
+      - Container Image Vulnerability
+      - Host Vulnerability
+      - Misconfiguration
+      - Attack Path
+      - Identity Risk
+      - API Security
     - **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**
-      - **Other**
-    - **Rule expiration**: The date on which the rule expires. 
+      - 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**. The rule applies to new findings immediately and starts checking existing findings within the next hour.
 

content/en/security/automation_pipelines/security_inbox.md

@@ -2,6 +2,16 @@
 title: Add to Security Inbox Rules
 aliases:
   - /security/vulnerability_pipeline/security_inbox
+products:
+  - name: Cloud Security
+    url: /security/cloud_security_management/
+    icon: cloud-security-management
+  - name: Code Security
+    url: /security/code_security/
+    icon: security-code-security
+  - name: App and API Protection
+    url: /security/application_security/
+    icon: app-sec
 further_reading:
   - link: "/security/security_inbox"
     tag: "Documentation"
@@ -15,21 +25,23 @@ further_reading:
   Add to Security Inbox Rules is in Preview.
 {{< /callout >}}
 
+{{< product-availability >}}
+
 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
 
-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. Use the following boxes to configure the rule criteria:
+1. In Datadog, go to **Security** > **Settings** > [Findings Automation][2]. Click **Add a New Rule**, then select **Add to Security Inbox**. The Create a New Rule page opens.
+1. Under **Rule name**, enter a descriptive name for the rule; for example, "Cloud Infrastructure Anomaly Warnings".
+1. Add your rule criteria into the following fields:
     - **Any of these types**: The types of findings that the rule should check for. Available types include:
-      - **Misconfiguration**
-      - **Attack Path**
-      - **Identity Risk**
-      - **Runtime Code Vulnerability**
-      - **Library Vulnerability**
-      - **Container Image Vulnerability**
-      - **Host Vulnerability**
+      - Misconfiguration
+      - Attack Path
+      - Identity Risk
+      - Runtime Code Vulnerability
+      - Library Vulnerability
+      - Container Image Vulnerability
+      - 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.

content/en/security/automation_pipelines/set_due_date.md

@@ -1,30 +1,42 @@
 ---
 title: Set Due Date Rules
+products:
+  - name: Cloud Security
+    url: /security/cloud_security_management/
+    icon: cloud-security-management
+  - name: Code Security
+    url: /security/code_security/
+    icon: security-code-security
+  - name: App and API Protection
+    url: /security/application_security/
+    icon: app-sec
 further_reading:
   - link: "/security/automation_pipelines"
     tag: "Documentation"
     text: "Automation Pipelines"
 ---
 
+{{< product-availability >}}
+
 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
 
-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:
+1. In Datadog, go to **Security** > **Settings** > [Findings Automation][2]. Click **Add a New Rule**, then select **Set Due Date**. The Create a New Rule page opens.
+1. Under **Rule name**, enter a descriptive name for the rule; for example, "Cloud Infrastructure Anomaly Warnings".
+1. Add your rule criteria into the following fields:
     - **Any of these types**: The types of findings that the rule should check for. Available types include:
-      - **Runtime Code Vulnerability**
-      - **Static Code Vulnerability**
-      - **Library Vulnerability**
-      - **Secret**
-      - **Infrastructure as Code**
-      - **Container Image Vulnerability**
-      - **Host Vulnerability**
-      - **Misconfiguration**
-      - **Attack Path**
-      - **Identity Risk**
-      - **API Security**
+      - Runtime Code Vulnerability
+      - Static Code Vulnerability
+      - Library Vulnerability
+      - Secret
+      - Infrastructure as Code
+      - Container Image Vulnerability
+      - Host Vulnerability
+      - Misconfiguration
+      - Attack Path
+      - Identity Risk
+      - API Security
     - **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 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.