Sample: SQL — see SquidGate detect findings

[DotNetRussell]

SquidGate language sample — SQL

This PR intentionally introduces insecure patterns so you can see SquidGate work on SQL:

• Hardcoded secret / credential
• Injection and/or dangerous API usage

File

examples/sql/demo.sql

What to look for

1. Check run named SquidGate
2. Line annotations on the sample file
3. PR comment summarizing findings
4. Check failure when severity ≥ block_on (default high)

Demo only. Do not merge these patterns into production apps.

All language samples · Setup SquidGate on your repo

[github-actions]

🛡️ Security Scan Results

The new demo SQL file introduces hardcoded credentials and overly broad privilege grants, both of which are clear security issues.

⛔ 2 finding(s) block merge.

HIGH — Hardcoded credentials in SQL script

File: examples/sql/demo.sql:3 | Confidence: high

The CREATE USER statement hardcodes a password 'SuperSecretDemoPassword123!'. Hardcoded credentials are easily discoverable in source control and violate secure credential management practices.

CWE: CWE-798 | OWASP: A07:2021

Recommendation: Remove the hardcoded password. For demo purposes use a placeholder such as '' and document that real credentials must come from secure configuration or secret management systems.

---

HIGH — Overly permissive database privileges granted to public

File: examples/sql/demo.sql:8 | Confidence: high

GRANT ALL PRIVILEGES ON DATABASE prod TO public; assigns full access to any database user, violating the principle of least privilege.

CWE: CWE-732 | OWASP: A01:2021

Recommendation: Grant only the minimum required privileges to specific roles or users. Never grant to PUBLIC for production or sensitive databases.

---