59 lines
2.0 KiB
Markdown
59 lines
2.0 KiB
Markdown
# Secure Development Lifecycle (SDLC) — CapaKraken
|
|
|
|
> Version: 1.0 | Date: 2026-03-27
|
|
|
|
---
|
|
|
|
## Development Workflow
|
|
|
|
```
|
|
Feature Branch -> Pull Request -> CI Pipeline -> Code Review -> Merge to main -> Deploy
|
|
```
|
|
|
|
## CI Pipeline (Quality Gates)
|
|
|
|
Every pull request must pass:
|
|
|
|
1. **TypeScript strict check**: `pnpm --filter @capakraken/web exec tsc --noEmit`
|
|
2. **Linting**: `pnpm lint` (ESLint with strict rules)
|
|
3. **Unit tests**: `pnpm test:unit` (Vitest, engine + staffing packages)
|
|
4. **E2E tests**: Playwright tests for critical user flows
|
|
|
|
## Security Gates
|
|
|
|
| Gate | Tool | Stage |
|
|
|------|------|-------|
|
|
| Type safety | TypeScript strict mode | Build |
|
|
| Input validation | Zod schemas on all tRPC procedures | Build + Runtime |
|
|
| Dependency vulnerabilities | Dependabot + `pnpm audit` | PR + Weekly |
|
|
| Audit logging | `createAuditEntry()` required for data mutations | Code review |
|
|
| RBAC enforcement | `requirePermission()` on new procedures | Code review |
|
|
| No hardcoded secrets | PR review checklist | Code review |
|
|
| SQL injection prevention | Prisma ORM (parameterized queries only) | Architecture |
|
|
|
|
## PR Review Checklist
|
|
|
|
See `.github/PULL_REQUEST_TEMPLATE.md` for the security checklist that must be completed on every PR.
|
|
|
|
## Branch Protection
|
|
|
|
- Direct pushes to `main` are blocked
|
|
- Minimum 1 approval required
|
|
- CI must pass before merge
|
|
- Force-pushes to `main` are prohibited
|
|
|
|
## Secret Management
|
|
|
|
- No secrets in source code
|
|
- Environment variables for all credentials (`DATABASE_URL`, API keys)
|
|
- Runtime application secrets are provisioned outside the application data plane through environment variables or a deployment-time secret manager
|
|
- `SystemSettings` may still contain legacy secret residue during migration, but new secret values must not be written there
|
|
- `.env` files excluded from version control via `.gitignore`
|
|
|
|
## Incident Response
|
|
|
|
1. Identify and contain the issue
|
|
2. Create audit log review for affected timeframe
|
|
3. Patch and deploy fix
|
|
4. Post-mortem documented in `LEARNINGS.md`
|