False positive patterns: markdown code blocks flagged as real code (SQL injection, security) #329

Summary

Cora flags markdown code blocks (bash, SQL examples in docs) as real security vulnerabilities. The scanner does not distinguish between code blocks inside .md files and actual source code.

Observed False Positives

1. Bash command flagged as SQL injection (AGENT.md)

Finding: SQL injection via string concatenation on AGENT.md:168

Actual content:

```bash
git push origin vX.Y.Z
```

A git push command in a bash code block, inside a markdown documentation file, was flagged as SQL injection. This is clearly not SQL — it is a git command in a fenced code block.

2. CHANGELOG date flagged as "future date" (CHANGELOG.md)

Finding: The new release entry uses a future date relative to the rest of the release process

Actual content:

## [0.6.1] — 2026-06-30

The date was the current date (UTC+7 = 2026-06-30). The scanner incorrectly compared the date against a different timezone or clock.

3. Cargo.lock format downgrade flagged (Cargo.lock)

Finding: lockfile header changed from version 4 to version 3

Caused by regenerating the lockfile with a slightly older local Cargo toolchain. While this was a real issue in our case, the scanner should also consider that Cargo.lock is auto-generated and the format version is toolchain-dependent, not a security concern.

Pattern

All 3 findings are in non-executable, non-source files:

• .md (markdown docs) — code blocks are examples, not executable code
• Cargo.lock — auto-generated, not hand-written

Suggested Fix

1. For markdown files (.md): Detect fenced code blocks (```lang ... ```) and either:

   • Skip content inside fenced code blocks entirely, OR
   • Apply a significantly reduced severity (informational only) for content inside code blocks, OR
   • Use the language hint (bash, sql, yaml) to determine if the finding type matches (SQL injection in a bash code block = FP)

2. For auto-generated files (Cargo.lock, package-lock.json): Already in ignore patterns — extend to also reduce severity for format/structure changes that are not security-relevant.

3. General: When scanning .md files, default severity should be capped at informational for non-source-code file types. Security findings in documentation files should never be error/failure level unless the content is a real embedded script (e.g., inline JS in HTML).

Environment

• Cora version: latest (via codecoradev/cora-review-action@v1)
• Repo: codecoradev/uteke
• CI: GitHub Actions
• .cora.yaml already has ignore.files: ["*.lock"] but CodeCora (SARIF upload path) may not read this config

Note

The .cora.yaml rules field already has custom suppression rules for known patterns (SQL params, api_key identifiers, subprocess calls). But these only apply to the Cora Review check run, not the CodeCora SARIF-based check run. If both paths share config, the suppressions should apply to both. If not, that is a separate gap.