Skip to content

Auto-Ticket Rules

Auto-ticket rules create remediation tickets automatically when specific trigger conditions are met. No manual intervention is required. When a new KEV entry matches your assets at 2 AM, a ticket is already created and waiting for your team by the time they start their shift.

Setting Up a Rule

Navigate to Integrations > Ticketing > Add Rule.

Fill in the rule configuration:

Name (required): A descriptive name for the rule. Examples: "Critical KEV to OT Jira", "High findings to email", "Weaponized exploits to PagerDuty".

Environment (required): Which environment triggers this rule. Select a specific environment or "All Environments" to apply the rule across your entire organization.

Trigger Event (required): What event causes the rule to fire:

Trigger Fires When
kev.new A new KEV entry matches an asset in the selected environment
cve.critical A new CRITICAL severity CVE (CVSS 9.0+) matches an asset
cve.high A new HIGH severity CVE (CVSS 7.0+) matches an asset
exploit.confirmed A public exploit is confirmed for a CVE matching your assets
asset.matched Any new CVE matches an asset (any severity)

Severity Floor (optional): Minimum CVSS or BCS score to trigger. Example: set to 8.0 to only create tickets for findings with BCS 8.0 or higher, even if the trigger event is cve.high.

Destination Type (required): Where the ticket is sent:

  • Email: Sends to a specified email address.
  • Jira: Creates an issue in a connected Jira project.
  • ServiceNow: Creates an incident in a connected ServiceNow instance.

Destination Configuration: Fill in the destination-specific details (email address, Jira project and issue type, ServiceNow assignment group).

Default Assignee (optional): Pre-assign all tickets from this rule to a specific person or team.

Click Save Rule.

Example Rules

Rule 1: Immediate KEV Alerting via Email

  • Name: KEV matches to OT ops
  • Environment: All Environments
  • Trigger: kev.new
  • Severity Floor: None (all KEV matches regardless of CVSS)
  • Destination: Email to [email protected]

Creates an email ticket every time a KEV entry matches any asset in any environment. This is the single most important auto-rule for most operators.

Rule 2: Critical Findings to Jira

  • Name: Critical CVEs to Jira OT board
  • Environment: Water Treatment Plant Alpha
  • Trigger: cve.critical
  • Severity Floor: 9.0
  • Destination: Jira, project OT-SEC, issue type Bug
  • Default Assignee: [email protected]

Creates a Jira issue for every new critical CVE match in the water treatment plant. The OT security team sees it on their Jira board immediately.

Rule 3: Exploit Confirmation to PagerDuty

  • Name: Exploits to PagerDuty
  • Environment: All Environments
  • Trigger: exploit.confirmed
  • Destination: Email to [email protected]

Sends a PagerDuty alert (via email integration) when an exploit drops for any CVE matching your assets. This can wake someone up for an emergency if your PagerDuty routing is configured for high-urgency incidents.

Rule 4: All High+ Findings to ServiceNow

  • Name: High+ findings to ServiceNow
  • Environment: Substation Beta
  • Trigger: cve.high
  • Severity Floor: 7.0
  • Destination: ServiceNow, assignment group: Network Security

Creates a ServiceNow incident for every high or critical CVE match in the substation environment.

Managing Rules

Navigate to Integrations > Ticketing to see all your auto-ticket rules.

Each rule shows: name, environment, trigger, destination, and whether it is enabled.

  • Enable/Disable: Toggle a rule on or off without deleting it. Disabled rules do not fire.
  • Edit: Modify any field on an existing rule.
  • Delete: Permanently remove the rule.
  • Test: Click the test button to simulate the rule and verify the destination receives a test ticket.

Rule Execution

When a trigger event occurs:

  1. The matching engine detects the event (new KEV match, new critical CVE, etc.).
  2. All applicable rules are evaluated.
  3. For each matching rule, a ticket is created in BreachSpider and sent to the configured destination.
  4. The ticket creation is logged in the audit log as TICKET_CREATED with source: auto-rule.

If multiple rules match the same event, multiple tickets may be created. Design your rules to avoid overlap if you want one ticket per event.

Auto-Rules and Manual Tickets

Auto-rules and manual tickets coexist. An auto-rule may create a ticket for a finding, and you can also manually create an additional ticket for the same finding with a different destination or assignee. Both appear in the Tickets tab.