Skip to main content

Generate Tickets Without Sprints

This article details how to generate tickets using automation and without the use of sprints. While this article specifically focuses on generating vulnerability tickets, you can also generate tickets for other findings, such as dynamic code findings, open source findings, pentest findings, and more.

Create tickets using automation

Users with the Configurator or System Administrator role can create a new automation that generates tickets. To do so, follow these steps:

  1. Navigate to Automation.

  2. Click Create and fill in the following fields:

    • Title: The title of the automation.

    • Description: The description of what the automation accomplishes.

    • BQL query: The BQL query that determines the findings that are included in the ticket. For example:

      FIND Vulnerability AS v
      WHERE v.status = "Confirmed active"
      AND v.severity = "Critical"`

      Click Test to check if your query is valid and returns any data.

      warning

      Avoid using "Finding" in the BQL query. Instead, choose a data model that extends the "Finding" model, such as Alert, Manual finding, Pentest finding, Violation, Vulnerability, etc. If you create an automation for generating tickets and use "Finding" in the BQL query, it will not work as intended and will result in tickets being created with empty counts.

    • Actions: The action that the automation performs. Since we used "Vulnerability" in our BQL query, click the drop-down and select Create vulnerability ticket without sprints. The options for the "Create vulnerability ticket without sprints" action are as follows:

      • SLA: The SLA definition to associate with the ticket. You have two options:

        • Default finding SLA definition: The SLA starts from the date that the findings are initially identified.

        • Default ticket SLA definition: The SLA starts when the ticket is created

        See Service-level agreements for additional information.

      • Grouping: Grouping consolidates tickets by grouping similar findings into a single, all-inclusive ticket. This means that each group of similar findings, as determined by the BQL query and grouping criteria, results in one ticket, as opposed to generating individual tickets for every separate finding returned by the query. This approach is beneficial when the same solution can be applied across multiple assets. Click the drop-down and indicate how you want the findings to be grouped. Figure 2 illustrates some of the common uses of groupings:

        • Vulnerabilities with the same solution (Type): This grouping is often used when dealing with multiple vulnerabilities that share the same solution. These are grouped by type, risk rating, or owner.

        • Vulnerabilities discovered on the same asset (Target): This grouping is often used when numerous vulnerabilities are found on the same asset, such as a specific laptop or server. These are grouped by target, risk rating, or owner.

        Common ticket groupings

        Figure 1. Common ticket groupings

      • Assignment policy: Select a default owner. You can assign it to a specific user, assign it based on an attribute, or leave it unassigned.

      • Continue adding new findings to open tickets for as long as this condition is met: (Optional) Configure the automation to determine, based on the specified condition, if newly found vulnerabilities should create a new ticket or be added to an existing open ticket. If a new finding emerges when this condition is true, it is added to the existing ticket. If not, a new ticket is generated.

    • Run: Choose a method for the automation to run. You can run the automation manually, set a schedule for the automation to run, or you can set it to run when your data orchestration runs.

  3. Click Create.

The Automations page reloads and the new automation appears in the list view. See launch the automation and view the generated tickets for details on running the ticket automation and viewing tickets generated by the automation.

Launch the automation

Once you've created your automation, you can run the automation and view the tickets generated by it. Running the automation uses your BQL query to identify the vulnerabilities or findings that should be included in the tickets. To launch the automation, follow these steps:

  1. Navigate to Automation.

  2. Hold the pointer over the automation you want to run, and then click Run.

  3. Click Confirm when prompted.

Upon confirmation, the automation initiates the ticket generation process. It uses your BQL query to identify matching findings and depending on your specified grouping settings, the findings are categorized and grouped into tickets.

View the generated tickets

After your automation runs successfully, you can then view the tickets generated by the automation. To do so, follow these steps:

  1. Navigate to Remediation > Tickets > All.

  2. Use the filters to zero in on the tickets generated by your automation.

    For instance, you can use the Assigned filter to display only the tickets assigned to the owner specified when you created the automation. Similarly, the Created by filter displays tickets by a particular user. Click on the "Date created" column header to sort tickets by their creation date.

  3. Hold the pointer over one of the tickets and click Details to view information about a specific ticket.

These details may include a summary and description of the vulnerability, recommendations on how to address the vulnerability, open and closed vulnerabilities, assignment information, risk and SLA information, and more.

Tutorial: Generate tickets on critical vulnerabilities using automation

This tutorial demonstrates the process of creating an automation for generating tickets without sprints, from defining your BQL query, to assigning tickets, and setting the automation run schedule. While this guide specifically focuses on generating vulnerability tickets, you can also generate tickets for other findings, such as dynamic code findings, open source findings, pentest findings, and more. You may want to create such an automation for the following reasons:

  • Vulnerability management: Enable real-time tracking and management of critical vulnerabilities. This can help ensure prompt and effective remediation.

  • Risk prioritization: Tickets are generated for only active and critical vulnerabilities. This can let your team focus on the most pressing issues first.

  • Efficient remediation: Ensure that your remediation efforts are not delayed or overlooked. This can boost the overall efficiency of your vulnerability response processes.

To create an automation that generates tickets for active, critical vulnerabilities without sprints, follow these steps:

  1. Navigate to Automation.

  2. Click Create and fill in the following fields:

    • Title: Type "Generate active and critical vulnerability tickets".

    • Description: Type "This automation generates tickets for critical vulnerabilities".

    • BQL query: Type the following (BQL) query to find all active vulnerabilities with a critical risk rating in your data. Click Test to ensure that the query is valid and returns the expected data:

      FIND Vulnerability AS v
      WHERE v.riskRating = "Critical"
      AND v.status = "Confirmed active"
    • Actions: Click the Select an action drop-down, and select Create vulnerability ticket without sprints. More options appear below.

      • SLA: Select an SLA definition to associate with the tickets. For example, Default ticket SLA definition, where the SLA starts when the ticket is created or Default finding SLA definition, where the SLA starts from the date that the findings are initially identified. See Service-level agreements for additional information.

      • Grouping: Click the drop-down and select Type > Name and Type > Risk rating. This groups the vulnerabilities by their name and risk rating levels.

      • Assignment Policy: Click the drop-down and select a default owner. You can assign it to a specific user, assign it based on an attribute, or leave it unassigned.

      • Continue adding new findings to open tickets for as long as this condition is met: (Optional) Enter a BCL condition that determines whether an existing open ticket should accept new findings or if a new ticket should be created. This condition is applied to the tickets, not the findings. For example, the BCL could be:

        dateCreated IN LAST 1 week

        In this case, any new vulnerabilities are added to tickets that were created within the last week.

    • Run: Choose a method for the automation to run. You can run the automation manually, set a schedule for the automation to run, or you can set it to run when your data orchestration runs.

  3. Click Create.

The Automations page reloads and the new automation appears in the list view. See launch the automation and view the generated tickets for details on running the ticket automation and viewing tickets generated by the automation.