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.
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.propsfor central package management, and legacypackages.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. 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. Webhook events: dependabot_alert, code_scanning_alert, secret_scanning_alert.
Confirmed alerts can also notify Microsoft Teams and email.