Security Review as a Feedback Loop
Claude Code’s security-guidance plugin treats review as something that happens across a session, not as one verdict at the end. This chapter follows the plugin from fast pattern warnings through diff review and commit or push analysis. The key question is why the system needs baselines, changed-file selection, exact commit identity, deduplication, rate limits, and bounded iteration. The answer is that a review is a stateful feedback loop: it must know what changed, when it changed, what has already been reported, and when the cost of another model call is no longer justified.
Three layers see different snapshots
The first security-guidance layer is pattern matching. The plugin keeps named rules for recognizable hazards such as unsafe deserialization, command injection, XSS sinks, insecure TLS settings, and unsafe YAML or XML parsing. When a file is written or edited, the hook checks the path and the new content and can inject a brief warning. This layer is fast because it does not need to understand the whole repository or ask another model to reason about a change. It is also narrow by construction. A pattern can identify a dangerous form, but it cannot establish that every equivalent form is absent or that a matched form is exploitable in its surrounding context.
Path filters are part of that narrowness. A rule for a JavaScript shell call should not fire indiscriminately on prose, and a Python deserialization rule should apply to the relevant file types. The plugin’s pattern definitions use path checks, substrings, and regular expressions, and assign stable numeric identifiers to known rules for metrics. Those details make the layer measurable and tunable, but they do not turn pattern matching into a complete program analysis. The useful claim is “this edit resembles a known hazard,” not “this edit is secure after the warning is shown.”
The warning is most useful when it changes the next action. A developer who sees an unsafe deserialization reminder can replace the loader, constrain the input, or document why a deliberate exception is safe. A team can measure which pattern categories fire and whether they remain unresolved. But the stable rule identifier is a reporting aid, not evidence that the pattern was understood or fixed. The layer’s value lies in speed and repeatability: it puts a known concern in front of the person or agent while the edit is still easy to change.
The second layer reviews a diff when Claude finishes a turn. Rather than repeatedly sending the entire repository for analysis, the plugin captures a baseline at the user prompt and later inspects changes relative to that snapshot. The model sees a more coherent unit than one line: it can consider how a new function is called, whether validation is bypassed elsewhere in the diff, or whether a configuration change alters the meaning of code around it. This richer context costs more time and model usage than a regex check, so the scope must be bounded.
The third layer performs an agentic review for commits and pushes. The reviewer can read related files while tracing data flow, which is the kind of context needed for issues such as an authorization check that is separated from its use, an indirect server-side request, or a path-validation gap spread across modules. It is also the layer with the largest visibility and cost boundary. Reading related files can find relationships that a diff alone hides, but it sends more content to a model endpoint and depends on the repository being in a state the reviewer can interpret.
The three layers are complementary rather than sequential grades of the same test. A pattern warning is immediate and cheap.