Secure Software Development Policy

1. Purpose

Integrates security throughout the Rex Black software lifecycle so that vulnerabilities are prevented, detected, and remediated before they reach customers.

2. Scope

All source code, infrastructure code, build systems, artifacts, and runtime environments Rex Black owns.

3. Lifecycle requirements

3.1 Design

Features with material privacy, security, or legal impact receive a written design doc covering threat model, data flows, and classification of processed data.
Third-party components are evaluated against the Vendor Management Policy before adoption.

3.2 Implementation

Code is TypeScript with strict mode enabled. Variables typed as any are justified or refactored.
Inputs from untrusted sources (HTTP, webhooks, SES, SQS) are validated with zod or equivalent schemas at the boundary.
Output encoding is handled by React/Next.js; ad-hoc HTML/SQL string concatenation is prohibited.
Secrets are read from SSM Parameter Store or the Vault. Never committed, never logged.
Cryptographic operations use approved primitives only (008-cryptography-and-key-management-policy.md).

3.3 Peer review

Every PR is reviewed against the Secure Code Review checklist published by the Security Officer (authentication, authorization, input validation, secrets, logging, error handling).
PRs touching authentication, authorization, crypto, or IaC require Security Officer review.

3.4 Automated checks

CI runs on every PR and blocks merge on failure:

Typecheck (tsc --noEmit).
Lint (next lint).
Unit tests.
Dependency vulnerability scan (npm audit high/critical fails build; weekly Dependabot PRs).
Secret scanning (Gitleaks-equivalent; history scanned on each push).
IaC static analysis (Checkov or Pulumi CrossGuard) for misconfigurations in AWS resources.
License scanning; GPL and other copyleft licenses blocked without Security Officer approval.

3.5 Testing

Unit tests cover critical paths; target ≥ 70% coverage on business logic.
Integration tests verify authorization rules on every sensitive API endpoint.
Annual external penetration test scoped to production.

3.6 Deployment

Deployments are automated by SST on master merge. No manual shell access to production except break-glass.
Canaries / staged rollouts for high-risk changes.
Release notes are generated from PR metadata.

3.7 Post-deploy monitoring

Error rates, latency, and security-relevant metrics feed CloudWatch dashboards. Alarms on anomalies route to on-call per 021-logging-and-monitoring-policy.md.

3.8 Decommissioning

When a feature is retired, its code, tables, and S3 keys are removed. Data is disposed of per the retention schedule.

4. Training

Engineers complete annual secure-coding training covering OWASP Top 10, API security, and AWS security baselines. New hires complete the training in their first 30 days.

5. AI-assisted development

Use of generative AI coding tools is encouraged but:

Rex Black or client source code is only sent to approved AI tools (see 026-ai-acceptable-use-policy.md).
Generated code is reviewed like any other; copy-pasted AI output without review is prohibited.

6. Roles & responsibilities

Role	Responsibility
Engineering	Writes secure code; participates in review.
Security Officer	Maintains checklist; reviews high-risk PRs; owns SAST/DAST.

7. Enforcement & exceptions

Merges that bypass checks (e.g., by disabling CI) trigger a security review and may be rolled back. Exceptions to any step require Security Officer written approval.

8. References

007-change-management-policy.md
018-vulnerability-management-policy.md
026-ai-acceptable-use-policy.md

9. Revision history

Version	Date	Author	Approver	Change
1.0	2026-04-17	S.O.	CEO	Initial policy

Approval

This policy has been reviewed and is hereby approved for the named version and effective date above.


Approved by	Myles Bai
Title	Chief Executive Officer, Rex Black LLC
Email	myles@rexblack.com
Approval date	2026-04-17
Effective date	2026-04-17
Next review due	2027-04-17

Digital signature of record: the CEO's electronic approval is captured in the platform audit log (event kind admin.policy.approved) with hash-chained integrity under the M-C1 control. The hash-chained audit log entry for this document is the canonical signature of record; this printed block exists for print/review convenience.