Secure Coding

​

Principles

​

Secure-by-design

• Minimize attack surface area.
• Establish secure defaults.
• Principle of least privilege.
• Defense in depth.
• Fail securely.
• Don’t trust services.
• Separation of duties.
• Avoid security by obscurity.
• Keep security simple.
• Fix security issues correctly.

​

Privacy-by-design

• Proactive not reactive; preventative not remedial.
• Privacy as the default.
• Privacy embedded into design.
• Full functionality — positive-sum.
• End-to-end security — full lifecycle protection.
• Visibility and transparency.
• Respect for user privacy.

​

What we look for in code review

• Input is validated and output is encoded — no string concatenation into SQL, shell, HTML, or templates.
• No secrets in source — and no secret values in .env, config.yaml, values.yaml, container images, Helm charts, Terraform state, deployment manifests, or CI logs. Production environment variables that hold secrets are populated from HashiCorp Vault at runtime (Vault Agent on Kubernetes / ECS / Cloud Compute; CI fetches via Vault JWT/OIDC auth). See Secrets Management → Application configuration and environment variables.
• Authentication and authorization checks are present at every layer that handles user data.
• Untrusted input from third parties is treated as untrusted.
• Dependencies are pinned and scanned via the GitHub Security tab — Dependabot, Snyk, and GitHub Advanced Security cover SCA / vulnerability findings.
• Logs do not contain PII, secrets, or full payloads.
• Errors fail closed, not open.

​

Common-vulnerability training

• Authorization-bypass attacks.
• Insecure session IDs.
• Injection (SQL, NoSQL, command, template).
• Cross-site scripting.
• Cross-site request forgery.
• Use of vulnerable libraries.

​

Tooling

​

Version history