# Sentinel: repo security

# Sentinel: repo security

Sentinel is inline's repository security monitor. It continuously watches your dependencies for known vulnerabilities and malicious packages, **confirms** each candidate with an agent that actually reads your code before it alerts you, and ingests GitHub's own security alerts into one place. Confirmed issues can flow straight into a [remediation PR](./security-autofix.html).

It's an optional per-repo module, off by default.

## What it scans for

- **Dependency vulnerabilities** — your exact lockfile dependencies are range-matched against public advisory data for npm and NuGet (every manifest listed under fingerprinting below). This is the primary signal.
- **Malicious packages** — exact-name matches against a curated malicious-package feed. Always `critical`.
- **Dependency fingerprinting** — dependencies are resolved from lockfiles first (`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `packages.lock.json`), then from project manifests (`package.json`; `.csproj` / `.fsproj` / `.vbproj`, `Directory.Build.props`, `Directory.Packages.props` for central package management, and legacy `packages.config`) and hashed, so an unchanged manifest is skipped without re-matching.
- **Threat news** — a web sweep surfaces relevant security news (informational, not code-specific).
- **GitHub-native alerts** — Dependabot, code-scanning, and secret-scanning alerts are **ingested** via webhooks (opt-in) and stored pre-confirmed, with secrets always `critical`.

Sentinel does not run its own SAST or secret scanner — it leans on public advisory data, the malicious feed, and GitHub's native scanners.

## Fresh vulnerability data

Sentinel keeps its vulnerability data current on a schedule: security advisories (npm + NuGet), critical and high CVEs, the threat-news sweep, and the malicious-package feed. Advisory matching is queried live at match time, so you're always matched against the latest data.

## Agentic confirmation

The point of Sentinel is **low noise** — a raw "you depend on a package with a CVE" is often a false positive because your code never hits the vulnerable path. So every candidate is confirmed by an agent that explores the repo (read-only, pinned at a commit, plus web search) and returns a verdict — `affected`, `not_affected`, or `needs_attention` — with file/line evidence and remediation.

Confirmation is tiered for cost: a cheap fast model triages every candidate, a more capable model does the deep read only when a candidate looks serious or the first pass wasn't confident, and a frontier model is reserved for still-ambiguous high/critical cases. Advisories for the same package share one repo exploration, so cost tracks the *number of distinct packages*, not the number of advisories. A confirmed high/critical fires an alert immediately.

## Alerts

Each alert carries its match type (`range` / `malicious` / `news` / `dependabot` / `code-scan` / `secret-scan`), a stable fingerprint, a status (`new → assessing → confirmed / not_affected / dismissed / resolved`), and — once assessed — the verdict, summary, evidence, and confidence. Manage them under **Security → Alerts** in the portal; the **Threat feed** shows the news sweep, and **Fixes** shows remediation runs with live progress.

## From alert to fix

A confirmed, fixable alert can open a remediation PR automatically or on demand — see **[Security auto-fix](./security-autofix.html)**. Secret-scanning alerts are excluded from auto-fix (they need rotation, not a code change).

## Setup

Enable per repo under **Security → Overview**, set the **Severity threshold**, and optionally turn on **Native alerts** to ingest GitHub's scanners.

**GitHub App permissions:** Security events: read (for native alerts), plus Contents: write and Pull requests: write if you want [remediation PRs](./security-autofix.html). **Webhook events:** `dependabot_alert`, `code_scanning_alert`, `secret_scanning_alert`.

Confirmed alerts can also notify [Microsoft Teams and email](./notifications.html).