| Attribute | Value |
|---|---|
| Status | Mandatory engineering standard |
| Owner | Cubewise Asia Engineering |
| Security co-owner | Cubewise Asia ISMS owner |
| Review frequency | At least annually and after a material incident, audit finding, technology change, or change to an applicable requirement |
This guide defines the minimum engineering, security, quality, and release controls for software developed or maintained by Cubewise Asia. It is intended to make changes reviewable, reproducible, reversible, and supported by evidence.
The guide is aligned with the software-development aspects of ISO/IEC 27001:2022 and its 2024 climate-action amendment. It supports the Cubewise Asia Information Security Management System (ISMS); it does not, by itself, establish conformity or certification. Organizational risk assessment, the Statement of Applicability, policies, training, supplier management, incident management, internal audit, and management review remain required outside this repository.
This guide applies to:
- employees, contractors, reviewers, release owners, and maintainers;
- source code, configuration, infrastructure, build scripts, data migrations, tests, documentation, and deployment artifacts;
- internally developed, customer-specific, open-source, and externally maintained components under Cubewise Asia control;
- human-authored and AI-assisted changes.
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are normative.
Applicable law, contracts, customer requirements, and approved ISMS policies take precedence. Repository-level instructions MAY add stricter or more specific controls, commands, and approval requirements, but MUST NOT silently weaken this baseline. Conflicts MUST be escalated to the repository maintainer and ISMS owner before work continues.
Every change MUST satisfy all applicable controls below:
- Start from an approved issue, incident, or change record with acceptance criteria.
- Classify the change risk before implementation and record security, privacy, and operational impact.
- Work on a short-lived branch; do not commit directly to a protected integration, release, or production branch.
- Keep the change minimal and preserve existing behavior unless the approved requirement changes it.
- Never commit secrets, credentials, tokens, private keys, customer data, production data, or unredacted security evidence.
- Enforce authentication and authorization on the server side, use least privilege, and fail closed.
- Add or update tests for changed behavior, including negative and abuse cases where relevant.
- Run repository-defined formatting, linting, type checks, security checks, builds, migrations, and tests before review.
- Use a pull request with independent review. The author MUST NOT be the sole approver.
- Record validation evidence, deployment impact, and rollback steps in the pull request or linked change record.
- Release only from an approved commit and preserve traceability from issue to commit, pull request, artifact, deployment, and rollback decision.
- Report suspected security incidents immediately through a private approved channel. Do not investigate in a way that destroys evidence or broadens exposure.
Exceptions MUST be explicit, risk-assessed, time-bound, approved by the accountable engineering owner and ISMS owner, and accompanied by compensating controls and an expiry or remediation issue. Schedule pressure is not an exception.
| Role | Minimum responsibility |
|---|---|
| Requester / Product Owner | Define the business need, acceptance criteria, data sensitivity, and priority. |
| Developer | Assess risk, implement the smallest safe change, test it, document evidence, and disclose limitations. |
| Reviewer | Independently verify correctness, security, test adequacy, scope, and rollback safety. |
| Maintainer | Enforce repository controls, branch protection, required checks, ownership, and merge policy. |
| Security / ISMS Owner | Approve security exceptions, guide incident handling, and maintain ISMS control applicability. |
| Release Owner | Verify release evidence, artifact provenance, approvals, deployment readiness, and rollback capability. |
One person MAY hold more than one role for low-risk work, but no author may independently approve and release a security-sensitive or high-risk change. Emergency access and emergency merges require retrospective independent review.
- Create or confirm the issue and acceptance criteria.
- Classify the change as standard, high-risk, or emergency.
- Identify affected assets, data, trust boundaries, dependencies, and rollback constraints.
- Create a branch from the repository's approved base.
- Implement a focused change using the repository's established architecture and tools.
- Run local checks and inspect the final diff for secrets, unrelated changes, and generated artifacts.
- Open a pull request using the repository template and attach reproducible evidence.
- Resolve review findings and rerun affected checks after every material update.
- Merge only when approvals and required checks are current and successful.
- Release and deploy through the approved process, verify the result, and retain evidence.
See Development Flow for the complete lifecycle.
The following Cubewise Asia repositories informed this guide:
- fastapi_template: the baseline Python service layout, editable development installation,
pyproject.tomlconfiguration, YAPF/isort/pre-commit, external configuration, and packaging conventions.
These repositories are implementation references, not evidence that every historical implementation satisfies every control in this guide. Repository-specific commands and architecture remain authoritative for that repository.
Git history, pull requests, reviews, required-check results, release records, risk acceptances, and incident records are controlled records. They MUST be accurate, access-controlled, retained according to the approved retention policy, and never fabricated or edited to hide a failure.
At minimum, a pull request MUST preserve:
- the linked issue or change record;
- the risk classification and security/privacy assessment;
- the reviewed diff and reviewer identity;
- commands or jobs run and their results;
- migration, deployment, monitoring, and rollback notes where applicable;
- accepted exceptions, residual risks, and follow-up issues.
Changes to mandatory controls require an issue, impact assessment, independent Engineering review, and ISMS-owner review. Control-removal changes MUST explain the risk, replacement control, affected repositories, and transition plan. Editorial corrections MAY use the standard documentation workflow.