Release Management Policy

Purpose

This policy defines the requirements for managing software releases at Carriyo, from development through to production deployment. It ensures that releases are secure, tested, approved, and deployed in a controlled manner that minimises risk to service availability and data integrity.

Scope

This policy applies to all software releases to Carriyo's production environment, including application code, API changes, infrastructure configuration changes, database migrations, and third-party component updates. It applies to all engineering and DevOps personnel involved in the release process.

Policy Statements

Secure Development Lifecycle (A.8.25, A.8.26, A.8.27, A.8.28)

• All software development follows Carriyo's secure development lifecycle, which incorporates security considerations at every stage from design through deployment.
• Security requirements are identified during the design phase for new features and significant changes.
• Threat modelling is performed for features that handle sensitive data, authentication, or authorisation.
• Developers follow secure coding standards, including input validation, output encoding, parameterised queries, and proper error handling.
• Development, staging, and production environments are separated. Developers do not have direct write access to production systems.

Code Review and Approval

• All code changes require at least one peer review before merging to the main branch.
• Security-sensitive changes (authentication, authorisation, cryptography, data handling) require review by a member of the security team or a designated security champion.
• Code reviews assess: functional correctness, security implications, performance impact, test coverage, and adherence to coding standards.
• Merge approvals are enforced through branch protection rules in the version control system.

Automated Security Checks (A.8.28)

• The CI/CD pipeline includes the following automated security checks that must pass before a release is eligible for production deployment:
  • Static Application Security Testing (SAST): Scans source code for security vulnerabilities and insecure coding patterns.
  • Software Composition Analysis (SCA): Identifies known vulnerabilities in third-party dependencies and open-source libraries.
  • Container Image Scanning: Scans Docker images for known vulnerabilities before deployment.
  • Secrets Detection: Scans code and configuration for accidentally committed credentials, API keys, or tokens.
• Findings rated as Critical or High severity block the release pipeline and must be remediated before deployment.

Testing Requirements (A.8.29)

• All releases must pass automated unit tests, integration tests, and end-to-end tests before production deployment.
• Test coverage thresholds are defined and enforced for critical services.
• Releases involving significant changes must be validated in a staging environment that mirrors production.
• Performance and load testing is required for changes that may impact system capacity or response times.

Release Approval and Deployment (A.8.31, A.8.32)

• Releases to production follow the change categories defined in the Change Management Policy (CAR-ISMS-POL-007): standard, normal, and emergency.
• Normal releases require explicit approval from the engineering lead before production deployment.
• Emergency releases (critical security patches, incident remediation) may be deployed with expedited approval, followed by retrospective review within 48 hours.
• Deployments are automated through CI/CD pipelines using blue-green or rolling deployment strategies to minimise downtime.
• All deployments are logged with: who deployed, what was deployed, when it was deployed, and the associated change reference.

Rollback

• Every production release must have a documented and tested rollback mechanism.
• Automated rollback is triggered if post-deployment health checks fail.
• Manual rollback can be initiated by any on-call engineer if issues are detected.
• Rollback procedures are tested as part of the regular release process.

Third-Party Components (A.8.33)

• Third-party libraries and dependencies are managed through approved package managers with lock files to ensure reproducible builds.
• Dependencies are regularly updated to incorporate security patches. Critical vulnerability patches are applied within 48 hours of disclosure.
• New third-party dependencies require review for licence compliance, security posture, and maintenance status before adoption.

Roles and Responsibilities

Compliance and Enforcement

Compliance is monitored through CI/CD pipeline logs, deployment audit trails, and periodic reviews of release practices. Releases that bypass mandatory security checks or approval processes are investigated as policy violations. Repeated non-compliance is escalated through the disciplinary process.