Security auto-fix

When Sentinel confirms a vulnerability, inline can open a remediation pull request — bumping the vulnerable dependency or patching the code — verified in a sandbox before it’s raised. It’s the security counterpart to review auto-fix.

# What it fixes

Fixable alert types: dependency range matches, malicious packages, ingested Dependabot alerts, and code-scanning alerts. Secret-scanning alerts are excluded — a leaked secret needs rotation, not a patch.

# Triggers

• Manual — “Create fix” on an alert in the portal.
• Automatic — when Fix mode is set to automatic and a newly confirmed (or newly opened native) alert meets the severity threshold, the dependency-only rule, and the open-PR cap.

Each fix run atomically claims the alert, so two runs never race to open duplicate PRs.

# Two strategies

The fix job runs in a sandbox and picks the safest route:

1. Deterministic bump — when the patched version is known and the dependency is direct, inline just runs the package manager’s add command (npm / pnpm / yarn) at the fixed version. No model, no guesswork.
2. Agentic patch — otherwise a frontier-model loop upgrades, adds overrides/resolutions, removes a malicious package, or sanitizes vulnerable code — aiming for the minimal blast radius.

# Verify, then repair

Per the monitor’s Verification setting (none / build / full), inline plans a verification run, installs with the same fallback chain as the test sandbox, and runs it. If verification fails, it re-invokes the agent in repair mode for a couple of rounds. If it still fails, no PR is opened — inline won’t hand you a broken fix.

# Convention-matched branches

inline matches your team’s branch naming. It reads recent branches and merged-PR heads to infer a prefix (hotfix/, bugfix/, fix/…), caches the convention, and names the branch accordingly. Base branch, draft state, and PR labels are all configurable on the monitor.

On success the alert moves to awaiting_review with the PR linked.

# Live progress

Every phase (queued → cloning → analyzing → patching → verifying → repairing → pushing → opening_pr → done) streams live to Security → Fixes in the portal, and to Teams/email if configured.

# Configuration

On the repo’s security monitor:

Requires the GitHub App to have Contents: write (to push the branch) and Pull requests: write. Each run has a bounded time and cost budget and a fixed number of repair rounds.