No String Concat In Queries
@security/check-no-string-concat-in-queries
$ prime install @security/check-no-string-concat-in-queries Projection
Always in _index.xml · the agent never has to ask for this.
NoStringConcatInQueries [check] v0.1.0
Loaded when retrieval picks the atom as adjacent / supporting.
NoStringConcatInQueries [check] v0.1.0
Label
Static analysis detects no string-built SQL
Assertion
A SAST tool, lint rule, or grep step in CI flags any path where a runtime value is concatenated, interpolated, or formatted into a SQL string. Findings are addressed (or whitelisted with a comment explaining the allow-listed-identifier case) before merge.
Evidence
- CodeQL / Semgrep rule for SQL injection enabled in CI; build fails on new findings.
- Lint rule for the project's ORM (e.g.
eslint-plugin-security/detect-non-literal-regexpanalogue,banditB608, Checkstyle SQL rules) is on by default. - Allowlist comments include a ticket reference and an allow-list-of-identifiers justification, not 'TODO fix later'.
Failure Mode
An injection slips through code review because the concatenation is hidden inside buildWhereClause(filter) two files away from the controller.
Loaded when retrieval picks the atom as a focal / direct hit.
NoStringConcatInQueries [check] v0.1.0
Label
Static analysis detects no string-built SQL
Assertion
A SAST tool, lint rule, or grep step in CI flags any path where a runtime value is concatenated, interpolated, or formatted into a SQL string. Findings are addressed (or whitelisted with a comment explaining the allow-listed-identifier case) before merge.
Evidence
- CodeQL / Semgrep rule for SQL injection enabled in CI; build fails on new findings.
- Lint rule for the project's ORM (e.g.
eslint-plugin-security/detect-non-literal-regexpanalogue,banditB608, Checkstyle SQL rules) is on by default. - Allowlist comments include a ticket reference and an allow-list-of-identifiers justification, not 'TODO fix later'.
Failure Mode
An injection slips through code review because the concatenation is hidden inside buildWhereClause(filter) two files away from the controller.
Rationale
Reviewers miss SQL injection during code review — especially when the unsafe concatenation is wrapped in a helper or a multi-line query. Mechanical detection at PR time is the first reliable line of defence.
Label
Static analysis detects no string-built SQL
Assertion
A SAST tool, lint rule, or grep step in CI flags any path where a runtime value is concatenated, interpolated, or formatted into a SQL string. Findings are addressed (or whitelisted with a comment explaining the allow-listed-identifier case) before merge.
Evidence
- CodeQL / Semgrep rule for SQL injection enabled in CI; build fails on new findings.
- Lint rule for the project's ORM (e.g.
eslint-plugin-security/detect-non-literal-regexpanalogue,banditB608, Checkstyle SQL rules) is on by default. - Allowlist comments include a ticket reference and an allow-list-of-identifiers justification, not 'TODO fix later'.
Failure Mode
An injection slips through code review because the concatenation is hidden inside buildWhereClause(filter) two files away from the controller.
Source
prime-system/examples/security-appsec/primes/compiled/@security/check-no-string-concat-in-queries/atom.yaml