Secure Development Policy
This policy describes how Bunker designs, writes, tests and ships the code that runs its platform. On the development dimension, it implements the principles of our information security policy and covers controls A.5.8 and A.8.25 to A.8.31 of the Statement of Applicability.
Our controls are self-assessed, aligned with ISO/IEC 27001, not certified by a third party to date. The status of each measure below reflects that self-assessment.
Purpose and scope
This policy applies to all the code we write and deploy: the control plane, the admin console, the nuage CLI, the SDK, as well as the Helm charts and the infrastructure described as code. It also covers the continuous integration pipeline that validates and promotes those changes. It applies to employees, contractors and any external contribution.
Principles
- Security is decided up front. Structural choices (authentication, authorisation, cryptography) are captured in a written architecture decision before they are coded, not patched in afterwards.
- Fail closed. Where there is doubt, an error or an unavailable security component, the code denies access rather than granting it.
- The language does part of the work. The core of the platform is written in a memory-safe language, which removes whole classes of vulnerabilities instead of chasing them one by one.
- What is not tested is not guaranteed. Security properties are expressed as assertions that run on every change, not as good intentions in a document.
- No production data outside production. Test datasets are synthetic; qualification and production share neither clusters nor credentials.
Measures
| Area | Measure |
|---|---|
| Life cycle | Lifecycle governed by documented architecture decisions, a multi-stage continuous integration pipeline and automated code review on every merge request (A.8.25). |
| Application requirements | Security requirements explicitly specified (fail-closed behaviour, anti-CSRF, anti-replay) and enforced in the authentication code (A.8.26). |
| Architecture | Defence in depth: confidential client, fine-grained relationship-based authorisation, encryption at rest, per-tenant isolation, pod hardening (A.8.27). |
| Coding | Blocking lint, memory-safe language (Rust) for the platform core, coding guardrails: a compile-time guard preventing any mock component in production, key zeroization, secret redaction in logs (A.8.28). |
| Testing | Unit, authorisation, integration and manifest-security tests run in continuous integration as acceptance gates (A.8.29). |
| Environments | Distinct clusters and namespaces between qualification and production, separate credentials, production promotion restricted to the main branch (A.8.31). |
| Pipeline | Security built into the pipeline: blocking secret scanning, then infrastructure-as-code and dependency scanning (A.5.8). |
| Outsourced development | Development mostly in-house; any external contribution goes through the same validation chain as internal code (A.8.30, partial). |
Responsibilities
- The CISO (François-Guillaume Ribreau) owns this policy and the security requirements that apply to the code.
- Everyone who submits code is accountable for the security of what they propose and bypasses no blocking acceptance gate.
- Any weakness found in the code or in the delivery chain is reported without delay to [email protected].
Status and roadmap
The development life cycle, application security requirements, architecture, secure coding, security testing and environment separation are in place and operational (A.8.25–A.8.29, A.8.31, A.5.8). Outsourced development remains partial (A.8.30). Development is mostly in-house today and the acceptance criteria for an external contribution are still to be formalised.
Two additions concern the pipeline itself and are detailed in our vulnerability management policy, namely automated CVE detection (A.8.8) and anti-malware image scanning (A.8.7), both still to be wired into CI. Branch-protection settings (A.8.4) remain to be documented, as stated in our change management policy.
Review
This policy is reviewed at least once a year and whenever our development or delivery chain changes significantly.
Last reviewed: 31 August 2026.
See also
- Statement of Applicability (the status of controls A.5.8 and A.8.25–31)
- Change Management Policy (how a change travels from merge request to production)
- Vulnerability Management Policy (how published flaws and dependencies are handled)
- Security model (the defence layers this development cycle implements)
- Information Security Policy (the ISMS framework this policy derives from)