Sentinel — Remediation Workflow

Sentinel is BleedWatch's autonomous security agent. It runs scheduled scan cycles across your attack surface, detects security findings, and orchestrates their remediation through pull requests, runbooks, and team assignments — with a complete audit trail for compliance.

How Sentinel Works

1. Scans your attack surface on a configurable schedule (domains, repositories, IP ranges, container registries)
2. Detects findings using open-source scanner tools (Trivy, Nuclei, Grype, Semgrep, and others)
3. Creates fix PRs or runbooks for each finding
4. Tracks remediation through a structured status lifecycle
5. Verifies fixes by re-scanning after remediation
6. Reports results with risk scores and executive summaries

Finding Status Lifecycle

Every Sentinel finding follows this lifecycle:

Open → Triaged → Remediation In Progress → Pending Verification → Resolved

Status	Meaning
Open	A new finding detected — no action taken yet
Triaged	Reviewed and assessed for priority
Remediation In Progress	A team member is actively working on the fix
Pending Verification	The fix is implemented and awaiting automated re-scan
Resolved	Verification confirms the vulnerability is gone
Reopened	A previously resolved finding was detected again
Won't Fix	A deliberate decision not to remediate (requires justification)
False Positive	The finding was determined to be incorrect

note

Never skip the Pending Verification step. It confirms the fix actually removed the exposure via automated re-scan. Moving directly from "In Progress" to "Resolved" bypasses this safety check.

Pull Request Linking

Sentinel can automatically create and track pull requests linked to findings.

Automatic PR Creation

When Sentinel detects a finding it can fix programmatically, it creates a pull request in your repository with:

• A branch following the naming convention bleedwatch/fix/{findingId}
• A description explaining the finding and the fix
• A self-scan validation to verify the fix addresses the issue

Merge Strategies

Configure how Sentinel handles fix PRs in Sentinel → Config:

Strategy	Behavior
Propose Only	Creates the PR but takes no further action
Propose + Assign Reviewer	Creates the PR and assigns your configured default reviewers
Auto-Merge Low Severity	Low-severity fixes that pass self-scan and CI are automatically merged

Safety Limits

To prevent overwhelming your repositories, Sentinel enforces:

• Maximum PRs per scan cycle (default: 10)
• Maximum commits per day (default: 50)
• Blocked file patterns — CI/CD configs, Dockerfiles, and shell scripts are never modified automatically

Linking Existing PRs

If you've already created a fix PR manually, you can link it to a finding from the finding detail page. Sentinel will then track its lifecycle (draft → open → CI → merged → closed) and trigger verification after merge.

Runbooks

For findings that cannot be fixed via code changes (e.g., DNS misconfigurations, exposed ports, infrastructure issues), Sentinel generates a runbook — a step-by-step remediation guide committed to your repository.

Runbooks are versioned and updated as conditions change.

Assignment and SLA

Assigning Findings

Each finding can be assigned to a team member. You can:

• Assign individual findings from the finding detail page
• Bulk-assign multiple findings from the findings list
• Add client notes for internal context

Routing Rules

Configure automatic routing in Sentinel → Routing to dispatch findings based on severity and type:

• Route critical findings to Slack immediately
• Route vulnerability findings to Jira for tracking
• Set different SLA deadlines by severity

SLA Enforcement

Each routing rule can define an SLA deadline:

Severity	Typical SLA
Critical	24 hours
High	72 hours
Medium	7 days
Low	30 days

When an SLA deadline passes without resolution, Sentinel logs an escalation event and sends a notification to the assigned team member.

Verification

When a finding moves to Pending Verification, Sentinel triggers a re-scan of the affected asset:

1. If the re-scan confirms the issue is gone → finding moves to Resolved
2. If the issue persists → finding is Reopened with a notification to the assignee

The verification delay is configurable (default: 24 hours after remediation) to allow changes to propagate.

Observation Mode

When first activated, Sentinel starts in Observation Mode:

• All alerts are routed only to the primary contact for validation
• No automated PRs are merged
• No actions are taken against repositories

This allows your team to validate that scan results are accurate before enabling full autonomous operation. Observation mode can be toggled off at any time from Sentinel → Config.

Integrations

Configure notification channels in Sentinel → Integrations. Each channel can be targeted by routing rules (see Routing Troubleshooting when things misfire).

Channel	Connection	Dedicated guide
Slack	Webhook URL	—
Microsoft Teams	Webhook URL	—
Jira	OAuth (shared app)	Jira integration
Linear	OAuth (shared app)	Linear integration
ServiceNow	OAuth (per-tenant app)	ServiceNow integration
Generic Webhook	HTTP endpoint + HMAC-SHA256	—

For the full picture of how channels and routing rules fit together, see Integrations → Overview.

Risk Score

Sentinel computes a risk score (0–100) for your organization based on open findings, severity distribution, and remediation velocity. The score is tracked over time so you can measure improvement across scan cycles.

Reports

Cycle Reports

Each scan cycle produces a summary: new findings discovered, findings resolved, PRs created, and risk score change.

COMEX Executive Report

A weekly executive summary (auto-sent Mondays at 08:00 UTC) with risk score trends, top findings, and remediation metrics. Can also be generated on demand from Sentinel → Reports.

SBOM Export

Download your Software Bill of Materials in SPDX JSON or CycloneDX JSON format for supply chain compliance.

Activity Feed

Every Sentinel action is recorded in a tamper-evident audit log accessible from Sentinel → Activity:

• Scan cycle events (started, completed, failed)
• Finding events (created, updated, resolved, reopened)
• PR events (created, merged, closed)
• Alert and SLA events
• Configuration changes

Configuration

Key settings available in Sentinel → Config:

• Scan scope — Domains, repositories, IP ranges
• Scan schedule — Daily, weekly, every 12h, every 6h
• Scanner stack — Toggle individual scanners (Trivy, Nuclei, Grype, Semgrep, etc.)
• Kill switch — Immediately disable all scanning
• Merge strategy — Propose only / Propose + assign / Auto-merge low
• Report language — French or English
• Report level — Technical or Executive
• Primary contact — Name and email for the responsible security contact
• Maintenance windows — Periods when scanning should be paused

Troubleshooting

Findings Not Resolving After Fix

If a finding stays in Pending Verification longer than expected:

1. Check that the fix PR was actually merged
2. Verify the verification delay hasn't been set too high (default: 24 hours)
3. Check Sentinel → Activity for verification events — look for "verification-failed" entries

Too Many PRs

If Sentinel creates more PRs than your team can review, reduce the maximum PRs per cycle in Sentinel → Config or switch to Propose Only merge strategy.

Scan Cycle Failing

Check Sentinel → Activity for error events. Common causes include expired repository access tokens or misconfigured scan scope.