Skip to main content

Generate Tickets Using Automation

You can generate tickets in the Brinqa Platform using automation, with or without the use of sprints. While most of the examples in the documentation focus on generating vulnerability tickets, you can also generate tickets for other types of findings, such as dynamic code findings, open source findings, pentest findings, and more.

The key difference between generating tickets with and without sprints is how findings are managed and tracked over time. Choosing between the two models depends on your organization’s workflows and how you prefer to structure remediation efforts.

To get started, choose the model that best fits your needs:

Comparing tickets with and without sprints​

When you generate tickets with sprints, the process is organized around time-boxed iterations, or sprints, which typically cover a week or two weeks, where a specific set of vulnerabilities or findings are addressed. At the end of each sprint, unresolved issues and new findings discovered during the sprint are moved to a backlog ticket and a new sprint begins with a fresh set of tickets. This approach provides a structured way to manage vulnerability remediation and can help you understand your remediation performance over time.

Unlike the sprint model, when you generate tickets without sprints, findings do not move cyclically between a backlog and a sprint. Instead, every finding either belongs to an active ticket or is queued for the next ticket. This approach eliminates backlog management seen in ticketing with sprints. Although these tickets are not bound by sprint timeframes, they still adhere to the timelines established by their respective Service-level Agreement (SLA) due dates.

When new findings emerge, they are not added to existing tickets by default. Instead, a new ticket is generated, ensuring that each ticket accurately represents its corresponding findings. Additionally, if a finding associated with a closed ticket reopens, it moves into a new ticket, providing a straightforward way of tracking reopened issues. However, there's an option to add findings to existing tickets based on a condition. See the Continue adding new findings to open tickets section in step 2 of the Create tickets without sprints tutorial for additional information.

Ticket closing​

In the Brinqa Platform, the life cycle of a ticket generated using automation is directly tied to the vulnerabilities or findings associated with that ticket. In other words, a ticket remains in an "open" state as long as it has associated findings that need addressing. Tickets in the Brinqa Platform are not manually deleted but rather they reach a "closed" status. Tickets can reach a "closed" status for the following reasons:

  • Resolution of findings: Once all of the findings tied to a specific ticket have been resolved, the ticket doesn't close immediately. Instead, it's marked for closure, and upon the next run of the automation, if the system confirms that all the findings tied to a specific ticket have been resolved, that ticket is then closed. This process ensures that the ticket status accurately reflects the current state of associated findings.

  • BQL criteria: The Brinqa Query Language (BQL) query is written to determine the findings or vulnerabilities that are included in the ticket(s). If the associated findings or vulnerabilities no longer match the BQL criteria of the automation created, they can be removed, and the ticket is then closed.

    For example, suppose you have a BQL query that identifies critical vulnerabilities with a patch available:

    FIND VulnerabilityDefinition AS v
    WHERE v.severity = "Critical"
    AND v.patchAvailable EXISTS

    If a vulnerability initially matches this criteria and is included in a ticket, but later its severity is downgraded (e.g., to 'critical' or 'high'), it no longer matches the BQL criteria. As a result, the automation removes this vulnerability from the ticket. If all vulnerabilities associated with the ticket are removed because they no longer meet the criteria, the ticket is then closed.

This approach not only ensures comprehensive tracking of all identified vulnerabilities and their remediation status, but also maintains a clean, efficient, and structured way to manage the backlog of tickets. As a result, this makes the review of historical data and understanding your organization's vulnerability management performance over time easier and more accurate.

Last updated on