Security Vulnerability Scanner

A security vulnerability scanner in the build stage pairs static analysis with an LLM so that each pull request can surface OWASP-class issues with concrete, per-finding remediation. Tools in this class include Snyk AI, Semgrep with AI-assisted explanation, and similar SAST-plus-LLM products. The scanner does not replace security judgment. It flags candidates, cites evidence in the diff, and proposes fixes; a security engineer still triages severity, false positives, and merge risk.

The outcome is quality: fewer high-risk patterns reach mainline, and reviewers spend less time reconstructing why a finding matters. The primary reader is a security engineer reviewing PR findings, not the author alone. Authors may receive inline comments, but ownership of accept, suppress, or escalate remains with security (or a defined security-aware reviewer role).

Related build-stage work often sits nearby. Automated PR Review covers broader review quality. Agentic Feature Implementation may introduce new surfaces that this scanner should re-check. Codebase-Aware Code Completion can reduce insecure snippets earlier, but it does not substitute for a cited scan on the final diff.

On open or update of a pull request, the pipeline collects the changed files (and any required context such as dependency manifests or framework config). Static rules and taint/flow engines run first. The LLM layer then explains matches, maps them to OWASP-style categories when applicable (injection, broken access control, cryptographic failures, insecure design patterns visible in code, and similar classes), and drafts remediation steps tied to the exact hunk.

Each finding should carry at least: location (file, line or range), category or rule id, short rationale grounded in the cited code, severity suggestion, and a remediation sketch that a developer can apply without guessing. Prefer remediation that shows the unsafe pattern and a safer alternative in the same language and framework as the PR. Avoid generic advice that could apply to any codebase.

Scope the scan to the PR diff plus the minimum context needed for dataflow. Full-repo rescans on every push are usually too noisy for PR triage unless policy requires them for release gates. When the pipeline cannot obtain a usable diff, or the configured ruleset is missing or failed to load, the scanner must emit empty output rather than invent findings or invent a pass. Empty output is a signal to fix the job inputs, not a silent green check.

Do not treat LLM prose as a substitute for a rule or analyzer hit. If static analysis produced no match and the model only “suspects” a problem, either omit the finding or mark it clearly as speculative and out of band for merge blocking. Merge or CI failure should require a cited finding with a stable rule or analyzer identifier, not free-form suspicion.

Triage starts with the finding list sorted by suggested severity and by whether the change touches auth, input boundaries, secrets, crypto, or deserialization. For each item, confirm that the cited lines actually support the claim. Discard or downgrade matches that are unreachable, already mitigated by framework defaults, or outside the PR’s blast radius.

Ask three practical questions: Is the sink reachable from untrusted input in this change? Is the suggested fix correct for this stack? Would accepting the risk need an explicit exception with an owner and expiry? Document suppressions with rule id, path, reason, and reviewer. Prefer time-boxed exceptions over permanent silence.

Remediation steps are starting points. Rewrite them when the model proposes an API that the repo does not use, or when the fix would break intentional behavior (for example, a deliberate reflection path behind a strict allowlist). Push clarified guidance back into shared Semgrep or Snyk rules so the next PR gets a sharper signal instead of the same debate.

Coordinate with authors through the PR thread. Security owns the disposition (fix, accept risk, false positive). Authors own the patch. Avoid auto-blocking the PR unless a finding is present, cited, and mapped to a blocking policy. Soft-fail or comment-only modes are appropriate while tuning rules and false-positive rates.

Human-in-the-loop is mandatory for disposition. The scanner flags; security triages. Automation may open comments, label the PR, or fail a required check only when policy maps a cited finding to a blocking severity. Never fail a check solely because the model wrote cautionary text without a backing analyzer or rule hit.

Required inputs: a resolvable PR diff (or equivalent patch set) and a loaded ruleset or policy pack. If either is missing, corrupted, or timed out before analysis, return empty findings and surface a pipeline error distinct from “no vulnerabilities found.” An empty finding list with a successful ruleset load means no cited matches; an empty finding list with a missing ruleset means the job did not run.

Secrets and PII in diffs need care. Prefer redaction or path exclusion for known secret locations before sending hunks to an external LLM. Keep rule evaluation local when possible; send only the minimum snippet required for explanation. Log model prompts and responses under the same retention and access controls as other security tooling.

Do not auto-merge, auto-revert, or force-push remediations. Suggested patches belong in review comments or draft commits the author can accept. Blocking without a cited finding creates false confidence and trains teams to ignore the scanner.

This use case complements Automated PR Review: general review agents look for correctness and style; the vulnerability scanner specializes in security classes with OWASP-oriented framing and remediation. Keep the channels distinct so security noise does not bury functional review, and so security can filter by rule id.

When Agentic Feature Implementation lands large generated diffs, run the scanner on the final PR, not only on intermediate agent steps. Generated code often repeats the same insecure pattern across files; a single high-confidence rule hit with multi-location citations is more useful than dozens of near-duplicate comments.

Codebase-Aware Code Completion can steer authors away from banned APIs earlier. Treat completion guidance as prevention; treat this scanner as detection on the merged candidate. Shared allowlists and banned-API rules across completion and SAST reduce contradictory advice.

Feed confirmed false positives into rule tuning. Feed confirmed true positives with weak remediations into prompt or template updates for the LLM explanation layer. Over time, the useful metric is not raw finding count but time-to-triage and rate of findings that survive security review as real issues.

Adopt when pull requests regularly touch auth, parsers, file or network I/O, or dependency upgrades, and when security review is already a bottleneck on the critical path. Start in comment-only mode on a representative set of services. Promote specific rule ids to blocking only after false-positive rates are acceptable for those services.

Measure with operational signals you can collect without inventing benchmarks: share of PRs with at least one cited finding, median time from comment to disposition, false-positive rate among closed findings, and count of blocking failures that lacked a rule or analyzer citation (that count should stay at zero). Track empty-output job failures separately so missing diffs or rulesets are fixed as infrastructure bugs.

Success looks like security engineers spending review time on reachable, well-cited issues with actionable fixes, authors getting consistent remediation language, and the pipeline refusing to invent confidence when inputs are incomplete. The scanner accelerates detection; people still decide what ships.