# Security auto-fix

# Security auto-fix

When [Sentinel](./sentinel.html) confirms a vulnerability, inline can open a **remediation pull request** — bumping the vulnerable dependency or patching the code — verified in a [sandbox](./sandbox.html) before it's raised. It's the security counterpart to [review auto-fix](./auto-fix.html).

## 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](./sandbox.html#install-resilience) 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:

| Setting | Meaning |
| --- | --- |
| **Fix mode** | Off / manual / automatic. |
| **Fix severity threshold** | Minimum severity for automatic fixes. |
| **Verification** | None / build / full check before opening a PR. |
| **Dependency-only** | Only fix dependency issues automatically. |
| **Max open fix PRs** | Cap on concurrent open fix PRs. |
| **Base / target branch** | Where the PR is based and targeted. |
| **Draft PR / labels** | Open as draft; labels to apply. |

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.