For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt — this page is also available in markdown by appending .md to the URL.
Security is built into how we ship, not bolted on afterward. Every change to Coverbase flows through a secure software-development lifecycle (SDLC) with mandatory review and automated quality and security gates before it reaches production.
Change management
Peer review required
All code changes are made on branches and merged through pull requests. Changes require review and must pass automated checks before merge to the main branch.
Protected main branch
The production branch is protected. Direct pushes are disallowed; merges go through review and a green check suite.
Traceable history
Every change is attributable to an author and a reviewer, with linear, auditable history from commit to deploy.
Controlled releases
Deployments are automated through CI/CD, so what runs in production is exactly what was reviewed and built.
Automated quality and security gates
Every pull request runs an automated check ladder before it can merge:| Gate | What it enforces |
|---|---|
| Type checking | Static type analysis across all services (backend and frontend) catches whole classes of defects before runtime. |
| Linting and formatting | Enforced style and lint rules keep the codebase consistent and flag risky patterns. |
| Automated tests | Unit, integration, and end-to-end suites must pass. |
| Dependency scanning | Third-party dependencies are scanned for known vulnerabilities and kept current. |
| Secret scanning | Automated scanning blocks credentials and secrets from being committed. |
Dependency and supply-chain hygiene
- Dependencies are pinned and their lockfiles are checked in CI, so the build is reproducible and a dependency cannot change underneath us silently.
- Known-vulnerable dependencies are surfaced and upgraded on a priority basis.
- CI/CD runs with least-privilege credentials scoped to the task at hand.