DevSecOps Practice Hub

Secure Coding

Apply language-level and framework-level practices that eliminate whole vulnerability classes.

BeginnerSecure CodingApplication

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Plan Threat modeling, requirements and security design decisions.
  • Code Static analysis, secret detection and secure coding practices.

Overview

Secure coding is mostly about defaults: parameterised queries, output encoding by the template engine, validated input at boundaries, and safe-by-construction APIs rather than developer vigilance.

Why it matters

A framework that makes the safe path the default removes an entire class of findings from every future scan.

How it works

  1. 01Identify the vulnerability classes relevant to the stack.
  2. 02Choose APIs and framework settings that make the unsafe form hard to write.
  3. 03Encode the rule as a linter or SAST check so it stays enforced.

Common tools

SemgrepSonarQubeESLintPythonGitHubLinux

Implementation examples

pythonParameterised query
# Unsafe: string interpolationcur.execute(f"SELECT * FROM users WHERE email = '{email}'") # Safe: parameter bindingcur.execute("SELECT * FROM users WHERE email = %s", (email,))
Binding keeps user input as data, never as SQL syntax.

Best practices

  • Validate at the boundary and use typed models.
  • Prefer allow-lists over deny-lists.
  • Turn each incident into a lint rule.

Common mistakes

  • Relying on code review alone to catch known unsafe patterns.