name	false-positive-rules
description	Rules for auto-dismissing code review findings that are false positives

False Positive Rules (Auto-Dismiss)

Apply these rules to ALL findings. If a finding matches ANY rule, DISMISS it.

1. CI-Controlled Variables

ANY finding about these variables -- they aren't attacker-controlled in CI context:

CI_* (CI_PROJECT_ID, CI_MERGE_REQUEST_IID, CI_JOB_TOKEN, etc.)
GITLAB_* (GITLAB_USER_LOGIN, etc.)
PROJECT_*, MR_* variables set by CI
Environment variables set by deployment scripts or CDK

2. Intentional CI/Automation Flags

These are required for CI automation, not security issues:

--dangerously-skip-permissions (required for non-interactive CI)
--output-format text (standard CI output)
--print with MCP servers
--no-verify in CI pipeline contexts
Feature flags and toggles that are intentional

3. Ephemeral CI Context

CI jobs run in isolated, ephemeral containers:

Token permissions (CI tokens are scoped and ephemeral)
File permissions in /tmp or CI workspace directories
MCP server access (uses CI token context, not persistent)
World-readable files in CI workspace (container is isolated)
Temporary credentials with automatic rotation

4. Theoretical Risks

Dismiss findings that match these patterns:

"Could be exploited if..." with no practical attack path
Race conditions with no real-world trigger
Missing validation where input is already validated upstream
Performance concerns in cold-start-only paths
Complexity complaints about necessarily complex logic

5. Already-Enforced Constraints

Issues caught by linters/formatters (ESLint, Prettier, tsc)
Issues caught by existing CI checks (tests, type checks)
Issues in auto-generated code (packages/generated/)
CDK nag suppressions that already have documented justification

The Senior Engineer Test

If you're unsure, apply this test: "Would a senior engineer reviewing this MR request this change?" If the answer is "probably not", DISMISS IT.

Also ask: "Is this finding actionable and specific?" If the finding is vague or the fix is unclear, DISMISS.

False Positive Rules (Auto-Dismiss)

Apply these rules to ALL findings. If a finding matches ANY rule, DISMISS it.

1. CI-Controlled Variables

ANY finding about these variables -- they aren't attacker-controlled in CI context:

CI_* (CI_PROJECT_ID, CI_MERGE_REQUEST_IID, CI_JOB_TOKEN, etc.)

GITLAB_* (GITLAB_USER_LOGIN, etc.)

PROJECT_*, MR_* variables set by CI

Environment variables set by deployment scripts or CDK

2. Intentional CI/Automation Flags

These are required for CI automation, not security issues:

--dangerously-skip-permissions (required for non-interactive CI)

--output-format text (standard CI output)

--print with MCP servers

--no-verify in CI pipeline contexts

Feature flags and toggles that are intentional

3. Ephemeral CI Context

CI jobs run in isolated, ephemeral containers:

Token permissions (CI tokens are scoped and ephemeral)

File permissions in /tmp or CI workspace directories

MCP server access (uses CI token context, not persistent)

World-readable files in CI workspace (container is isolated)

Temporary credentials with automatic rotation

4. Theoretical Risks

Dismiss findings that match these patterns:

"Could be exploited if..." with no practical attack path

Race conditions with no real-world trigger

Missing validation where input is already validated upstream

Performance concerns in cold-start-only paths

Complexity complaints about necessarily complex logic

5. Already-Enforced Constraints

Issues caught by linters/formatters (ESLint, Prettier, tsc)

Issues caught by existing CI checks (tests, type checks)

Issues in auto-generated code (packages/generated/)

CDK nag suppressions that already have documented justification

The Senior Engineer Test

If you're unsure, apply this test: "Would a senior engineer reviewing this MR request this change?" If the answer is "probably not", DISMISS IT.

Also ask: "Is this finding actionable and specific?" If the finding is vague or the fix is unclear, DISMISS.

false-positive-rules