Secure Development Lifecycle Policy

1. Purpose

This policy sets out how CompleteFlow designs, builds, tests, and releases software so that security is treated as a first-class engineering concern throughout the development lifecycle. It aligns with OWASP SAMM, NIST SSDF (SP 800-218), and the relevant controls from ISO/IEC 27001:2022 Annex A.8.

2. Scope

This policy applies to:

• The CompleteFlow platform (application code, infrastructure-as-code, deployment pipelines, container images)
• All CompleteFlow personnel who contribute to or review code
• All environments where CompleteFlow code runs (development, test, production customer subscriptions)

3. Principles

• Security is a property of the system, not a stage. Security activities are embedded throughout the lifecycle, not concentrated in a single pre-release gate.
• Shift-left. Defects and vulnerabilities are cheaper to fix the earlier they are found. Automated checks run at developer commit and at pull-request time.
• Automate the repetitive. Every change runs a standard battery of automated security checks; humans focus on design, intent, and what automation cannot catch.
• Least privilege by construction. The application, its workflows, and its credentials are scoped to what the work requires.
• Defence in depth. No single control is assumed sufficient; failures in one layer should be detected and contained by others.
• Evidence over assertion. Security claims are backed by artefacts (CI logs, reviewed code, test records) that can be produced on demand.

4. Roles and responsibilities

5. Design

5.1 Threat modelling

Material new features, architectural changes, or changes to data flows are assessed using a lightweight STRIDE-style threat model. The assessment records the assets being protected, the actors, the data flows, the trust boundaries, and the threats with corresponding mitigations. The Information Security Officer signs off on the resulting threat model.

Examples of changes that trigger a threat model: a new integration that introduces outbound calls to a new destination; a change to authentication, authorisation, or tenancy boundaries; a new class of processing (for example, a new AI model with different data-handling commitments); a change to data retention or location.

5.2 Privacy and data-protection impact

Where a design affects personal data (new data category processed, new retention, new sub-processor, new data flow), the Information Security Officer considers privacy impact in conjunction with CF-POL-002 and the Data Protection Policy. For customer deployments, DPIA responsibility rests with the customer as controller; CompleteFlow supports the customer with the information required.

5.3 Architecture standards

• All designs targeting customer subscriptions follow the reference architecture in CF-DOC-001, notably: private endpoints on data services, managed-identity authentication, restricted outbound traffic, and customer-held encryption keys.
• New components default to least-privilege IAM, no public network exposure, and encryption at rest and in transit.
• Per-user credentialling is preferred over shared service principals where the action is on behalf of an identified user.

6. Development

6.1 Source control

• All code is held in a GitHub organisation with branch protection on the default branch
• Mandatory pull-request review; at least one reviewer required for merge
• Signed commits required for the default branch
• MFA enforced organisation-wide; FIDO2 or authenticator-app preferred
• Fine-grained repository access; external collaborators granted only the minimum access required

6.2 Secure coding standards

• OWASP Top 10 (web) and OWASP API Security Top 10 are the baseline
• LLM-specific risks addressed per OWASP LLM Top 10, notably prompt injection, insecure output handling, and supply-chain risks
• Input validation at trust boundaries; structured, typed interfaces between components; defensive handling of LLM output
• Parameterised database access; ORM use with awareness of injection risks where raw SQL is required
• PostgreSQL Row-Level Security enforced at the database layer for tenancy isolation
• No sensitive data in application logs; structured logging with field allow-lists where customer data could leak

6.3 Secrets management

• Secrets are never committed to source control, if one is, it is rotated immediately and the incident is logged
• Runtime secrets are held in Azure Key Vault within the customer's subscription, referenced via managed identity
• Developer-local secrets are held in an approved password manager; no shared secret files
• Short-lived credentials are preferred over long-lived where the cloud service supports them

6.4 AI-assisted coding

Use of AI coding assistants is permitted per CF-POL-008. All AI-assisted changes are subject to the same review and automated testing as any other change. Personnel remain responsible for the correctness, security, and licence compatibility of code submitted under their name.

7. Build and automated security testing

Every pull request and every release runs the following automated checks. Findings above the configured severity threshold block merge or release without recorded override.

7.1 Static Application Security Testing (SAST)

An industry-standard SAST tool runs on every pull request and every push to the default branch, using a ruleset tuned to the CompleteFlow stack. Findings are triaged by the engineer and the reviewer; Critical and High severity findings block merge without documented override by the Information Security Officer.

7.2 Software composition and container vulnerability scanning

Container images and dependency manifests are scanned on every pull request and release for:

• Known vulnerabilities in application dependencies
• Known vulnerabilities in base images and OS packages
• Misconfiguration of infrastructure-as-code
• Embedded malware signatures and suspicious binaries in built images

7.3 Dependency management

• Automated dependency monitoring generates grouped pull requests for dependency updates, distinguishing security updates from routine version bumps
• Security updates are prioritised on the patch SLA (Critical within 7 days, High within 14 days, Medium at next scheduled release, Low at normal cadence)
• Any alert not automatically resolved within the SLA is manually investigated

7.4 Secret scanning

Secret scanning is enabled across all repositories. Any detected secret triggers automatic notification and a rotation procedure. Historical commits are scanned in addition to the working branch.

7.5 AI-assisted review

Pull requests receive an automated AI-assisted security review, which complements (but does not replace) human reviewer judgement. The AI review flags potential issues for reviewer attention; humans remain accountable for approval.

7.6 Build integrity

• Container images are built reproducibly from defined base images
• Image tags reference immutable digests at deployment time
• Build logs are retained for audit

8. Code review

• Every change requires at least one peer review before merge
• Reviewers check for: functional correctness; security of inputs, outputs, and trust boundaries; handling of secrets; tenancy and authorisation; test coverage; compliance with this policy
• Security-sensitive areas (authentication, authorisation, tenancy, cryptography, AI prompt handling) require review by a second senior reviewer
• Authors and reviewers are not the same person; review-self is not permitted on the default branch

9. Testing

• Unit tests are required for new business logic; regressions require a covering test before the fix is merged
• Integration tests cover the major flows of the platform, including authentication, RBAC, tenancy isolation, and AI interactions
• Adversarial testing: specific tests for known attack patterns on authentication, authorisation, prompt injection, and data-leakage paths
• Customer-conducted penetration testing: supported by a production-equivalent environment provisioned from the same infrastructure-as-code as production

10. Release gating

• All automated checks (SAST, SCA, dependency, secret scan, AI review) must pass, or have a documented override recorded with justification and expiry
• All tests must pass
• Changes to security-sensitive areas, infrastructure, or customer-visible behaviour receive an additional review sign-off
• Release candidate is deployed to a non-production environment before production rollout

11. Deployment and change control

• Infrastructure-as-code: all deployments are from version-controlled IaC (Bicep). No manual production configuration
• Environment parity: production and customer test environments are defined from the same IaC, parameterised by environment-specific values
• Standard changes follow the documented change process; high-risk changes (schema migration, credential rotation, policy rollout) require explicit authorisation and a rollback plan
• Emergency changes follow the expedited process in CF-PLAN-001 with post-hoc review within 5 working days
• Segregation of duties: the approver of a production deployment is not the implementer where practicable, and where not, both actions are logged and retained

12. Patch management

The patch SLA applies to both application dependencies and platform components:

Azure-managed services are patched by Microsoft on their published cadence.

13. Post-deployment validation

• Smoke tests and synthetic probes after deployment
• Error-rate and latency monitoring with alerting thresholds; deviations trigger rollback or investigation
• Microsoft Defender for Cloud anomaly alerts cover runtime posture; custom KQL rules cover CompleteFlow-specific patterns
• Customer-reported issues are triaged via the incident response process (CF-PLAN-001) where applicable

14. Training

• All personnel with code commit access complete information security training at induction, covering OWASP Top 10, OWASP LLM Top 10, secret handling, dependency management, and CompleteFlow-specific secure coding patterns
• Annual refresher training includes updates on new threat classes and any changes to this policy
• Role-specific training (for example, for the Technical Lead approving security-sensitive PRs) is recorded

15. Exceptions

Exceptions to any clause of this policy require written justification, a compensating control, a review date, and approval by the Information Security Officer. Exceptions are logged in the risk register (CF-REG-001) and reviewed quarterly.

16. Related documents

• CF-POL-001 Information Security Policy
• CF-POL-003 Access Control Policy
• CF-POL-008 AI Governance and Acceptable Use Policy
• CF-PLAN-001 Incident Response Plan
• CF-DOC-001 Architecture and Security Overview

17. Document control