# Secure Development Policy

**Touch2Sign Ltd**  
**Version:** 1.0  
**Effective date:** 11 July 2026  
**Owner:** Robert — Engineering Lead  
**Approved by:** Robert — CEO / Managing Director  
**Next review:** 11 July 2027

---

## 1. Purpose

Define secure software development practices for the Touch2Sign eSignature and eWitness platform. Ensures that code changes are reviewed, tested, and deployed without introducing avoidable security defects or exposing secrets.

## 2. Scope

Applies to all engineering staff and contractors who:

- Write, review, or deploy application code  
- Modify infrastructure configuration  
- Integrate third-party libraries or APIs  
- Access production or staging environments  

## 3. Secure development principles

1. **Security by design** — consider data classification and threat model in feature design  
2. **Least privilege in code** — API routes enforce tenant isolation and role checks  
3. **Defence in depth** — validate input at boundary; parameterised queries; output encoding  
4. **No secrets in source** — credentials only in Secrets Manager or local gitignored files  
5. **Test before production** — QA sign flow executed before every production release  

## 4. Source code management

### 4.1 GitHub workflow

| Control | Requirement |
|---------|-------------|
| Branch protection | Enabled on `main` and production branches when GitHub org allows |
| Pull requests | Required for merges to `main`; feature branches may commit directly to dev |
| Peer review | **Standard team:** minimum 1 approving review from another engineer. **Solo operator (current):** self-review against [`.github/pull_request_template.md`](../../.github/pull_request_template.md) security triage + automated lint/build/QA — see [SOLO_TEAM_OPERATING_MODEL.md](../SOLO_TEAM_OPERATING_MODEL.md) |
| CI checks | Lint, build, and QA smoke must pass before production deploy |
| Signed commits | Recommended for production merges |

### 4.2 Prohibited in repository

- `.env` files with real credentials (`.env.local` is gitignored)  
- AWS access keys, Stripe secret keys, database passwords  
- Customer production data dumps  
- Private keys or TLS certificates  

If secrets are accidentally committed: rotate immediately, purge from history if needed, follow Incident Response Plan.

## 5. Dependency management

- New npm packages require justification in PR description  
- Prefer well-maintained packages with active security advisories  
- Dependabot alerts triaged per **Vulnerability Management Policy**  
- Lock file (`package-lock.json`) committed and reviewed on dependency changes  
- No packages from untrusted registries without Security Lead approval  

## 6. Security testing before production

Before every production deployment, the releasing engineer completes checks from **`docs/QA_SIGN_FLOW.md`**:

| Area | Minimum verification |
|------|---------------------|
| Authentication | Cognito login, MFA where applicable |
| Signing flow | Create document → send → sign → audit trail |
| Witness flow | eWitness capture if changed |
| Part 11 / PIN | PIN gate, lockout, intent-to-sign if changed |
| WebAuthn / mobile | Platform biometric on supported device if changed |
| Admin routes | Authorisation enforced |
| Regression | No console errors on critical paths |

Results documented in release ticket or deploy checklist.

## 7. Production deployment

Production deployments are performed **only** via the approved scripts:

```bash
bash scripts/rebuild-dev.sh    # development (:4001)
bash scripts/deploy-prod.sh    # production (:4000)
```

| Requirement | Detail |
|-------------|--------|
| Authorisation | Engineering Lead or delegated release manager |
| Change ticket | Linked change record with rollback plan |
| QA evidence | QA_SIGN_FLOW.md checklist attached |
| Timing | Prefer business hours unless emergency |
| Rollback | Previous tagged release identified before deploy |

Ad-hoc manual production changes (AWS console edits) require change log entry and are discouraged — prefer IaC or scripted changes.

## 8. Environment separation

| Environment | Data | Access |
|-------------|------|--------|
| **Local** | Synthetic / anonymised | Developer |
| **Staging** | Synthetic; no production DB copy without approval | Engineering team |
| **Production** | Live customer data | Restricted; MFA required |

Production database must not be used for development or demo purposes.

## 9. API and application security

Engineering teams must:

- Use parameterised SQL — no string concatenation for queries  
- Validate and sanitise all external input (signing tokens, webhooks, uploads)  
- Enforce authentication and authorisation on every API route  
- Log security-relevant events to `audit_log` without logging secrets or PINs  
- Set secure HTTP headers (CSP, HSTS where applicable)  
- Limit file upload types and sizes for document ingestion  

## 10. Security issue reporting

Internal discovery:

- Report to Security Lead or security@touch2sign.com  
- Do not disclose externally until remediated and coordinated  

External reports handled per Vulnerability Management Policy secure disclosure process.

## 11. Training

Engineers complete secure coding awareness as part of **Security Awareness Training**. Role-specific topics: OWASP Top 10, tenant isolation, secrets handling.

## 12. Related documents

- Vulnerability Management Policy  
- Change Management Policy  
- Cryptography & Key Management Policy  
- QA_SIGN_FLOW.md  
- Access Control Policy  

## 13. Review

Reviewed **annually** and after security-related production incidents.

---

**Approval**

| Name | Role | Signature | Date |
|------|------|-----------|------|
| Robert | CEO / Engineering Lead | Electronic | 11 July 2026 |