feat: add security lint rules (hardcoded secrets, SQL injection, unsafe deserialization)

[cschanhniem]

Summary

Rattle currently has 48 built-in lint rules focused on code style and correctness, but only one security-related rule (no-unsafe-tempfile-factories). Django, Flask, and other Python web frameworks commonly have code that is vulnerable to:

• Hardcoded passwords, API keys, and tokens in source
• SQL injection via raw string interpolation in query construction
• Unsafe deserialization (pickle.loads, yaml.load without Loader)

Security scanning currently requires a separate tool like Bandit. Adding optional security rules as a built-in rule set would let projects get both style linting and security scanning from a single rattle lint command.

Proposal

A new security rule set (enabled via [tool.rattle] enable = ["security"] in pyproject.toml):

Rule candidates

Rule	Detection target	Bandit equivalent
hardcoded-password	Variable assignment or function argument containing password, secret, token, api_key with a string literal	B105–B108
sql-injection	Raw string concatenation or f-string in execute() / executemany() calls on cursor objects	B608
unsafe-deserialization	pickle.loads, yaml.load (without yaml.SafeLoader), marshal.load	B301, B403
request-no-timeout	requests.get/post/put/... calls without timeout= argument	B113
insecure-ssl-context	ssl._create_unverified_context, verify=False in requests	B501, B602

Implementation approach

Each rule would be a Rule subclass following the LibCST visitor pattern already used by rattle. Rules would live under src/rattle/rules/security/ and be auto-discovered when the security group is enabled in config.

Prior art

• Bandit: the standard Python security linter, but runs as a separate tool with its own pyproject.toml configuration
• Ruff security rules (S category): similar goal, demonstrates detection patterns are well-understood in the ecosystem
• no-unsafe-tempfile-factories in rattle: the existing security rule establishes the pattern

Questions

1. Would this be better as a separate plugin package (e.g. rattle-security) or built into rattle core?
2. What is the minimum acceptable detection accuracy for inclusion as a built-in rule?