Secure Development Policy

Purpose of the Policy

This policy defines the organisation's requirements for writing, reviewing, and deploying code securely and consistently. It applies to all developers, engineering leads, and contractors contributing to any organisation-owned repository, and governs the use of three enforced tools across the development lifecycle: Prettier, SonarQube, and GitHub Actions.

Procedures

Secure Coding Practices

All code contributed to organisation repositories must follow the baseline practices outlined below.

No credentials, API keys, tokens, or connection strings may be hardcoded in source files. Secrets must be provided via environment variables or a managed secrets store and must never be committed to version control. Any secret accidentally committed must be rotated immediately — removal from the latest commit alone is not sufficient.

Dependencies must be kept up to date and free of known critical or high vulnerabilities. New dependencies should be evaluated for maintenance activity and licensing before being introduced. Automated dependency alerts must be triaged within an agreed turnaround time and must not be left open indefinitely.

Authentication and authorisation checks must be applied consistently across all services and enforced on the server side. Client-side checks alone are not sufficient.

Production error responses must not expose stack traces, internal file paths, or database schema details. Errors should be logged internally with sufficient detail for debugging, while user-facing messages remain generic.

Logs must never contain personally identifiable information — such as PAN, Aadhaar, or similar identifiers — in plaintext. Logs must also never contain secrets, tokens, or credentials. Logging levels must be reviewed before release so that debug-level detail does not leak into production logs.

Code Formatting Standards (Prettier)

A shared formatting configuration is maintained centrally and applied to all repositories to ensure visual consistency and remove style debate from code review.

A pre-commit hook runs the formatter automatically; commits that fail formatting are rejected locally before reaching the remote repository. A formatting check also runs in the CI pipeline as a safety net and blocks merge on failure. Format-on-save is the team-wide default editor setting.

Code Quality & Static Analysis (SonarQube)

Every pull request is scanned automatically before it can be merged. A quality gate blocks merge when new code introduces bugs, vulnerabilities, or code smells above the agreed threshold. Security hotspots flagged by the scan must be manually reviewed and explicitly resolved or justified — they are not auto-approved.

New and changed code must meet a minimum test coverage threshold. Legacy coverage gaps are tracked separately and improved over time rather than blocking unrelated work. Quality gate results are a required check in the CI/CD pipeline and cannot be bypassed by a manual merge.

CI/CD Pipeline (GitHub Actions)

All builds, checks, and deployments run through GitHub Actions. Branch protection on main/master enforces the following:

Pipeline secrets are stored using GitHub Encrypted Secrets or short-lived credentials via OIDC — never as plaintext values in workflow files. Long-lived cloud credentials should be avoided in favour of scoped, short-lived tokens wherever the platform supports it.

Dependency vulnerability scanning runs on a scheduled basis, with automated pull requests raised for available fixes. Secret scanning runs on every push to catch accidentally committed credentials before they reach a shared branch.

Merges to main/master trigger an automatic deployment to the staging environment. Production deployment requires a manual approval step by a designated approver and is never fully automatic. Releases are tagged so any deployed version can be identified precisely, and a documented one-step revert workflow is available for production incidents.

Deployment & Environment Security

Development, staging, and production environments must use separate credentials; no credential is shared across environments. Each environment's access is scoped to least privilege — services and individuals receive only the access their role requires.

Every deployment is traceable via the CI/CD pipeline's run history and approval records. Automated post-deployment health checks run after every release; a failed check triggers rollback rather than being left for manual discovery.

Roles & Responsibilities

It is the responsibility of the Engineering Lead to own the Prettier configuration, SonarQube quality gate thresholds, and overall policy compliance. The DevOps Lead is responsible for the GitHub Actions pipeline configuration, branch protection settings, and secrets infrastructure, and reviews SonarQube security hotspots at a programme level. All developers are responsible for following secure coding practices, resolving formatting and quality gate failures before requesting review, and reporting suspected security issues promptly.

Policy Revision History