security-analysis

Security Analysis

Two passes, run in order. The static pass is mechanical and exhaustive — report every match, even ones that turn out to be false positives on inspection, and only discard a match after confirming why it's safe. The reasoning pass catches what patterns structurally cannot: this is not a re-run of security-review's priority checklist or security-and-hardening's proactive threat-modeling — it's a scan workflow that ends in a severity-counted findings report.

Pass 1: static pattern scan

Check every category below against the target. Treat this like a grep sweep — you're looking for shapes, not judging exploitability yet.

Injection

• SQL: string concatenation or fmt.Sprintf/+ building a query with an external value; raw input placed directly in a WHERE/ORDER BY clause
• Command: exec.Command/os/exec/subprocess/child_process.exec where any argument traces back to external input
• Template: untrusted input rendered through a non-escaping template engine (Go text/template instead of html/template)
• LDAP: unsanitized input interpolated into an LDAP filter string

Credential and secret exposure

• Hardcoded passwords, API keys, tokens, connection strings in source
• Secrets appearing in log statements, even at DEBUG level
• Secrets or internal detail echoed back in error responses
• Environment variables logged directly instead of redacted

Authentication and authorization

• Endpoints reachable with no authentication check at all
• Authentication present but no check that the caller is authorized for this resource (ownership/role check)
• JWT validation skipped, or alg: none/unverified-signature acceptance
• Session tokens with low entropy or no expiry

Cryptographic weaknesses

• MD5 or SHA1 for anything security-sensitive (password hashing, MACs)
• ECB mode block ciphers
• Hardcoded IV/nonce (reused nonce breaks stream-cipher and GCM confidentiality)
• math/rand (or language equivalent) used for tokens, session IDs, or anything security-sensitive