Remediation¶

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

The life of a finding¶

A finding leaves the list in three ways, and each one comes back differently. Solid arrows are what you do. Dotted arrows are what happens without you.

%%{init: {"flowchart": {"curve": "basis", "nodeSpacing": 55, "rankSpacing": 110, "wrappingWidth": 420}}}%%
flowchart LR
    scan(["a scan finds the<br/>vulnerable version"]) --> open

    open["<b>Open in the list</b><br/><i>assigning it starts the clock,</i><br/><i>it stays here either way</i>"]

    open -->|"Snooze<br/>until a date you pick"| snz["<b>Snoozed</b>"]
    snz -.->|"the date passes"| open

    open -->|"Risk exception<br/>reason, end date optional"| acc["<b>Risk accepted</b><br/>out of the list,<br/>still in the VEX export"]
    acc -.->|"the end date passes<br/><i>never, if you left it empty</i>"| open

    open -->|"Mark as fixed"| fix["<b>Marked fixed</b><br/>your claim,<br/>not a fact yet"]
    fix -.->|"next scan still sees it"| open
    fix -.->|"next scan agrees"| res

    open -.->|"next scan no longer sees it"| res["<b>Resolved</b>"]
    res -.->|"rollback, reinstall,<br/>a new machine reports it"| open

Three things in that picture are worth saying out loud.

Assignment is not a state. It starts the deadline clock and it puts a name on the row. It does not move the finding anywhere, and unassigning does not either.

Snooze and Risk exception run out on their own, when you gave them a date. Nothing renews them, and the finding reappears in the list when the date passes. A risk acceptance that has expired is not an acceptance any more, which is the behaviour an auditor expects, though an administrator can reactivate it by hand.

The exception is a risk acceptance saved with no date, which the form allows and which never comes back on its own.

Mark as fixed is a claim, not a result. The next scan settles it. If the vulnerable version is still installed, the finding comes straight back, and that round trip is visible in the audit trail. This is the difference between Mark as fixed and Snooze that matters at audit time.

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. On the dashboard, find the CVE row.
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).

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.

Creating a policy¶

On the dashboard, the line above the list says SLA: not set · Set up, or SLA: ... · Edit once policies exist. That is the way in: Configure SLA Policies is the title of the window that opens, not a button to look for.

Create one policy per severity you want to track. A policy has:

Policies are per organization. There is no separate exploited and not-exploited deadline: severity is the only axis, so if you want exploited CVEs treated more urgently, that has to come from how severity is assigned, not from the policy.

A starting point¶

These are not defaults, and nothing creates them for you. They are the exploited-vulnerability compliance windows, which are a reasonable baseline to type in:

What happens at the deadline¶

A daily job at 08:00 checks assignments against their policy and sends a digest of the ones that have crossed it. It goes to the organization's admins, plus the policy's escalate_to address when set, and each breach is only mailed once rather than re-sent every morning until it is fixed.

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: nothing. The integration is one-way.

Setup¶

1. Integrations → Issue Trackers → click your tracker.
2. Authenticate with an API token (Jira Cloud, GitHub, GitLab, YouTrack) or a personal access token (Jira Server/Data Center). There is no OAuth flow.
3. Pick the default project/repo for new issues.
4. Optional: map SentriKat severity → tracker priority.
5. Save.

Test by opening a finding and clicking Create issue.

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: The daily 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, the SLA deadline if you have a Critical policy, and a summary naming the CVE and the affected package.
3. Assignment: someone triaging the new findings assigns it to the backend team. Assignment is manual: there are no auto-assignment rules.
4. Notification: the assignee gets an email.
5. Work: developer bumps express to 4.19.1 and merges the PR. CI re-runs SentriKat dependency scanning.
6. Resolve: the next scan no longer finds the vulnerable version and SentriKat marks the finding resolved. The Jira issue stays open until someone closes it: the integration does not push closures back.
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¶

• Risk Exceptions, accept-the-risk workflow
• Issue Trackers, deep dive on tracker config
• Remediation API, programmatic access