Secure Development Policy

Document ID: DPWAT-ISMS-POL-006
Version: 1.0
Owner: Process Owners (RA) + CISO — Timo Andreas Bejan
Approved by: Administrator (ADM) — Anna Boros
Effective date: 2025-10-15
Next review: 2027-02-01 (or on major change)

1. Scope

This policy covers software development and delivery activities performed by DP WAT, including customer projects and DP WAT-owned internal tooling.

2. Baseline secure development controls

• Maintain separation between development/test and production environments where applicable.
• Follow least privilege for access to repositories, CI, and production.
• Protect source code repositories with MFA and appropriate permissions.
• Apply dependency management practices (keep dependencies updated; track critical vulnerabilities).

3. Code review approach (risk-based)

DP WAT does not mandate peer review for every change. Instead:

• High-risk changes require a second-person review before merge/deploy (e.g., auth changes, payment, data access, infrastructure, security settings, production hotfixes).
• Low-risk changes may be merged by the author if controls still provide adequate assurance (tests, small scope, etc.).

Any exceptions to the above (e.g., emergency changes) must be documented as a change record and, if needed, a risk acceptance.

4. Test data and data masking

• Prefer synthetic or anonymized test data over production data where feasible.
• Do not copy production data (e.g., user lists, PII) to local machines for testing unless strictly required.
• When production data access is needed for debugging, minimize scope and duration.
• Masking or anonymization requirements for customer data follow customer specifications.
• Test environments are typically ephemeral (CI pipelines, Docker containers); test data is disposed of when environments are torn down.

5. Security testing

Static analysis and dependency scanning - Static code analysis is performed on most projects. - IDE tools (JetBrains) and GitHub dependency alerts flag vulnerable dependencies. - Dependency warnings are taken seriously; code is patched and dependencies updated promptly.

Penetration testing - Third-party penetration testing is recommended for customer projects based on risk. - Preferred supplier: S.C. FOX SYSTEMS S.R.L. (see supplier register SUP-0016). - When a customer opts out of paid testing, DP WAT records the decision and residual risk.

Security scanning scope - SAST/DAST/dependency/secret scanning is performed based on project risk and customer requirements.

Functional testing - DP WAT employs unit tests, integration tests, end-to-end tests, and manual QA as appropriate. - No fixed coverage requirements; testing scope and depth is determined per project based on risk, complexity, and customer requirements.

6. Secure architecture and engineering principles

DP WAT applies the following principles when designing and building systems:

Defense in depth - Apply multiple layers of security (network, application, data). - Do not rely on a single control to protect assets.

Secure defaults and least privilege - Configure systems to deny by default; access is opt-in. - Apply least privilege to IAM roles, service accounts, and policies via IaC. - Use cloud provider policy frameworks (AWS IAM, Google Cloud IAM, Cloudflare access policies).

Environment isolation - Maintain isolated environments (development, staging, production). - Separation is implemented via separate AWS accounts where feasible; at minimum, separate database/data layer. - Production credentials and data are not used in non-production environments. - Environments are defined via IaC (Terraform) and version-controlled.

Fail secure - Design systems to fail closed (deny access) rather than fail open.

Input validation - Validate input on both client and server side. - Sanitize data to prevent injection attacks (SQL, XSS, etc.).

Secrets management - No plaintext secrets (see Cryptography & Secrets Policy). - Rotate credentials for critical systems, especially those accessible to developers.

Logging and auditability - Implement logging with appropriate levels (debug, info, warn, error). - Implement audit trails for mutating requests on sensitive operations.

Infrastructure standards - Standard stack: AWS, Terraform (IaC), ECS, CloudFront, Application Load Balancers. - TLS termination handled by cloud provider (AWS ALB/CloudFront). - Infrastructure is defined as code and version-controlled.

Dependency management - Keep libraries and dependencies updated. - For projects DP WAT develops: mandatory update cycles every few months. - For consulting engagements: updates recommended but enforcement is customer's responsibility. - Third-party dependencies are chosen based on experience; only reputable, well-maintained libraries are used.

Outsourced development (contractors) - DP WAT engages contractors (PFAs and companies) to perform development work. - Contractors are subject to: policy acknowledgements, NDAs/DPAs as applicable, onboarding/offboarding procedure, access reviews, and security training. - Contractor access is time-bound, follows least privilege, and is revoked at contract end. - See procedure 04.01-people-onboarding-offboarding-and-third-parties.

7. Work on customer-owned devices (cross-customer segregation)

DP WAT acknowledges that customer-owned devices may be used to access DP WAT internal systems and other customers’ code. DP WAT applies the following minimum controls to reduce cross-customer risks:

• Do not develop or handle non-customer-specific codebases on a customer-owned device unless explicitly approved and risk-assessed.
• Prefer separation by accounts/profiles (separate browser profiles and separate SaaS accounts where applicable).
• Do not store or persist other customers’ code/data on the customer-owned device beyond transient access required to do the work.
• Use least privilege and project-scoped access (separate repos/teams per customer where feasible).