Skip to content

Remediation

SentriKat turns vulnerability findings into actionable work items with assignments, SLAs, and native integration with your existing issue tracker.

Assignments

Every vulnerability finding can be assigned to a user or team. The assignment carries through to:

  • The vulnerability detail page in the SentriKat UI
  • The connected issue tracker (if enabled)
  • The SLA clock (see below)
  • Email and webhook notifications
  • Compliance reports (who is accountable for what)

Assigning from the UI

  1. Go to Vulnerabilities → find the CVE.
  2. Click the Assign button in the finding toolbar.
  3. Pick a user or team from the dropdown.
  4. Optional: add an assignment note (visible in the audit trail).
  5. Save.

The assignee gets an email notification immediately. If an issue tracker is connected for the product, a new issue is also created (or an existing one is updated).

Bulk assignment

From the vulnerability list, select multiple findings with the checkboxes and use the Bulk Assign action. Useful for mass- triaging a new batch of findings after a KEV publication.

Unassigning

Click Unassign on any assigned finding. The SLA clock stops but the history is preserved for audit.

SLA policies

SLA policies map the severity of a finding to a maximum time-to-fix. Exceeding the SLA triggers escalation.

Built-in policy (default)

Severity Time to fix Escalation
Critical (KEV) 14 days Email team lead + admin at day 10
Critical (non-KEV) 21 days Email at day 18
High 30 days Email at day 27
Medium 90 days Email at day 85
Low 180 days No escalation

This matches the CISA BOD 22-01 baseline for federal systems and is appropriate for most SMBs.

Custom policies

Admins can define custom SLA policies per organization or per product. Go to Admin → SLA Policies and create a new policy with your own severity → days mapping.

Use cases:

  • Stricter KEV policy for high-value products: Critical KEV = 7 days instead of 14.
  • PCI-DSS Req 6.3.3 alignment: Critical = 30 days, High = 30 days, Medium = 90 days (matches PCI-DSS v4.0 external scan remediation windows).
  • Relaxed policy for non-production environments: double all numbers.

SLA breach handling

When a finding crosses its SLA deadline:

  1. The finding is flagged BREACHED in the UI with a red badge.
  2. The assignee and their team lead get an email.
  3. The breach is logged in the audit trail.
  4. Compliance reports include the breach count in the "Overdue Findings" section.

Breached findings never auto-resolve; they require explicit closure with a resolution reason (fixed, mitigated, risk-accepted).

Issue tracker integration

SentriKat supports four issue trackers out of the box. One-click setup, two-way sync.

Supported trackers

  • Jira (Cloud + Server/Data Center)
  • GitHub Issues
  • GitLab Issues
  • YouTrack

What gets synced

From SentriKat → Tracker (push):

  • New finding → new issue created with summary, CVE link, severity, assigned component, and SLA deadline
  • Assignment change → tracker issue reassignment
  • SLA breach → tracker issue commented with "[SentriKat] SLA breached on YYYY-MM-DD"
  • Resolution → tracker issue closed with the resolution reason

From Tracker → SentriKat (pull):

  • Issue status change (open → closed) → finding auto-resolved
  • Issue comment with [sentrikat:accept] → finding flagged as risk-accepted (see Risk Exceptions)
  • Issue comment with [sentrikat:defer] → finding deferred with the note as the reason

Setup

  1. Admin → Integrations → Issue Trackers → click your tracker.
  2. Authenticate with OAuth (Jira/GitHub/GitLab) or API token (YouTrack).
  3. Pick the default project/repo for new issues.
  4. Optional: map SentriKat severity → tracker priority.
  5. Optional: enable two-way sync (unchecked = push-only).
  6. Save.

Test by opening a test finding and clicking Push to tracker.

Per-product overrides

If you have multiple products that live in different Jira projects (or different trackers entirely), override the default per product:

  1. Products → pick a product → Settings → Issue Tracker.
  2. Pick tracker + project.
  3. Save.

Workflow example

A typical flow from detection to closure:

  1. Detection: Daily KEV sync discovers a new Critical CVE affecting backend product's express dependency.
  2. Auto-create: A Jira issue INFRA-1234 is created with severity=Critical, SLA=14 days, summary="[KEV] CVE-2024-12345 in [email protected]".
  3. Assignment: SentriKat auto-assigns based on the backend → backend-team rule configured in Admin → Assignment Rules.
  4. Notification: backend-team lead gets an email.
  5. Work: developer bumps express to 4.19.1 and merges the PR. CI re-runs SentriKat dependency scanning.
  6. Auto-resolve: next scan no longer finds the vulnerable version; SentriKat marks the finding resolved; Jira issue auto-closes.
  7. Audit: the compliance report for this quarter shows time-to-fix=3 days for CVE-2024-12345.

Reporting

Every Remediation workflow fuels the compliance reports:

  • NIS2 Article 21: aggregate time-to-fix by severity
  • PCI-DSS Req 6.3.3: external vulnerability scan remediation within 30 days
  • ISO 27001:2022 Annex A.8.8: management of technical vulnerabilities
  • SOC 2 CC7.1/CC7.2: vulnerability management lifecycle evidence

See Compliance Reports for the full list.

See also