Security scanning and code review have historically lived in different places in the development lifecycle. Code review happens in the PR. Security scanning — SAST, dependency vulnerability checking, secrets detection — typically runs as a separate CI job that produces a separate report, often in a separate interface that developers have to consciously go check. The operational consequence of this separation is well-documented: findings that require a context switch out of the review workflow get addressed at lower rates than findings that appear inline in the code the developer is already looking at.
Embedding security pattern detection in the PR review loop — inline in the diff, posted as suggestions alongside style and convention findings — is a different approach. It doesn't replace dedicated security scanning pipelines. It changes where and when certain categories of security findings surface to the developer.
What categories belong in the review loop
Not all security findings are suited for inline PR review. The distinction matters, because putting the wrong categories into the review loop creates noise that trains developers to dismiss the channel — which undermines both the security value and the general review value.
Categories that work well as inline PR review findings:
- Injection-vulnerable patterns: String concatenation into SQL queries, template string interpolation into shell commands, unsanitized user input passed to file system operations. These are patterns that are localized to specific lines and have clear, inline-expressible remediations.
- Exposed credentials and secrets: Hardcoded API keys, authentication tokens, database connection strings, private keys. Detection is high-confidence, remediation is clear (move to environment variable or secrets manager), and the finding is urgent enough to warrant interrupting the review flow.
- Insecure API call patterns: HTTP calls where HTTPS is available, API calls with authentication disabled, missing TLS verification flags. Pattern matching on call sites where these issues appear is tractable and produces low false-positive rates with appropriate configuration.
- Missing input validation at boundary functions: If a function is on an inbound request path and doesn't have input validation, and your codebase has a consistent pattern for how validation is done at those boundaries, the style graph can flag the missing pattern — treating it as both a convention deviation and a security observation.
Categories that don't work well as inline review findings:
- Dependency vulnerability scanning — this is better handled by a dedicated tool that monitors dependencies continuously, not just on PR diffs
- Complex data flow analysis (taint tracking, SSRF detection through multi-hop paths) — these require full-program analysis that can't be expressed as a local inline suggestion
- Cryptographic implementation review — this requires specialized knowledge that a pattern-matching tool can't reliably provide without generating significant false positives
How inline security suggestions work
When Replixa detects a security pattern in a PR diff, it posts the finding inline at the specific line where the issue appears — the same format used for style suggestions. For pattern categories with clear remediation, it posts an inline patch suggestion rather than a comment thread.
Consider a concrete example: a developer opens a PR adding a new endpoint that queries the database. The query is constructed with string concatenation:
// In the PR diff — new code
const query = `SELECT * FROM users WHERE email = '${userEmail}'`
const result = await db.execute(query)Replixa detects the string interpolation into a SQL query context and posts an inline suggestion at that line, with a patch showing the parameterized query pattern consistent with how the rest of the codebase handles database queries:
// Suggested replacement
const query = 'SELECT * FROM users WHERE email = $1'
const result = await db.execute(query, [userEmail])The suggestion includes a brief finding label — [security: sql-injection-pattern] — so the developer understands the category, and a link to the relevant section of the project's security guidelines if configured. The developer can apply the patch in one click, or dismiss the suggestion if there's a reason the pattern doesn't apply.
The signal-to-noise problem in security scanning
Security tools have a well-known false-positive problem. Tools that are too aggressive generate findings on patterns that look dangerous but are actually safe in context — a base64-encoded string being flagged as a potential secret, for instance, or a rate-limited internal API call being flagged as an insecure HTTP request. When developers encounter false positives frequently, they build a habit of dismissing findings — which means they dismiss the real ones too.
This is why the inline security findings in Replixa are filtered through the same confidence threshold system as style suggestions. A security pattern match that has a high false-positive rate in the codebase's historical context will be suppressed or posted with lower confidence labeling. Patterns that are consistently high-confidence — hardcoded strings that match credential formats, SQL concatenation patterns without parameterization — post at higher confidence.
We're not saying the inline approach eliminates false positives. We're saying that calibrating security finding confidence using codebase context — knowing that a certain string pattern in a test file is intentionally hardcoded mock data versus a production credential — reduces false-positive rates compared to context-free regex matching against the full repository.
Security review and human reviewer roles
Inline security pattern detection doesn't substitute for human security review on high-risk changes. A PR adding a new authentication mechanism, changing how sessions are managed, or modifying access control logic warrants human security review regardless of what automated tools say. No pattern-matching tool can reason about the full security implications of an access control design — that requires understanding the system's threat model.
What automation changes is the baseline coverage. In organizations without automated security finding in the review loop, security issues surface in PRs only when a reviewer with security knowledge happens to look at the specific line where the issue appears. That's a coverage property — it depends on who reviewed the PR and whether the reviewer's attention landed on the right lines. Automated inline detection makes the coverage deterministic for the pattern categories it covers, regardless of which human reviewer is assigned.
The combination — automated baseline coverage for pattern-detectable issues, human review for architectural security questions — produces better coverage than either approach alone. The human reviewer's attention is freed from scanning for injection patterns and exposed credentials (which the automation covers) and can focus on the security questions that require reasoning about system design rather than pattern matching.
Configuration: getting the right scope
Security pattern detection in Replixa is configured in replixa.yml under the security key:
# replixa.yml
security:
enabled: true
# Categories to enable
patterns:
- sql_injection
- credential_exposure
- insecure_http
- missing_input_validation # Requires style graph for boundary detection
# Confidence threshold for security findings (higher than style suggestions)
# Security findings post at higher bar to minimize false positives
confidence_threshold: 0.85
# Post security findings even if they're below the threshold —
# as lower-confidence observations rather than suggestions
post_low_confidence_observations: false
# Paths to exclude from security scanning
# (e.g., test files where hardcoded values are intentional)
exclude:
- "**/__tests__/**"
- "**/*.test.ts"
- "test/**"
- "fixtures/**"The exclusion list for test files is important. Test files legitimately contain hardcoded values that look like credentials, SQL strings that are intentional test fixtures, and HTTP calls with intentionally insecure configurations for test environments. Without test exclusions, security pattern detection generates consistent false positives in test code and trains developers to dismiss the channel.