> ## Documentation Index
> Fetch the complete documentation index at: https://docs.botbrains.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Secure Development Policy
> Secure Development Policy embeds security into our software development lifecycle, code review, testing, and deployment
export const PolicyVersion = ({version, effective}) => Version {version} ยท Effective {effective}. Change history is tracked in version control.
;
The Secure Development Policy embeds security into every stage of how botBrains designs, builds, tests, and ships software. It defines our secure development lifecycle, secret handling, dependency scanning, change controls, and deployment gates so that security is a property of the system, not an afterthought.
botBrains is **not yet ISO 27001 certified**. We are preparing our ISMS and writing these policies as part of pursuing certification, and we fully intend to get our controls attested.
## Scope
This policy applies to all botBrains source code, infrastructure-as-code, and configuration that builds or runs the customer service AI product. It covers both team members and any contracted developer.
## Secure development lifecycle
botBrains follows a lightweight, iterative lifecycle suited to a two-person remote team. Each change moves through the same stages.
| Stage | What happens |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Design.** | botBrains considers security requirements up front for changes that touch authentication, tenant isolation, customer data, or model inference. |
| **Build.** | Developers apply the mandatory practices in the [Employees Only: Secure Coding Standards](https://app.notion.com/p/391481da93cf81c4a39cf1ea90ed0079), namely input validation, output encoding, parameterized queries, server-side authorization, and keeping secrets out of source, aligned with the OWASP Top 10, and commit to a private GitHub repository. Developers complete an annual secure-coding refresher aligned to the current OWASP Top 10 to keep these standards fresh. |
| **Verify.** | Automated tests and CI/CD checks run on every change, including static application security testing (SAST) and secret scanning as pipeline gates. Tests run outside production against staging or local environments. |
| **Deploy.** | Changes ship through the CI/CD pipeline after validation in a separate staging environment. |
Secure engineering principles apply throughout: least privilege, defence in depth, logical multi-tenant isolation by tenant ID, and secure defaults. botBrains protects account and conversation data per the [Data Classification Policy](/trust/policies/data-classification-policy).
## Source code and secret handling
botBrains hosts all source code in **private GitHub repositories**. The platform restricts access by role and protects it with multi-factor authentication, as defined in the [Access Control Policy](/trust/policies/access-control-policy).
botBrains never commits secrets such as API keys, database credentials, and signing keys to source control. If a secret is ever committed, botBrains rotates it immediately and handles the exposure under the [Incident Management Policy](/trust/policies/incident-management-policy). The platform injects secrets at deploy time through environment variables and provider secret stores, and the team shares them through the company password manager. The [Cryptography Policy](/trust/policies/cryptography-policy) defines encryption standards for the data the application handles.
## Dependency scanning
**Automated dependency scanning** (Dependabot) continuously monitors third-party dependencies on the GitHub repositories. botBrains triages and remediates findings through the [Vulnerability Management Policy](/trust/policies/vulnerability-management-policy), which sets severity-based remediation timelines.
## Code review and change approval
botBrains operates as a small team, which makes a mandatory independent second approval on every change impractical today. We treat this as a known segregation-of-duties gap and apply compensating controls rather than claim a control we don't run.
| Control | How it compensates |
| ----------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **CI/CD gates.** | Automated tests, build checks, and dependency scanning must pass before a change can deploy. |
| **Post-merge review.** | The second team member reviews significant changes after merge, and the team reviews material changes before wide rollout. |
| **Automated scanning.** | Dependency and configuration scanning catches known-vulnerable code paths without a human reviewer. |
botBrains intends to make pull-request review with a second approval mandatory as the team grows. Change management for production is governed by the [Operations Security Policy](/trust/policies/operations-security-policy).
## Environment separation and deployment
botBrains maintains separate **local, staging, and production** environments. Production runs on Hetzner servers with data stored in AWS, as listed in our [subprocessors](/trust/subprocessors). Development and testing never use the production environment.
botBrains uses synthetic or anonymized data for development and testing. Production data may enter a non-production environment only in exceptional cases, and each use requires prior CISO approval, tokenization or anonymization of the data, restriction to need-to-know access, and secure erasure once the work completes. Deployments are automated, repeatable, and reversible, with the ability to roll back a failed change.
## ISO 27001 mapping
This policy supports Annex A controls 8.25 (secure development lifecycle), 8.26 (application security requirements), 8.27 (secure system architecture and engineering principles), 8.28 (secure coding), 8.29 (security testing in development and acceptance), 8.30 (outsourced development), and 8.31 (separation of development, test, and production environments).
## Review
The CISO owns this policy and reviews it at least annually and whenever a material change to our development process, tooling, or team size occurs.