Secure Development Lifecycle Policy

Governs how security is built into Finaisse's development process, and how vulnerabilities are found and remediated. Subordinate to the Information Security Policy.

Policy owner	Security & Infrastructure Owner (Sekhar Prakash)
Applies to	All development on blitz, blitz-ui, fin-infra
Effective	2026-08-19 (v0.1 draft)
Review cadence	Annual + on major change
SOC 2	CC7.1, CC8.1

1. Purpose

Identify and address security weaknesses as early in development as practical ("shift left"), and maintain a disciplined vulnerability-management process.

2. Design

• Significant new capabilities receive a security review before implementation. Capabilities touching authentication, tenant boundaries, financial data, or AI receive dedicated review — these are Finaisse's highest-risk areas.
• Security requirements are captured alongside functional requirements.

3. Development controls

Control	Status
Peer-reviewed PRs, no direct-to-main for changed code	🟠 PR required and no direct push to main: enforced. Peer review: by convention only (0 required approvals). See Change Management
Reproducible builds — committed lockfiles + --frozen-lockfile guard in CI	✅
Secrets kept out of source (env/secret store only)	✅ policy; 🎯 secret-scanning gate to enforce
Dependency (SCA) scanning	🟠 ad-hoc; 🎯 CI gate (F-31)
Secret scanning (history + push protection)	🟠 ad-hoc; 🎯 CI gate + push protection
Container image scanning	🟠 ad-hoc; 🎯 CI gate, block on critical (F-20)
IaC scanning (Terraform)	🟠 ad-hoc; 🎯 CI gate
SAST (static code analysis)	🔴 never run; 🎯 adopt (tooling is an open decision)

Tooling choices (GitHub Advanced Security vs OSS Semgrep/gitleaks) are open owner decisions because of the paid-vs-free trade-off on private repos.

4. Testing & validation

• Security regression is avoided by tracking fixed findings to closure in the register.
• 🎯 Target — DAST integrated as a release gate (coverage).
• 🎯 Target — annual independent penetration test covering application, API, infrastructure, and AI/LLM surfaces, plus a vulnerability-disclosure path (F-24). Vendor/budget/timing is an open decision.

5. Vulnerability management & remediation SLAs

Findings are severity-ranked (P0/P1/P2) in the register and remediated within target timelines:

Severity	Meaning	Target remediation
P0	Exploitable now / hits Restricted data or tenant boundary	≤ 7 days; hard blocker for production
P1	High impact / on the go-live path	≤ 30 days
P2	Real weakness, constrained conditions	≤ 90 days

No P0 finding may be open (🔴) at AWS production go-live (see AWS gate).

6. Platform hardening

• Containers run from minimal base images; 🎯 Target — enforce non-root execution, drop unnecessary capabilities, and pin image digests (moving off :latest) (F-20).
• 🎯 Target (AWS) — configuration against CIS benchmarks with drift detection (Domain 9).

Revision history

Version	Date	Author	Change
0.1	2026-08-19	Security & Infrastructure Owner	Initial draft
0.2	2026-09-24	Security & Infrastructure Owner	Peer-review control ✅ → 🟠: PRs are enforced, review is not (0 required approvals).