Secure Software Development Lifecycle (SDLC) Policy
Document owner: VP Engineering, with CISO as co-owner
Version: 3.0
Effective date: January 1, 2026
Last updated: January 15, 2026
Classification: Public — Trust Center
Review cadence: Annual review; updates for significant methodology changes
Company: Acme Cloud, Inc.
Address: 1200 Market Street, Suite 400, San Francisco, CA 94103, USA
Primary contacts: trust@acmecloud.com | security@acmecloud.com | privacy@acmecloud.com
Definitions and Key Terms
| Term | Definition |
|---|
| SDLC | Software Development Lifecycle — the structured process encompassing all phases of software creation from conception through retirement |
| Secure SDLC | Integration of security practices throughout the software development lifecycle to identify and mitigate vulnerabilities early |
| Threat Modeling | A structured approach to identifying, quantifying, and addressing security threats to a system or application |
| Static Application Security Testing (SAST) | Automated analysis of source code to identify security vulnerabilities without executing the program |
| Dynamic Application Security Testing (DAST) | Automated security testing of running applications to identify vulnerabilities through simulated attacks |
| Software Composition Analysis (SCA) | Analysis of third-party and open source components to identify known vulnerabilities and license issues |
| Penetration Testing | Authorized simulated cyberattack to evaluate security by attempting to exploit vulnerabilities |
| Code Review | Systematic examination of source code to identify defects, security issues, and adherence to standards |
| Pull Request (PR) | A method of submitting contributions to a codebase for review before merging |
| CI/CD | Continuous Integration/Continuous Deployment — automated processes for building, testing, and deploying software |
| Secrets Management | Practices for securely storing, accessing, and managing sensitive credentials, keys, and tokens |
| Dependency | External software libraries, frameworks, or packages used by an application |
| Vulnerability | A weakness in software that can be exploited to compromise security |
| CVE | Common Vulnerabilities and Exposures — standardized identifiers for known security vulnerabilities |
| CVSS | Common Vulnerability Scoring System — a framework for rating vulnerability severity |
| OWASP | Open Web Application Security Project — an organization providing security guidance and resources |
| Security Champion | A development team member who acts as a liaison between security and development teams |
| Secure Coding | Development practices that minimize security vulnerabilities in software |
| Input Validation | The process of verifying that user input meets expected criteria before processing |
| Output Encoding | Converting potentially harmful characters in output to safe representations |
| Parameterized Queries | Database queries that separate SQL code from data to prevent injection attacks |
| Infrastructure as Code (IaC) | Managing and provisioning infrastructure through machine-readable configuration files |
Scope and Purpose
This Secure Software Development Lifecycle (SDLC) Policy establishes Acme Cloud, Inc.'s requirements, processes, and controls for developing secure software throughout the entire development lifecycle. The policy scope encompasses all software developed by Acme Cloud, including customer-facing applications, internal tools, APIs, infrastructure configurations, and automation scripts. The purpose is to ensure that security is integrated into every phase of software development, reducing vulnerabilities, protecting customer data, meeting compliance requirements, and maintaining the trust that customers place in our platform.
Applicability
| Scope Element | Included | Examples |
|---|
| Customer-Facing Applications | Yes | Web application, mobile apps, public APIs |
| Internal Applications | Yes | Admin tools, internal dashboards, automation |
| APIs and Services | Yes | REST APIs, GraphQL endpoints, microservices |
| Infrastructure as Code | Yes | Terraform, CloudFormation, Kubernetes manifests |
| CI/CD Pipelines | Yes | GitHub Actions, deployment scripts |
| Libraries and SDKs | Yes | Shared components, customer SDKs |
| Configuration Files | Yes | Application config, feature flags |
| Documentation | Limited | Security-relevant documentation |
SDLC Phases and Security Integration
Phase Overview
| Phase | Security Activities | Key Outputs | Responsible |
|---|
| Requirements | Security requirements gathering; threat assessment | Security requirements document | Product + Security |
| Design | Threat modeling; security architecture review | Threat model; secure design | Engineering + Security |
| Development | Secure coding; peer review; SAST | Reviewed code; SAST results | Engineering |
| Testing | Security testing; DAST; penetration testing | Security test results | QA + Security |
| Deployment | Secure deployment; configuration review | Deployment checklist | SRE + Engineering |
| Operations | Vulnerability management; incident response | Vulnerability reports | SRE + Security |
| Maintenance | Patching; dependency updates; security reviews | Update records | Engineering |
Phase 1: Requirements
Security must be considered from the earliest stages of software planning to ensure security requirements are captured and prioritized alongside functional requirements.
| Activity | Description | Owner | Artifacts |
|---|
| Security Requirements Identification | Identify security requirements based on data sensitivity, compliance needs, and threat landscape | Product Manager + Security | Security requirements list |
| Compliance Mapping | Map requirements to applicable compliance frameworks (SOC 2, HIPAA, GDPR) | Security | Compliance checklist |
| Data Classification | Classify data types that will be processed, stored, or transmitted | Product Manager | Data classification matrix |
| Risk Pre-Assessment | Initial risk evaluation for proposed functionality | Security | Risk assessment notes |
| Privacy Assessment | Evaluate privacy implications; determine if DPIA required | Privacy Officer | Privacy assessment |
Phase 2: Design
Secure design practices ensure that security is built into the application architecture rather than bolted on later.
| Activity | Description | Owner | Artifacts |
|---|
| Threat Modeling | Systematic identification of potential threats and mitigations | Engineering + Security | Threat model document |
| Security Architecture Review | Review proposed architecture for security weaknesses | Security | Architecture review notes |
| Authentication Design | Design authentication mechanisms per standards | Engineering | Auth design document |
| Authorization Design | Design access control model and permissions | Engineering | Authorization matrix |
| Cryptographic Design | Design encryption and key management approach | Engineering + Security | Crypto specification |
| Third-Party Component Review | Security assessment of proposed external dependencies | Engineering | Dependency assessment |
Threat Modeling Methodology
Acme Cloud uses a STRIDE-based threat modeling approach for significant features and architectural changes.
| STRIDE Category | Threat Type | Example | Typical Mitigations |
|---|
| Spoofing | Identity impersonation | Stolen credentials, session hijacking | MFA, session management, token binding |
| Tampering | Data modification | Parameter tampering, message modification | Input validation, integrity checks, signing |
| Repudiation | Deniable actions | Unauthorized action without evidence | Audit logging, digital signatures |
| Information Disclosure | Unauthorized data access | Data leaks, verbose errors | Access controls, encryption, error handling |
| Denial of Service | Availability attacks | Resource exhaustion, floods | Rate limiting, redundancy, capacity planning |
| Elevation of Privilege | Unauthorized access escalation | Privilege escalation, authorization bypass | Least privilege, authorization checks |
Phase 3: Development
Secure coding practices during development prevent vulnerabilities from being introduced into the codebase.
| Activity | Description | Owner | Artifacts |
|---|
| Secure Coding | Follow secure coding standards and guidelines | Developers | Source code |
| Code Review | Peer review of all code changes | Engineering team | PR approvals |
| Static Analysis | Automated SAST scanning during development | CI/CD | SAST reports |
| Dependency Scanning | SCA analysis for vulnerable dependencies | CI/CD | SCA reports |
| Secrets Scanning | Automated detection of hardcoded secrets | CI/CD | Secrets scan reports |
| Security Champion Review | Security-focused review for sensitive changes | Security Champion | Champion sign-off |
Secure Coding Requirements
| Requirement | Description | Verification Method |
|---|
| Input Validation | Validate all user input on server side; reject malformed input | Code review; SAST |
| Output Encoding | Encode output to prevent XSS and injection attacks | Code review; SAST |
| Parameterized Queries | Use parameterized queries or ORM; no string concatenation for SQL | Code review; SAST |
| Authentication Security | Use approved authentication libraries; implement proper session management | Code review; security review |
| Authorization Checks | Verify authorization at every access point; implement least privilege | Code review; testing |
| Cryptography | Use approved algorithms; never implement custom crypto; proper key management | Code review; security review |
| Error Handling | Handle errors gracefully; never expose stack traces or sensitive info | Code review; DAST |
| Logging | Log security-relevant events; never log sensitive data (PII, credentials) | Code review; log review |
| File Operations | Validate file paths; restrict file types; scan uploads | Code review; testing |
| API Security | Authenticate all API endpoints; implement rate limiting; validate input | Code review; DAST |
Phase 4: Testing
Security testing validates that security controls function correctly and vulnerabilities are identified before deployment.
| Testing Type | Description | Frequency | Owner |
|---|
| Unit Security Tests | Security-focused unit tests for critical functions | Per PR | Developers |
| Integration Security Tests | Test security controls in integrated environment | Per release | QA |
| SAST | Static code analysis for vulnerabilities | Per PR (CI/CD) | Automated |
| DAST | Dynamic testing of running application | Weekly | Security |
| SCA | Third-party component vulnerability scanning | Per PR (CI/CD) | Automated |
| Penetration Testing | Manual security testing by qualified testers | Annual + major releases | Security/External |
| Security Regression | Automated regression tests for past vulnerabilities | Per release | QA |
Security Testing Coverage Requirements
| Test Category | Coverage Target | Current Coverage | Gap Remediation |
|---|
| Authentication flows | 100% | 100% | Maintained |
| Authorization checks | 100% | 98% | Q1 2026 target |
| Input validation | 100% | 95% | Ongoing expansion |
| Cryptographic functions | 100% | 100% | Maintained |
| API endpoints | 100% | 97% | Q1 2026 target |
| Error handling | 90% | 88% | Q2 2026 target |
Phase 5: Deployment
Secure deployment ensures that applications are released safely without introducing configuration vulnerabilities.
| Activity | Description | Owner | Artifacts |
|---|
| Pre-Deployment Review | Verify all security gates passed | Release Manager | Deployment checklist |
| Configuration Review | Validate production configuration security | SRE | Config review notes |
| Secrets Deployment | Deploy secrets via secure secrets management | SRE | Deployment logs |
| Staged Rollout | Deploy progressively with monitoring | SRE | Deployment metrics |
| Security Monitoring | Verify security monitoring active | Security | Monitoring confirmation |
| Post-Deployment Scan | DAST scan of deployed application | Security | Scan results |
Deployment Security Checklist
| Checkpoint | Requirement | Verification |
|---|
| CI/CD Gates | All required security checks passed | Pipeline status |
| Code Review | All changes approved by qualified reviewer | PR approval records |
| SAST Clean | No critical or high SAST findings unaddressed | SAST report |
| SCA Clean | No critical SCA findings unaddressed | SCA report |
| Secrets Management | No hardcoded secrets; secrets via vault | Secrets scan |
| Configuration Security | Production config follows security baseline | Config review |
| Monitoring Ready | Security monitoring and alerting configured | Dashboard verification |
| Rollback Plan | Documented rollback procedure available | Runbook review |
Phase 6: Operations
Ongoing security operations ensure that deployed applications remain secure over time.
| Activity | Description | Frequency | Owner |
|---|
| Vulnerability Monitoring | Monitor for newly disclosed vulnerabilities | Continuous | Security |
| Patch Management | Apply security patches within SLA | Per vulnerability | Engineering |
| Security Monitoring | Monitor for security anomalies and incidents | Continuous | Security |
| Incident Response | Respond to security incidents per IRP | As needed | Security |
| Access Reviews | Review application access permissions | Quarterly | Security |
| Log Review | Review security logs for anomalies | Weekly | Security |
Vulnerability Management SLAs
| Severity | CVSS Score | Remediation SLA | Escalation |
|---|
| Critical | 9.0-10.0 | 24 hours | CISO immediately |
| High | 7.0-8.9 | 7 days | CISO at 5 days |
| Medium | 4.0-6.9 | 30 days | VP Engineering at 25 days |
| Low | 0.1-3.9 | 90 days | Standard tracking |
| Informational | 0.0 | Best effort | None |
Code Review Requirements
Peer Review Process
| Requirement | Description | Enforcement |
|---|
| Minimum Reviewers | All PRs require at least 1 qualified reviewer approval | Branch protection |
| Author Exclusion | PR author cannot approve their own changes | Branch protection |
| Expertise Requirement | Reviewer must have relevant codebase knowledge | Review assignment |
| Timeliness | Reviews completed within 24 business hours | Process monitoring |
| Security Changes | Security-sensitive changes require Security Champion review | Security tagging |
Code Review Checklist
| Review Area | Checklist Items |
|---|
| Functionality | Logic correct; edge cases handled; error conditions addressed |
| Security | Input validation; authorization checks; no hardcoded secrets; secure coding |
| Performance | No N+1 queries; appropriate caching; resource efficiency |
| Maintainability | Clear code; appropriate comments; consistent style |
| Testing | Adequate test coverage; tests pass; security tests included |
| Documentation | API docs updated; README updated if needed |
Security-Sensitive Change Triggers
| Trigger | Required Reviewer | Rationale |
|---|
| Authentication changes | Security Champion + CISO approval | Critical security function |
| Authorization changes | Security Champion | Access control impact |
| Cryptography changes | Security Champion | Crypto sensitivity |
| Database schema changes | Security Champion + DBA | Data integrity |
| Third-party integration | Security Champion | Third-party risk |
| API endpoint changes | Security Champion | External attack surface |
| Infrastructure changes | Security Champion + SRE Lead | Infrastructure security |
CI/CD Security Pipeline
Pipeline Security Gates
| Gate | Tool/Method | Failure Threshold | Bypass Process |
|---|
| Unit Tests | Jest/Pytest | Any failure | None; must pass |
| Integration Tests | CI framework | Any failure | Emergency only; CISO approval |
| SAST | Semgrep/CodeQL | Critical or High findings | Security exemption with tracking |
| SCA | Dependabot/Snyk | Critical findings | Security exemption with tracking |
| Secrets Scan | GitLeaks/TruffleHog | Any detection | None; must remediate |
| Container Scan | Trivy/Grype | Critical findings | Security exemption with tracking |
| IaC Scan | Checkov/tfsec | Critical findings | Security exemption with tracking |
| License Check | FOSSA/Snyk | Restricted license | Legal review |
Pipeline Configuration Requirements
| Requirement | Description | Implementation |
|---|
| Immutable Pipelines | Pipeline definitions version-controlled and reviewed | GitHub protected files |
| Secure Credentials | Pipeline secrets via secure secrets management | GitHub Secrets/AWS Secrets Manager |
| Minimal Permissions | Pipeline runs with least privilege | IAM role restrictions |
| Build Reproducibility | Builds are reproducible and auditable | Pinned dependencies; build logs |
| Artifact Signing | Build artifacts cryptographically signed | Sigstore/cosign |
| Audit Logging | All pipeline executions logged | CI/CD audit logs |
Security Tool Configuration
| Tool | Purpose | Configuration | Reporting |
|---|
| Semgrep | SAST for custom rules + OWASP | Custom ruleset + community | PR comments; dashboard |
| CodeQL | SAST for complex analysis | Default security queries | PR comments; alerts |
| Snyk | SCA for dependency vulnerabilities | Auto-fix PRs enabled | PR comments; dashboard |
| GitLeaks | Secrets detection | Custom patterns + defaults | PR blocking; alerts |
| Trivy | Container vulnerability scanning | Critical/High threshold | PR comments; dashboard |
| Checkov | IaC security scanning | CIS benchmarks | PR comments; dashboard |
Dependency Management
Dependency Policy
| Policy | Requirement | Enforcement |
|---|
| Approved Sources | Dependencies only from approved registries (npm, PyPI, etc.) | Registry configuration |
| License Compliance | Dependencies must have approved licenses | License scanning |
| Version Pinning | Production dependencies pinned to specific versions | Lock file enforcement |
| Security Status | No dependencies with unpatched critical vulnerabilities | SCA scanning |
| Maintenance Status | Prefer actively maintained dependencies | Manual review |
| Minimal Footprint | Avoid unnecessary dependencies | Code review |
Dependency Update Cadence
| Dependency Type | Update Frequency | Automation | Review |
|---|
| Security patches | Immediate (within SLA) | Dependabot auto-merge for patch | Automated + monitoring |
| Minor updates | Weekly | Dependabot PRs | Developer review |
| Major updates | Monthly evaluation | Dependabot PRs | Developer + Security review |
| Framework updates | Quarterly evaluation | Manual | Architecture review |
Approved Dependency Licenses
| License Category | Status | Examples |
|---|
| Permissive | Approved | MIT, BSD, Apache 2.0, ISC |
| Weak Copyleft | Approved with review | LGPL, MPL |
| Strong Copyleft | Case-by-case | GPL (not in distributed software) |
| Commercial | Case-by-case | Proprietary licenses |
| Unknown/No License | Not approved | Must identify or avoid |
Security Champion Program
Program Structure
| Element | Description |
|---|
| Role | Developer with additional security responsibilities serving as team liaison |
| Selection | Volunteer with interest; manager approval; security training |
| Coverage | Minimum 1 Security Champion per development team |
| Time Allocation | 10-20% of time for security activities |
| Reporting | Reports to CISO for security matters; engineering manager for other work |
Security Champion Responsibilities
| Responsibility | Description | Frequency |
|---|
| Security Review | Review security-sensitive changes for their team | Per change |
| Threat Modeling | Lead or participate in team threat models | Per feature |
| Training Liaison | Cascade security training to team members | Quarterly |
| Vulnerability Triage | Initial triage of vulnerabilities in team's code | As identified |
| Security Advocacy | Promote secure coding practices within team | Ongoing |
| Security Office Liaison | Attend Security Champion meetings; bring team concerns | Bi-weekly |
Security Champion Training
| Training Module | Duration | Frequency | Topics |
|---|
| Secure Coding Fundamentals | 4 hours | Initial | OWASP Top 10; secure coding practices |
| Threat Modeling | 2 hours | Initial | STRIDE methodology; practical exercises |
| Code Review for Security | 2 hours | Initial | Security review techniques |
| Application Security Tools | 2 hours | Initial | SAST/DAST/SCA tool usage |
| Security Updates | 1 hour | Quarterly | Emerging threats; tool updates; lessons learned |
Security Training for Developers
Required Training Matrix
| Training | Audience | Duration | Frequency | Completion Target |
|---|
| Secure Coding Fundamentals | All developers | 4 hours | Annual | 100% |
| OWASP Top 10 | All developers | 2 hours | Annual | 100% |
| Security Awareness | All employees | 1 hour | Annual | 100% |
| Language-Specific Security | By technology stack | 2 hours | Annual | 100% for applicable |
| API Security | API developers | 2 hours | Annual | 100% for applicable |
| Threat Modeling | Security Champions | 4 hours | Initial + refresher | 100% of champions |
Training Completion Metrics (FY2025)
| Training | Required | Completed | Completion Rate |
|---|
| Secure Coding Fundamentals | 85 | 84 | 98.8% |
| OWASP Top 10 | 85 | 82 | 96.5% |
| Security Awareness | 340 | 334 | 98.2% |
| API Security | 52 | 51 | 98.1% |
| Security Champion Training | 12 | 12 | 100% |
Numbered Policy Statements
-
Security Integration Mandate: Security shall be integrated into all phases of the software development lifecycle, from requirements through retirement.
-
Threat Modeling Requirement: All significant new features and architectural changes shall undergo threat modeling before development begins.
-
Secure Coding Standards: All code shall be developed following approved secure coding standards aligned with OWASP guidelines.
-
Code Review Mandate: All code changes require peer review and approval before merging to protected branches.
-
Automated Security Testing: All code changes shall pass automated security testing (SAST, SCA, secrets scanning) before deployment.
-
Dependency Management: Third-party dependencies shall be tracked, monitored for vulnerabilities, and updated according to defined SLAs.
-
Vulnerability Remediation: Security vulnerabilities shall be remediated within the timeframes defined by severity-based SLAs.
-
Security Champion Coverage: Each development team shall have at least one designated Security Champion.
-
Developer Training: All developers shall complete annual secure coding training with 100% completion target.
-
Penetration Testing: Annual penetration testing shall be conducted by qualified testers, with additional testing for major releases.
-
Secrets Management: Secrets shall never be committed to source code; all secrets shall be managed through approved secrets management systems.
-
CI/CD Security Gates: Deployments to production shall be blocked if critical security gates fail, with bypass requiring documented security exception.
-
Security Metrics Tracking: Security metrics (vulnerability counts, remediation times, training completion) shall be tracked and reported monthly.
-
Continuous Improvement: The secure SDLC program shall be reviewed annually and improved based on industry developments, audit findings, and lessons learned.
Framework Appendix
Compliance Mapping
| Requirement | SOC 2 Criteria | ISO 27001 Control | NIST CSF | Implementation |
|---|
| Secure development | CC8.1 | A.14.2.1 | PR.IP-2 | This SDLC policy |
| Security requirements | CC3.1 | A.14.1.1 | ID.RM-1 | Requirements phase |
| Secure coding | CC8.1 | A.14.2.5 | PR.IP-2 | Coding standards |
| Code review | CC8.1 | A.14.2.6 | PR.IP-2 | PR process |
| Security testing | CC8.1 | A.14.2.8 | DE.CM-4 | Testing requirements |
| Change management | CC8.1 | A.12.1.2 | PR.IP-3 | Change management policy |
| Vulnerability management | CC7.1 | A.12.6.1 | RS.MI-3 | Patch SLAs |
OWASP SAMM Alignment
| SAMM Practice | Maturity Level | Acme Cloud Implementation |
|---|
| Education & Guidance | 2 | Security training program; secure coding standards |
| Threat Assessment | 2 | Threat modeling for significant features |
| Security Requirements | 2 | Requirements phase activities |
| Security Architecture | 2 | Design phase review |
| Security Testing | 2 | Automated testing + penetration testing |
| Code Review | 2 | Mandatory peer review; security review |
| Environment Hardening | 2 | Deployment security; configuration management |
Security Tool Stack
| Category | Primary Tool | Secondary Tool | Purpose |
|---|
| SAST | Semgrep | CodeQL | Source code analysis |
| SCA | Snyk | Dependabot | Dependency vulnerability |
| Secrets | GitLeaks | TruffleHog | Hardcoded secrets |
| Container | Trivy | Grype | Container vulnerabilities |
| IaC | Checkov | tfsec | Infrastructure security |
| DAST | OWASP ZAP | Burp Suite | Dynamic testing |
| Pen Testing | External firm | Internal red team | Manual testing |
Related Trust Center documents
security overview, change management, access control, vulnerability disclosure, penetration testing, encryption standards, incident response
Document revision history
| Version | Date | Author | Summary of changes |
|---|
| 1.0 | 2024-06-01 | Legal & Compliance | Initial Trust Center publication |
| 2.0 | 2025-03-15 | GRC Program | SOC 2 Type II alignment refresh; expanded subprocessors |
| 2.5 | 2025-09-01 | Security Engineering | Encryption standards update; ISO 27001 mapping |
| 3.0 | 2026-01-15 | Trust Center Program | Full procurement-grade expansion; 34-document set |
Contact
Acme Cloud, Inc.
1200 Market Street, Suite 400
San Francisco, CA 94103, USA
SDLC Security Contacts
| Contact | Role | Use Case |
|---|
| security@acmecloud.com | Security Team | Security questions; vulnerability reports |
| security-champions@acmecloud.com | Security Champion Group | Security review requests; training |
| VP Engineering | Engineering Leadership | Process questions; escalations |
| CISO | Security Executive | Policy exceptions; critical issues |
Appendix: SDLC Metrics Dashboard
| Metric | Definition | Target | FY2025 Q4 Actual |
|---|
| SAST pass rate | PRs passing SAST without critical/high findings | >95% | 97.2% |
| SCA pass rate | PRs passing SCA without critical findings | >98% | 99.1% |
| Code review coverage | PRs with approved reviews before merge | 100% | 100% |
| Mean time to remediate (critical) | Average days to fix critical vulnerabilities | <7 days | 4.2 days |
| Security training completion | Developers completing required training | 100% | 98.8% |
| Penetration test findings (critical) | Critical findings from annual pen test | 0 | 0 |
| Security Champion coverage | Teams with assigned Security Champion | 100% | 100% |
Document Version: 3.0
Last Updated: January 15, 2026
Visit EthicPages