Summary: The baseline practices that predate AI and still carry most of the load — input validation, least privilege, dependency hygiene, secrets handling — plus the OWASP/CERT/NIST standards behind them.
Sources: raw/Secure-coding-patterns/Secure Coding Practices_ 7 Best Practices, OWASP Guidance, and AI-Era Tips.md (Checkmarx)
Last updated: 2026-07-29
Checkmarx’s framing is the useful one: these practices “apply across languages, frameworks, and architectures, and they remain essential… whether code is written by humans, generated with AI assistance, or produced through a mix of both.”
Nothing here is new. It matters because the failure modes of AI-generated code are overwhelmingly omissions of these controls rather than novel vulnerability classes.
The seven foundational practices
- Input validation and encoding
- Authentication and session management
- Principle of least privilege
- Error handling and logging
- Cryptographic practices
- Dependency management
- Secrets and sensitive data handling
The checklist
Condensed from Checkmarx’s table:
| Practice | What to check |
|---|---|
| Validate all inputs | ”Treat all external input as untrusted. Validate type, length, format, and range. Use allow-lists where possible.” |
| Encode output by context | Encode before rendering in HTML, JavaScript, URLs |
| Strong authentication and session controls | Password handling, MFA, secure tokens, logout invalidation, session expiry |
| Apply least privilege | Users, services, containers and components get only what they need — “limits blast radius” |
| Enforce secure access control | ”Verify authorization on every sensitive action and object access. Do not rely on UI controls alone.” |
| Handle errors securely | Generic errors to users, detail in protected logs — prevents information leakage |
| Log security-relevant events | Failed logins, privilege changes, validation failures “without logging secrets or personal data” |
| Use proven cryptography | Standard libraries, approved algorithms, protected keys |
| Manage dependencies | Inventory, remove unused, monitor CVEs, update vulnerable or unmaintained libraries |
| Protect secrets | ”Never hardcode secrets in code, config files, or scripts. Use a secrets manager and rotate.” |
| Secure file handling | Restrict uploads by type and size, validate names and paths, store outside web-accessible paths |
| Build security into CI/CD | SAST, SCA, secrets detection, policy checks in PRs and pipelines |
| Review AI-generated code before use | ”Treat AI-generated code like third-party code. Validate logic, dependencies, secrets, and security controls before merging.” |
The last row is the only AI-specific entry, and it is a process control, not a new technical practice.
Standards referenced
- OWASP Top 10 Secure Coding Practices — the general application-security list, distinct from the OWASP Top 10 for LLM Applications in this vault
- CERT Coding Standards — language-specific rules
- NIST SSDF (SP 800-218) — Secure Software Development Framework
None of the three are present in raw/. SSDF is the notable absence: it is the framework a regulator or auditor is most likely to reference, and it sits alongside the NIST AI RMF already ingested in AI Governance.
What changes in the AI era, per Checkmarx
“The fundamentals of secure coding do not change in the AI era, but teams need additional guardrails because AI can generate insecure code quickly and at scale.”
The three amplified concerns:
- Lack of review — “Developers may accept AI-generated code without fully analyzing it, especially if it appears to work.”
- Lack of contextual awareness — tools “may not understand the specific business logic or security requirements… they may fail to enforce appropriate validation rules or security controls that a developer with domain knowledge would typically apply.”
- Delayed detection — issues surface later in the lifecycle, “often requir[ing] more effort, especially if other parts of the system depend on the affected code.”
Note that all three are about scale and review capacity, not about new vulnerability classes. The vulnerabilities are the same ones the seven practices already address; what changed is the rate at which they can be introduced and the erosion of the human checkpoint that used to catch them.
Why this page matters to the rest of the vault
This is the only material in the corpus covering conventional application security. Everything else — PITAX, ATLAS, OWASP LLM Top 10 — treats the AI system as the target.
Here the AI system is the author, and the target is ordinary software. OWASP LLM05 Improper Output Handling is the bridge between the two views: model output flowing untrusted into a downstream system, whether that system is a web page or a git repository.