Secure Development Policy¶
Purpose. Ensure security is built into Soon's product across the whole development lifecycle. All development is in-house, on GitHub. Absorbs the former Secure Coding Policy.
1. Scope¶
All software developed by Soon: the WFM SaaS product, supporting services, and infrastructure code. Applies to all engineers. Outsourced development is out of scope (Soon does not outsource development).
2. Policy¶
2.1 Security in the lifecycle¶
Security must be considered at every stage:
- Requirements: security and privacy requirements (tenant isolation, access control, GDPR processor obligations) are identified when features are specified.
- Design: features touching authentication, authorisation, tenant boundaries, or personal data require explicit design consideration of security before implementation.
- Code: secure coding principles (2.3) apply; all changes go through PR review (2.2).
- Test: CI checks must pass before merge; security-relevant behaviour (authorisation, isolation) must be covered by tests.
- Deploy: releases go through the CI/CD pipeline per the Change Management Process; no manual, unreviewed production deploys.
2.2 GitHub flow and CI¶
- All changes must be made on branches and merged via pull request. At least one review approval is mandatory; direct pushes to the main branch must be blocked by branch protection.
- CI checks (build, tests, lint) must pass before merge.
- Dependency scanning must be enabled on product repositories. TODO(owner): confirm Dependabot is enabled and alerts are triaged.
- SAST and secrets scanning must run in CI or on the repository. TODO(owner): confirm current tooling (e.g. GitHub code scanning / secret scanning).
2.3 Secure coding principles¶
Engineers must apply, and reviewers check for:
- Input validation on all untrusted input; output encoding to prevent XSS.
- Parameterised queries only — no string-built SQL.
- Authorisation and tenant-isolation checks enforced server-side on every request.
- No hardcoded secrets. Secrets live in a secrets manager (TODO(owner): confirm — AWS Secrets Manager / environment configuration), never in source code or Git history.
- Awareness of the OWASP Top 10; it is the baseline checklist for review of security-sensitive changes.
2.4 Environments and data¶
- Development, test/staging, and production environments must be separated; production credentials must not be used in dev/test.
- Production data must not be used in dev/test unless masked or anonymised — see the Data Handling & Deletion Policy.
3. Roles & responsibilities¶
- Engineers: follow this policy; flag security-relevant changes in PRs.
- Reviewers: check secure-coding principles during PR review.
- Security responsible: maintains tooling (scanning, branch protection), triages dependency and scanning alerts.
4. Related documents¶
- Change Management Process
- Data Handling & Deletion Policy
- Technical Vulnerability & Threat Management Policy
- Cloud & Infrastructure Security Policy
Change log¶
| Version | Date | Author | Comments |
|---|---|---|---|
| 0.1 | 2023-10-23 | Olaf Jacobson | First draft document |
| 0.2 | 2026-07-18 | Andrea Cardinali | Rewritten lean and Soon-specific (ISMS overhaul); absorbs the Secure Coding Policy |