The beliefs that underpin engineering work at Changineers, and how they apply across the secure software delivery lifecycle.
These are the guiding principles for engineering at Changineers. Engineers reach for them when making design decisions, reviewing pull requests, and approving releases. The task pages elsewhere in this handbook are how each principle becomes operational.
Core principles
Section titled “Core principles”- Shared responsibility. Security, quality, and customer care are everyone’s job.
- Correct by default. Small in size, not in rigour. High-quality work produces high-quality outcomes.
- Minimal everything. Less to maintain means more time on the work that matters.
- Automate by default. Anything that can be automated reliably, we automate.
- Zero trust. No corporate network or perimeter. Trust is granted explicitly, per interaction, and only for what is needed.
- Defense in depth. Security is layered so that one failure doesn’t become a broad one.
In practice
Section titled “In practice”We apply these principles at each phase of building and shipping software.
Planning and design
Section titled “Planning and design”The Solution design phase shapes designs through:
- High-risk areas called out explicitly. Authentication, authorisation, finance, and auditing flagged in the ADR for review.
- Data flows mapped where they matter. Designs that move or store data include the data flow as part of the design work.
- Multi-tenancy treated as first-class. Tenant isolation is an explicit consideration in any design touching data or access.
- Privacy considered for sensitive data. Designs touching PII or PHI include privacy considerations.
- Reversibility considered up front. Irreversible migrations use validation strategies (dual-write, shadow reads) before cutover.
- Decisions are recorded. Every non-trivial design choice produces an ADR; superseded ADRs are kept so the trail is recoverable.
Implementation
Section titled “Implementation”The Shipping code procedures operationalise:
- Secure defaults. Private repos, branch protection on
main, new API surfaces authenticated by default. - Defense in depth on dependencies. Multiple overlapping controls keep vulnerable dependencies out of production. Supply-chain risk weighs into dependency choices.
- Defense in depth on secrets. Secrets are kept out of source by default, with multiple checkpoints to catch any that slip through.
- Static analysis. Every PR is scanned for type, quality, and security issues.
- Infrastructure as code.
All infrastructure is managed in Terraform. Non-production
changes apply on merge to
main; production changes follow the change management process.
Verification
Section titled “Verification”The Penetration testing page describes:
- Independent annual review. External vendor exercises production and supporting AWS infrastructure each year.
- Findings tracked to remediation. Findings land in the Vanta risk register and become Jira security tickets if remediation is needed.
Promotion to production
Section titled “Promotion to production”The Change management page describes:
- Segregation of duties. Branch protection requires the approving reviewer to be different from the author.
- Risk-based review. Each release is individually assessed for risk, with compensating actions planned for higher-risk releases.
- Fail-safe recovery. Reversible changes are rolled back; destructive changes are rolled forward only.
- Accountability. The release PR is the change management record.
- Least privilege at production. Production access is layered, short-lived, and granted only when needed.