# Secure Development Policy

Last updated: October 28, 2026

Every code and infrastructure change goes through the protected main branch, is tested and scanned automatically, and is deployed only through the CI/CD pipeline.

## Scope

Application code, infrastructure as code, database migrations and configuration for the production service.

## Policy

### Change management

1. All changes to application code, infrastructure as code and database migrations are made in version control, and reach production only through the main branch.
2. The main branch is protected: it cannot be deleted or force-pushed, and its history is linear. A pull request merges only with an approving review from the code owner and passing automated tests.
3. The code owner may commit to the main branch directly. Every commit on main, whoever made it, goes through the full CI pipeline (automated tests, dependency scanning, secret scanning, infrastructure scanning and a container image vulnerability scan), and nothing that fails it is deployed.
4. Emergency changes may be merged by a designated engineer without waiting for review. GitHub records each such merge, and the code owner reviews it within 1 business day.
5. Deployments to production run only through the CI/CD pipeline, and the deploy credential can be used only from the main branch. Engineers do not change production by hand except in a declared incident, which is documented afterward.
6. Changes with high risk (authentication, encryption, data residency, permissions) are reviewed with extra care, and their security impact is described in the pull request or commit.

### Secure coding

7. Engineers follow the OWASP Top 10 guidance.
8. Automated checks in CI: dependency vulnerability scanning and secret scanning.
9. Secrets are never committed to repositories; any secret found in code is rotated at once.
10. Customer data is not used in development or testing (Data Management Policy).

### Testing and release

11. Changes include automated tests proportionate to risk; CI must pass before a change is merged through a pull request and before any change is deployed.
12. Changes are tested in staging before production where practical; feature flags and rollback plans are used for risky releases.

### Third-party code

13. Open-source dependencies are pinned, come from trusted registries, and have licenses compatible with commercial use.

### MCP server and APIs

These controls apply to the Summerbase MCP server and public APIs through which customers connect Connected AI Clients (Terms 4.5–4.6).

14. Every request is authenticated with OAuth or an API token tied to one user and one account. Tokens are scoped, read-only by default, revocable by the customer, and expire.
15. Each request is authorized against the user's account and role, so a token can never return another customer's data.
16. Requests are served from the customer's hosting region (EU or US).
17. Access through the MCP server and APIs is logged (user, token, tool or endpoint, time) and rate-limited, with alerts on unusual volume.
18. Prompt injection is treated as a known risk: data returned to an AI client is treated as untrusted, and any write or destructive action through MCP requires explicit user confirmation.
19. New MCP tools and API endpoints get security review as high-risk changes (item 6) before release.