Secure Development Lifecycle Policy

1. Purpose

This policy defines how security is built into the Cadence development process — from the first line of a new feature through deployment — rather than checked for only after the fact. It works alongside the Change Management Policy (CMP-2026-01), which covers process and release mechanics; this document covers the security-specific practices applied while writing code.

Cadence is developed by a single-person engineering team. This policy is scoped accordingly: automated tooling and a personal pre-ship checklist stand in for a formal security review board, matching the compensating-controls model already established in CMP-2026-01 Section 8.

2. Automated Controls (every push)

PHP syntax lint — every changed file, on every push.
Semgrep SAST — static analysis for common vulnerability patterns (injection, unsafe deserialization, hardcoded secrets, etc.), full repo scan on every push.
Trivy CVE scanning — repo filesystem scan plus the two base images Cadence actually runs in/against (MariaDB, SWAG), on every push.

All three run via GitHub Actions (.github/workflows/ci.yml) and are visible in the repo's Actions tab for every commit.

3. Manual Pre-Ship Security Checklist

Before shipping any feature or fix that touches data access, user input, authentication, or file handling, run through this checklist. It is a personal discipline check, not a sign-off gate — its value is in being asked every time, consistently, rather than from memory.

SQL injection — every query touching user input uses parameterized queries (PDO prepared statements), never raw string interpolation. XSS — every value rendered into HTML is escaped (htmlspecialchars) at output time, including values pulled from the database that originated as user input. IDOR — every endpoint that accepts a record ID checks that the requesting user is actually authorized for that specific record (own scope/company/patient), not just that they're logged in. Auth/role checks — every new page and API action explicitly checks the caller's role before doing anything sensitive, rather than relying on the UI simply not showing a button. CSRF — state-changing requests go through the existing CSRF token mechanism (auto-injected per _auth.php), not exempted without a specific reason. Secrets — no live credential, API key, or token is ever hardcoded into a file written to disk or committed to git; secrets are read from app_settings/.env at runtime. File uploads — MIME type validated, stored outside the web root or behind an authenticated serving script, never executed directly. Test-instance-first — verified on scheduler (or a throwaway container) before touching arc or a client's production data, per CMP-2026-01 Section 3.

4. Dependency & Third-Party Code

Cadence has no application-level dependency manager (no composer.json) as of this writing — all code is first-party. If dependencies are introduced in the future, Trivy's filesystem scan (already running) will catch known CVEs in them automatically; no separate process is needed to activate that coverage.

5. Review Cadence

This policy is reviewed annually and whenever CI tooling changes materially (a new scanner added, a check removed). Its checklist is also referenced from the Internal Audit Program's (IAP-2026-01) quarterly review — "confirm CI is green and no suppressed findings have accumulated" — so drift is caught even between annual reviews.