Skip to content

secure-coding-standards.md

Latest commit

 

History

History
59 lines (39 loc) · 3.98 KB

secure-coding-standards.md

File metadata and controls

59 lines (39 loc) · 3.98 KB
Raw

Secure Coding Standards — Organization Baseline

Scope: organization
Status: enabled
Path: org/secure-coding-standards.md

Purpose

This document defines the minimum security requirements all engineers must follow when writing, reviewing, or merging code. These rules apply to every repository, language, and deployment target in the organization. Team- or project-level documents may tighten these rules but never relax them.

Input Validation

  • Validate at the boundary. Every value entering the system from an external source (HTTP request, file upload, message queue, CLI argument) must be validated before use. "Internal" does not mean trusted — validate inter-service calls too.
  • Allowlist over blocklist. Define the set of acceptable characters, lengths, and formats; reject everything else. Regex blocklists that try to exclude bad characters will be bypassed.
  • Reject early, fail closed. Return an error and stop processing the moment validation fails. Never attempt to sanitize and continue when the input is structurally invalid.
  • Do not log raw input. Before writing user-supplied data to any log, strip or redact it to prevent log injection.

Authentication & Authorization

  • Use the organization-approved identity provider. Do not implement custom password storage or session management. Integrate with the IdP via the standard OIDC/SAML flow.
  • Enforce authorization on every request. Authentication confirms who the caller is; authorization confirms what they can do. Check both. Never assume an authenticated user is authorized for a given resource.
  • Least-privilege service accounts. Each service must run under a dedicated account with only the permissions it needs. Shared credentials are prohibited.
  • Rotate secrets automatically. Secrets must never have infinite TTLs. Use the secrets-management platform; hardcoded credentials in source will be flagged as P0 findings.

Cryptography

  • Approved algorithms only. Use AES-256-GCM for symmetric encryption, RSA-4096 or EC P-256 for asymmetric, and SHA-256 or SHA-3 for hashing. MD5 and SHA-1 are prohibited for security purposes.
  • Never roll your own crypto. Use audited libraries (e.g., cryptography for Python, node:crypto for Node). Implementing primitives from scratch requires a security review.
  • Protect data in transit. All internal and external service communication must use TLS 1.2+. TLS 1.0 and 1.1 are disabled org-wide.

Error Handling & Logging

  • Sanitize error messages. User-facing errors must never expose stack traces, internal paths, database schema, or implementation details.
  • Log security events. Authentication successes/failures, authorization failures, and input validation rejections must be logged at WARN or higher with a consistent schema (timestamp, actor, action, resource, result).
  • Do not log secrets. Tokens, passwords, API keys, and PII must never appear in logs. Use structured logging with an explicit allowlist of fields.

Dependency Management

  • Pin versions. All dependencies must be pinned to exact versions in the lockfile. Floating ranges (^, ~, *) are prohibited in production manifests.
  • Review before adopting. New third-party libraries require a brief security review comment in the PR. Check for known CVEs, last publish date, and maintainer reputation.
  • Keep dependencies current. Automated dependency-update PRs (Dependabot / Renovate) must be reviewed weekly. Critical CVE patches must be merged within 48 hours.

Code Review Security Checklist

Every PR author must confirm before requesting review:

  • No secrets, tokens, or credentials in source
  • No new eval(), exec(), dangerouslySetInnerHTML, or equivalent
  • SQL/command built with parameterized queries, not string concatenation
  • New endpoints have authentication and authorization checks
  • Error responses do not leak internal details

Maintained by the Security Engineering team. Questions → #security on Slack.