💻 Software Development Lifecycle (SDLC) Controls

1. Purpose

This policy establishes Nemu Inc.’s formal Software Development Lifecycle (SDLC) controls to ensure that software is developed, tested, deployed, monitored, and maintained in a secure, consistent, and high‑quality manner.
These controls reduce operational risk, protect customer data, and ensure regulatory and compliance alignment (SOC 2, ISO‑27001, SIG, and privacy frameworks).

2. Scope

This policy applies to all software components maintained by Nemu Inc., including:

Node.js + Bun backend APIs and microservices
Next.js web applications
Expo mobile applications (where applicable)
Infrastructure‑as‑Code assets, CI/CD automation, build pipelines
Shared internal libraries, queue workers, and background processors
Third‑party integrations, SDKs, scripts, and platform configurations

The SDLC policy is mandatory for all employees, contractors, and contributors with development responsibilities.

2.1 Agile Methodology Adoption

Nemu Inc. follows an Agile SDLC model, enabling iterative development, continuous delivery, and rapid response to customer feedback. Agile practices ensure that product improvements are shipped frequently and safely, while maintaining strong governance and security controls.

Agile Implementation Standards

Work is organized into sprints or delivery cycles with defined goals.
Requirements may evolve iteratively based on customer feedback, business need, or usability findings.
Features are broken into small, incremental releases to reduce risk and accelerate feedback loops.
Sprint planning, backlog refinement, and retrospective meetings are held regularly.
Release versions must meet acceptance criteria before deployment.

Agile Quality & Security Practices

Code is merged frequently to avoid large, risky changes.
Automated testing + CI ensures build health in every iteration.
Production feedback is monitored and fed back into the backlog for improvement.
Risk assessments are performed continuously as features evolve.
Security, compliance, and data privacy remain non‑negotiable controls regardless of sprint velocity.

3. SDLC Phases & Required Controls

3.1 Requirements & Design

Business, functional, and security requirements must be documented before development begins.
Architecture designs consider:
- Data flow, threat surfaces, handling of PII
- Supabase storage, Postgres, RLS‑based access governance
- Render hosting environment with TLS‑encrypted endpoints
- Logging, monitoring, auditing, error‑handling expectations
High‑risk changes require threat modeling or security review.
Third‑party services must undergo vendor risk assessment prior to adoption.

3.2 Development

All source code must reside in version‑controlled Git repositories.
Branch‑based workflows and pull requests are mandatory for all changes.
Code review requirements:
- At least one peer reviewer for standard changes
- Security‑sensitive code requires elevated review
Secure engineering principles enforced:
- No hard‑coded secrets or credentials
- Prepared queries/ORM usage for database operations
- Input validation + output sanitization to prevent injection or XSS
- Sensitive logs masked; PII logging prohibited
Static analysis / linting must execute before merge.

3.3 Testing & Quality Assurance

Automated tests are executed in CI (unit, integration, and E2E when available).
Major releases require regression validation.
Test/Staging environments should mirror production schemas where feasible.
Data used in testing must be anonymized or synthetic.
Performance testing is executed for high‑load or scalability‑impacting features.
Security testing is performed selectively for risk‑bearing changes.

3.4 Deployment & Release Management

CI/CD pipelines handle build, validation, artifact creation, and deployment.
Deployments are fully traceable to commit SHA, author, and timestamp.
Rollback and hot‑fix procedures are documented and periodically tested.
Production secrets stored only in secure environment variables or KMS.
Access to modify production environments requires least‑privilege approval.

3.5 Monitoring, Maintenance & Post‑Release Governance

Production logs, health checks, rate‑limits, and alerts are monitored continuously.
Vulnerabilities, technical debt, and runtime upgrades tracked and remediated.
Dependency patching follows security advisory alerts and scheduled review cadence.
Backup integrity and restore tests are performed periodically.
Post‑incident analysis is required after outages or security events, including:
- Root cause summary
- Containment & corrective actions
- Preventative future measures

4. Roles & Responsibilities

Role	Responsibilities
Engineering Team	Development, review, testing, deployment, remediation
Security Lead	Approves high‑risk changes, ensures secure coding & privacy controls
Product Owners	Define business requirements and release acceptance
DevOps/SRE (if applicable)	Manages CI/CD, observability, infrastructure governance

Access and permissions must align with least privilege and are reviewed at least quarterly.

5. Audit Evidence Examples

GitHub pull request history + reviewer approvals
CI/CD pipeline execution logs, build artifacts, deployment traceability
Automated test results and coverage reports
Documentation of security review outcomes
Runbook and incident‑response records

6. Compliance Alignment

SOC 2: CC3.2, CC5.2, CC7.1, CC7.2, CC7.3
ISO 27001:2022: A.5, A.6, A.8, A.12, A.14, A.18