Secure Software Development Lifecycle Policy¶
Classification: Internal
Document status: Effective
Version: 2.2
Owner: Management / Security Owner
Review cycle: Annual; interim revision upon material change to delivery methods, customer platforms, or tooling
Document control¶
| Role | Name |
|---|---|
| Prepared by | Management / Security Owner (Cloudnaut) |
| Reviewed by | Nidhi Jain (third-party reviewer) |
| Approved by | Sandeep AC |
Revision history¶
| Version | Date | Summary | Reviewed by | Approved by |
|---|---|---|---|---|
| 0.9 | 2021-03-14 | Draft for third-party review prior to first effective release. | Nidhi Jain (third party) | — |
| 1.0 | 2021-06-18 | Initial effective release. | Nidhi Jain (third party) | Sandeep AC |
| 1.0 | 2024-03-11 | Scheduled annual review; clarifications (retained at version 1.0). | Nidhi Jain (third party) | Sandeep AC |
| 1.1 | 2025-09-02 | Supply-chain scanning and design-assurance alignment. | Nidhi Jain (third party) | Sandeep AC |
| 2.0 | 2026-05-14 | Major revision: Agile, risk-tiered SDLC for small teams and manual QA. | Nidhi Jain (third party) | Sandeep AC |
| 2.1 | 2026-05-19 | Q-4 alignment: five-pillar SSDLC mapping, CI/CD integration, Sonar SAST, pre-deployment assessment. | Nidhi Jain (third party) | Sandeep AC |
| 2.2 | 2026-05-19 | Mandatory CI/CD guardrails, continuous scanning, formalized design/threat artifacts; reviewer-facing language. | Nidhi Jain (third party) | Sandeep AC |
Purpose¶
Cloudnaut operates a formalized, risk-adjusted Secure Software Development Lifecycle (SSDLC) with security embedded in CI/CD pipelines, automated branch protection, and continuous static analysis—not ad hoc or optional checks. Risk classification (Routine, Elevated, Material) scales documentation and review depth, not whether core controls run.
This policy is the authoritative baseline for how security is mandated across engineering work. Delivery follows an Agile operating model (iterations, backlog, incremental release) with manual QA for behavioral validation and pipeline-enforced controls for merge and scan discipline.
For vendor and audit questionnaires, the Agile operating model and change-risk tiers in this document may be cited collectively as the Cloudnaut Agile Operating Model and Change-Risk Policy (this policy, current version).
Scope¶
This policy applies to application code, scripts, Terraform, Terragrunt, AWS CDK, CloudFormation, comparable infrastructure-as-code, configuration, and technical deliverables produced for customers.
Work is engagement-scoped: repositories, identities, and branches follow customer or engagement definitions. When a customer statement of work, security addendum, or prime contractor requires stricter SDLC steps, tooling, or evidence, those requirements take precedence for that engagement; this policy is the baseline and must still be satisfied where it is not superseded.
Related policies (this document does not duplicate their full text):
- Code Security Scanning Policy — Dependabot, Snyk, Sonar, CI/CD scan gates, triage expectations.
- Customer Deliverable Development and Review Policy — review, release, and handover.
- Approved Development Tools and Plugin Policy — IDE, plugins, repository isolation.
- Engagement Access Isolation Policy — separation across engagements and customers; CI/CD role scoping.
- Data Handling Policy — regulated and sensitive data.
Team model¶
- Engineering owns implementation, peer review, merge discipline, and triage of automated findings in the normal PR path.
- Manual QA validates behavior against acceptance criteria, performs regression and exploratory testing, and—where the work item warrants—exercises security-relevant scenarios (for example authorization boundaries, error handling, and data visibility). There is no policy requirement for Cloudnaut to operate a dedicated automated DAST or mobile lab unless a customer contract mandates it.
- Automated security tooling (SAST, dependency and composition scanning) is repository- and CI/CD-integrated per the Code Security Scanning Policy—not a separate “security team queue” disconnected from developers’ daily workflow.
- Roles may overlap on engagements (author, reviewer, tester). Compensating controls are mandatory peer review, branch protection, CI/CD quality gates, transparent artifacts in tickets and PRs, and risk-tier scaling below.
Established SSDLC controls (overview)¶
Cloudnaut’s SSDLC applies mandatory pipeline and merge guardrails on every engagement repository (branch protection, peer review, continuous SAST/SCA in CI/CD). Design and threat artifacts scale by tier—Routine changes use the same automated gates with lighter documentation; Elevated and Material changes add structured architectural review and formalized threat-modeling notes before implementation.
The framework comprehensively covers application code and Infrastructure-as-Code (IaC) deliverables through these established phases (detailed in the sections below):
| Phase | Section |
|---|---|
| Risk assessment and design review | Risk assessment and design review |
| Threat modeling | Threat modeling |
| Static analysis (SAST and SCA) | CI/CD security integration; Code Security Scanning Policy |
| Security testing and peer code review | Security testing and peer code review |
| Security assessment and secure configuration | Pre-deployment security assessment and secure configuration |
Agile operating model¶
Security expectations are embedded in existing Agile ceremonies and artifacts. Naming is intentionally generic (backlog, iteration, sprint) so the team can map to Scrum, Kanban, or a hybrid.
| Ceremony / practice | Security expectation |
|---|---|
| Backlog refinement | Call out data sensitivity, new external attack surface, authentication or authorization changes, privilege or production access, new third-party or SaaS dependency, and cross-engagement access risks. Assign or confirm a change-risk tier (see below). |
| Iteration / sprint planning | Reserve capacity for review, scan triage, and manual QA on items that carry Elevated or Material tier. Do not treat security work as only “end of project.” |
| Daily work | Prefer small, reviewable changes. Surface security questions early in the ticket or PR description rather than deferring to a separate document unless tier requires it. |
| Sprint / iteration review and retrospective | Discuss near misses, confusing access, or customer feedback that hints at control gaps; feed improvements into the next refinement (lightweight continuous improvement). |
Change-risk tiers (proportionality)¶
Every substantive change has a tier chosen honestly at refinement or before implementation. Tiers drive minimum artifacts, not headcount.
Routine (Tier A)¶
Typical work: bug fixes, refactors with no security boundary movement, internal-only scripts, documentation, minor config with no new exposure or secrets.
Minimum: engagement-approved repository with branch protection and pull-request-only merge to protected branches; at least one peer approval; secrets hygiene; continuous SAST and SCA in CI/CD per the Code Security Scanning Policy; manual QA when the engagement Definition of Done requires QA (docs-only items may record “QA not applicable” with rationale).
Additional documentation not required: standalone architecture specification, formal STRIDE workshop, or separate security-committee gate—unless the customer contract requires them.
Elevated (Tier B)¶
Triggers (non-exhaustive): new or changed authentication or session behavior; authorization rule changes; new network exposure (public endpoint, CORS, webhook); PII or regulated data in scope; high-privilege IaC (IAM, organization policies, production networking); new third-party integration that receives customer code or credentials.
Minimum: everything in Routine, plus a structured architectural review recorded as a formalized design and threat-modeling note (required sections: scope, data flows, trust boundaries, key threats and mitigations, rollback) attached to the ticket or PR before implementation. Reviewers explicitly confirm the note in the PR. Manual QA includes targeted security cases for the trigger (for example role-matrix and IAM least-privilege validation for IaC).
Not required by default: multi-page architecture specification or formal STRIDE workshop—unless the engagement or customer demands it.
Material (Tier C)¶
Triggers (non-exhaustive): large trust-boundary moves; new product surface handling regulated data at scale; organization-wide security patterns; changes that could affect multiple customers from one mistake.
Minimum: everything in Elevated, plus structured design assurance and threat-modeling artifacts (see Threat modeling): documented trust boundaries, identities, credentials, exposure, data classification, rollback, and proportionate threat assumptions—still may live in-repo (for example docs/ ADR, ticket epic, or linked diagram) rather than a separate “security phase.”
Management or the security owner may escalate an Elevated-tier item to Material if uncertainty remains after the formalized note.
CI/CD security integration¶
Security controls are mandatory inside repository CI/CD workflows (for example GitHub Actions, GitLab CI) on every engagement repository Cloudnaut provisions or maintains. Onboarding an engagement includes enabling branch protection, pull-request checks, and the standard scan stack below (or a customer-contracted equivalent documented in the SOW when the customer forbids a named tool but requires an approved substitute).
| Control | Role in CI/CD |
|---|---|
| GitHub Dependabot | SCA on GitHub-hosted repos—dependency and security alerting; update PRs on default configuration. |
| Snyk | SCA—continuous scanning of dependencies and lockfiles; IaC or container surfaces when configured. |
| SonarQube / SonarCloud | SAST—application source analysis on pull requests and protected-branch pipelines. |
Mandatory process expectations:
- Enable Dependabot, Snyk, and Sonar (or documented customer-mandated equivalents) at repository onboarding per the Code Security Scanning Policy—not optional per developer discretion.
- Run scans on every pull request and protected-branch pipeline so findings surface before merge.
- Triage findings in the PR; configured quality gates block merge on agreed severity thresholds until remediation or written customer-approved risk acceptance.
- Scope pipeline roles, OIDC subjects, and deployment keys per engagement workstream per the Engagement Access Isolation Policy.
Automated scans supplement—they do not replace—structured design review, threat modeling, peer review, manual QA, or customer-required tools.
Risk assessment and design review¶
All incoming features undergo security categorization during backlog refinement and iteration planning: data sensitivity, external exposure, authentication and authorization impact, privilege changes, and third-party dependencies. Each item receives a Routine, Elevated, or Material tier (see Change-risk tiers).
Elevated changes require a structured architectural review and formalized design and threat-modeling note (standard sections listed under Threat modeling) before engineering begins, linked from the ticket or PR.
Material changes require the same, plus expanded threat-modeling artifacts (data-flow and trust-boundary diagrams or equivalent) suitable for audit.
Customer or contract stricter requirements (security addenda, prime contractor SDLC, regulated-sector playbooks) automatically override baseline tier triggers and may require additional artifacts or tools.
Artifacts live in the ticket, PR, or repository (docs/, ADR, linked diagram)—prefer living documentation in the repo over one-off decks that go stale.
Threat modeling¶
Threat boundaries are evaluated using the risk-tiered approach below. Artifacts remain proportionate and may live in tickets, PRs, or the repository.
| Tier | Threat modeling expectation |
|---|---|
| Routine | No separate threat-model workshop. Security considerations are documented in the PR description when relevant; CI/CD and branch protection still apply. |
| Elevated | Formalized threat-modeling note (minimum sections: scope, data flows, trust boundaries, threats and mitigations, rollback) as part of the structured architectural review before implementation. |
| Material | Formalized threat-modeling artifact mapping data flows, trust boundaries, and potential attack vectors for the AWS environment (and other platforms in scope), with diagrams or structured tables where complexity warrants. Threat assumptions and mitigations must be reviewable in the PR or linked repository path. |
Engineering covers at minimum for Elevated and Material work: trust boundaries, identities and credentials, network exposure, data classification (aligned with the Data Handling Policy), and rollback or recovery.
Security testing and peer code review¶
No code enters production (or customer handover) without mandatory merge controls on engagement repositories:
- Branch protection on default and release branches—required on engagement repositories Cloudnaut provisions or maintains; on customer-owned repos, Cloudnaut follows customer policy and documents the equivalent control. Configuration requires pull request workflow and blocks direct pushes that bypass review.
- At least one peer approval on every substantive change before merge.
- Reviewers verify functional correctness and, for Elevated and Material tiers, security logic (authorization, data handling, IaC blast radius, alignment with the design or threat note).
Manual and automated test suites include security-relevant test cases scaled by tier—for example horizontal and vertical access checks, negative paths, error handling that must not leak internals, and IAM policy least-privilege review for IaC at Elevated and Material tiers. QA derives cases from acceptance criteria and records notes in the ticket or engagement test tool.
Automated penetration testing or DAST is out of baseline scope unless the customer contract requires it; if required, record tool, scope, and results with release evidence.
Qualified peers perform review; there is no standing rule that only a single named “security officer” may merge. Segregation of duties for high-risk production deploys follows the customer contract where applicable.
Pre-deployment security assessment and secure configuration¶
Before production deployment or customer handover, deliverables undergo pre-deployment verification to confirm alignment with:
- AWS Well-Architected Framework — Security pillar themes (identity, detection, infrastructure protection, data protection, incident response) applied as an engineering checklist, not a formal Well-Architected Review engagement for every release unless the customer or SOW requires one.
- Engagement secure configuration baselines (encryption in transit and at rest, least-privilege IAM, logging and monitoring hooks, network segmentation patterns, secrets excluded from artifacts).
Verification is performed by engineering (and QA when in scope) using the engagement checklist; findings are remediated or risk-accepted per customer process before release.
Release mechanics follow the Customer Deliverable Development and Review Policy: protected branches, approved channels, scan triage complete, and no embedded secrets.
Lifecycle (summary)¶
The table below maps delivery steps to SSDLC pillars without duplicating full control text above.
| Step | Primary pillar(s) | Who / evidence |
|---|---|---|
| Intake and sizing | Risk assessment | Tier recorded on ticket; default up if unclear. |
| Design | Risk assessment; threat modeling | Design or threat note for Elevated/Material before build. |
| Implementation | CI/CD; secure configuration | Engagement repo; secrets hygiene; pipeline scans. |
| Code review and merge | Security testing; static analysis | PR approval; branch protection; scan triage. |
| Manual QA | Security testing | QA notes; security-relevant cases by tier. |
| Pre-deploy check | Security assessment | Well-Architected Security checklist; secure-config baseline. |
| Release and handover | Security assessment | Customer deliverables policy; delivery ticket or tag. |
| Post-release learning | — | Short retro action when SDLC lessons apply. |
Definition of Ready and Definition of Done (lightweight)¶
Definition of Ready (security-relevant bullets):
- Tier identified (or explicit “Routine” with one-line rationale).
- For Elevated / Material: acceptance criteria mention auth, data, or exposure expectations when those apply.
- Dependencies on customer tools, scans, or approvals are visible on the work item.
Definition of Done (security-relevant bullets, scaled by tier):
- PR reviewed and merged per change-control and branch protection rules.
- No known unresolved critical dependency, SAST, or SCA finding in the release scope unless customer-approved risk acceptance exists (see Code Security Scanning Policy).
- Manual QA completed when QA is in scope for the item; gaps explicitly documented if time-boxed exploratory testing could not finish.
- Elevated / Material design or threat note linked from the PR or release record.
- Pre-deployment security assessment completed for releases to production or customer handover.
- Delivery path matches Customer Deliverable Development and Review Policy.
Policy requirements (summary)¶
The following non-negotiable baseline requirements apply regardless of tier (unless a customer requirement adds to them):
- Engagement-scoped work in approved repositories and branches—not ad hoc personal or unapproved storage.
- Branch protection and peer-reviewed merge (minimum one approval) for all substantive changes.
- Secrets hygiene—no secrets in source control; approved secret management.
- Continuous SAST and SCA via Dependabot, Snyk, and Sonar integrated into CI/CD on every engagement repository per the Code Security Scanning Policy.
- Pipeline quality gates that block merge on configured critical findings until remediation or written customer-approved exception.
- Pre-delivery triage of security findings, pre-deployment secure-configuration verification, and manual QA when the engagement’s DoD includes QA.
- Delivery only through customer-approved channels (see Customer Deliverable Development and Review Policy).
Tier rules govern additional structured architectural review and threat-modeling depth. Routine work still runs the full automated guardrail stack; higher tiers add formalized design and threat artifacts, not stronger automation alone.
Records and audit trail¶
Cloudnaut maintains a verifiable and repeatable audit trail for every release, collected from how the team already works:
- Pull requests, approvals, and commit history (branch protection enforcement visible in platform audit logs where available).
- CI/CD scan results (Sonar, Snyk, Dependabot dashboards or exports) tied to the merge or release.
- Ticket or board links with tier, design notes, and QA references.
- Linked threat or design artifacts for Elevated and Material work.
- Release tags, customer delivery tickets, or handover records per the Customer Deliverable Development and Review Policy.
- Risk acceptance records when deferral is approved.
There is no requirement to introduce a new enterprise GRC tool for this policy to be satisfied.