1. Purpose
The Secure Development Checklist is used to ensure that information security is considered throughout the software development lifecycle.
It helps verify that security requirements are identified, secure design principles are applied, code is developed securely, vulnerabilities are identified and remediated, and security controls are verified before production deployment.
The checklist can be used for:
- New applications
- SaaS platforms
- APIs
- Mobile applications
- Web applications
- Internal applications
- Major application enhancements
- Cloud applications
- Infrastructure-as-code
- Significant software changes
The level of security review should be proportionate to the application’s risk, data, exposure, and business criticality.
2. Project Information
| Field | Details |
|---|---|
| Project Name | [Project Name] |
| Project ID | [Project ID] |
| Application Name | [Application] |
| Version / Release | [Version] |
| Development Team | [Team] |
| Project Manager | [Name] |
| Technical Owner | [Name] |
| Security Owner | [Name] |
| Repository | [Repository] |
| Environment | [Development / Test / Production] |
| Review Date | [Date] |
| Reviewer | [Name] |
| Status | [Open / In Progress / Complete] |
3. Development Lifecycle
Security should be considered throughout:
Requirements → Design → Development → Code Review → Testing → Release → Deployment → Monitoring → Improvement
Security should not be limited to the final penetration test.
4. Security Requirements
Checklist
- ☐ Security requirements identified
- ☐ Business security requirements documented
- ☐ Customer security requirements reviewed
- ☐ Legal/regulatory requirements identified
- ☐ Privacy requirements identified
- ☐ Data classification completed
- ☐ Authentication requirements defined
- ☐ Authorization requirements defined
- ☐ Encryption requirements defined
- ☐ Logging requirements defined
- ☐ Monitoring requirements defined
- ☐ Backup/recovery requirements defined
- ☐ Vulnerability management requirements defined
- ☐ Security testing requirements defined
Evidence
- Security Requirements Register
- Project Risk Assessment
- Customer requirements
- Regulatory applicability assessment
- Architecture Review
5. Project Risk Assessment
Confirm that development-related risks have been assessed.
- ☐ Project risk assessment completed
- ☐ Application risks identified
- ☐ Data risks identified
- ☐ API risks identified
- ☐ Authentication risks identified
- ☐ Third-party dependency risks identified
- ☐ Cloud risks identified
- ☐ Supply-chain risks identified
- ☐ Security risks linked to controls
- ☐ Risk treatment actions assigned
- ☐ Residual risks assessed
Traceability
Risk → Security Requirement → Control → Implementation → Testing → Evidence
6. Security Architecture
- ☐ Architecture reviewed
- ☐ Data-flow diagram available
- ☐ Trust boundaries identified
- ☐ Internet-facing components identified
- ☐ Sensitive data flows identified
- ☐ Third-party integrations identified
- ☐ Authentication architecture reviewed
- ☐ Authorization architecture reviewed
- ☐ Network security reviewed
- ☐ Cloud architecture reviewed
- ☐ Logging architecture reviewed
- ☐ Backup/recovery architecture reviewed
- ☐ Security architecture findings addressed
Evidence
- Architecture diagram
- Data-flow diagram
- Threat model
- Security Architecture Review
7. Threat Modelling
For applications with significant security exposure, perform appropriate threat modelling.
Checklist
- ☐ Assets identified
- ☐ Threat actors considered
- ☐ Entry points identified
- ☐ Trust boundaries identified
- ☐ Data flows analysed
- ☐ Attack scenarios considered
- ☐ Authentication threats considered
- ☐ Authorization threats considered
- ☐ Data exposure considered
- ☐ API threats considered
- ☐ Third-party risks considered
- ☐ Cloud threats considered
- ☐ Mitigations identified
- ☐ Residual risks documented
Example Threats
- Credential compromise
- Unauthorized access
- Injection
- Broken authorization
- Data exposure
- Malicious file upload
- API abuse
- Session compromise
- Supply-chain compromise
- Cloud misconfiguration
8. Source Code Repository Security
Repository Access
- ☐ Repository access restricted
- ☐ Access based on job responsibilities
- ☐ Least privilege applied
- ☐ MFA enabled where applicable
- ☐ Production credentials not stored in repository
- ☐ Sensitive information not committed
- ☐ Former employees’ access removed
- ☐ Third-party developer access reviewed
Repository Protection
- ☐ Branch protection enabled where appropriate
- ☐ Pull requests used
- ☐ Code review required
- ☐ Direct production branch changes restricted
- ☐ Commit history protected
- ☐ Repository activity logged
- ☐ Administrative access restricted
9. Secure Coding
Developers should follow approved secure coding practices appropriate to the technology.
Checklist
- ☐ Input validation implemented
- ☐ Output encoding implemented
- ☐ Authentication securely implemented
- ☐ Authorization enforced server-side
- ☐ Secure session management implemented
- ☐ Error handling does not expose sensitive information
- ☐ Sensitive information is not unnecessarily logged
- ☐ Cryptography uses approved mechanisms
- ☐ Passwords are securely hashed
- ☐ Secrets are not hard-coded
- ☐ SQL/database queries protected
- ☐ File uploads controlled
- ☐ Access control failures handled securely
- ☐ Security-sensitive functions reviewed
- ☐ Secure API practices followed
10. Authentication
Review application authentication.
- ☐ Unique user identification
- ☐ Strong authentication
- ☐ MFA where required
- ☐ Password policy implemented where passwords are used
- ☐ Passwords securely hashed
- ☐ Account lockout/rate limiting considered
- ☐ Brute-force protection implemented
- ☐ Session timeout considered
- ☐ Secure session/token handling
- ☐ Password reset process secured
- ☐ Authentication events logged
- ☐ Administrative authentication strengthened
11. Authorization
Confirm that users can access only resources and functions they are authorized to use.
- ☐ Role-based access considered
- ☐ Least privilege applied
- ☐ Server-side authorization implemented
- ☐ Object/resource-level authorization implemented
- ☐ Privileged functions restricted
- ☐ Tenant isolation tested where applicable
- ☐ Administrative functions protected
- ☐ Access-control failures tested
- ☐ Authorization decisions logged where appropriate
SaaS Example
For a multi-tenant SaaS application:
Customer A must never be able to access Customer B’s records by changing an ID or API parameter.
This should be explicitly tested.
12. API Security
- ☐ API authentication implemented
- ☐ API authorization implemented
- ☐ TLS used
- ☐ Input validation implemented
- ☐ Rate limiting considered
- ☐ Request size limits considered
- ☐ API tokens protected
- ☐ Secrets not exposed
- ☐ Sensitive responses restricted
- ☐ Error responses reviewed
- ☐ API activity logged
- ☐ API abuse monitored
- ☐ Third-party APIs assessed
13. Secrets Management
Checklist
- ☐ No passwords in source code
- ☐ No API keys in source code
- ☐ No private keys in source code
- ☐ No production credentials in configuration files
- ☐ Secrets stored in approved secret-management system
- ☐ Production and development secrets separated
- ☐ Secrets access restricted
- ☐ Secret rotation process defined
- ☐ Compromised credentials can be revoked
- ☐ Repository scanned for exposed secrets
AWS Example
Use:
AWS Secrets Manager / appropriate approved secret store
instead of:
Hard-coded credentials in application code
14. Cryptography
Review cryptographic requirements.
- ☐ Encryption requirements defined
- ☐ Data in transit protected
- ☐ Sensitive data at rest protected
- ☐ Approved cryptographic mechanisms used
- ☐ Encryption keys protected
- ☐ Key access restricted
- ☐ Key management responsibilities defined
- ☐ Secrets and keys separated where appropriate
- ☐ Key rotation considered
- ☐ Weak/deprecated algorithms avoided
15. Dependency Management
Third-party libraries and components can introduce security risk.
- ☐ Dependencies inventoried
- ☐ Approved sources used
- ☐ Dependency versions tracked
- ☐ Vulnerability scanning enabled
- ☐ Critical/high vulnerabilities reviewed
- ☐ Unsupported dependencies identified
- ☐ Security advisories monitored
- ☐ Dependency updates managed
- ☐ Transitive dependencies considered
- ☐ Open-source licensing requirements considered where applicable
Evidence
- Software Composition Analysis (SCA) report
- Dependency list
- Vulnerability report
- Remediation ticket
16. Software Supply Chain Security
Consider security of the development and deployment supply chain.
- ☐ Developer access controlled
- ☐ Source repositories protected
- ☐ Build systems protected
- ☐ CI/CD credentials protected
- ☐ Build artifacts protected
- ☐ Third-party packages assessed
- ☐ Build dependencies controlled
- ☐ Deployment credentials restricted
- ☐ Release process controlled
- ☐ Software provenance/integrity considered
- ☐ Unauthorized changes detectable
17. Static Application Security Testing
Where appropriate:
- ☐ SAST configured
- ☐ Scans performed
- ☐ Findings reviewed
- ☐ Critical findings addressed
- ☐ High-risk findings addressed or accepted
- ☐ False positives reviewed
- ☐ Exceptions documented
- ☐ Scan results retained
18. Dynamic Application Security Testing
Where applicable:
- ☐ DAST performed
- ☐ Internet-facing application tested
- ☐ Authentication tested
- ☐ Authorization tested
- ☐ API security tested
- ☐ Findings reviewed
- ☐ Critical/high findings remediated or formally accepted
- ☐ Retest completed
19. Vulnerability Assessment / Penetration Testing
For applications where testing is required:
- ☐ Vulnerability assessment completed
- ☐ Penetration testing completed
- ☐ Scope documented
- ☐ Findings classified
- ☐ Critical findings remediated
- ☐ High-risk findings addressed
- ☐ Exceptions documented
- ☐ Retesting completed where appropriate
- ☐ Final report retained
20. Security Code Review
Security-focused code review should be performed for security-sensitive functionality.
Examples:
- Authentication
- Authorization
- Payment processing
- Encryption
- Session management
- File upload
- Data export
- Administrative functions
- Credential handling
- API endpoints
Checklist
- ☐ Reviewer identified
- ☐ Security-sensitive code identified
- ☐ Review completed
- ☐ Findings recorded
- ☐ Findings resolved
- ☐ Evidence retained
21. Test Environment Security
- ☐ Development separated from production
- ☐ Test environment access restricted
- ☐ Production data not used unnecessarily in testing
- ☐ Sensitive test data protected
- ☐ Test credentials separated
- ☐ Test systems securely configured
- ☐ Test environment vulnerabilities managed
- ☐ Test data deleted when no longer required
22. CI/CD Pipeline Security
Checklist
- ☐ CI/CD access restricted
- ☐ MFA enabled for privileged access where applicable
- ☐ Build credentials protected
- ☐ Deployment credentials protected
- ☐ Secrets stored securely
- ☐ Code scanning integrated where appropriate
- ☐ Dependency scanning integrated
- ☐ Build logs protected
- ☐ Production deployment restricted
- ☐ Deployment approval implemented where required
- ☐ Unauthorized pipeline changes prevented
- ☐ Pipeline activity logged
Example Flow
Developer → Pull Request → Code Review → Security Scan → Build → Test → Approval → Deployment
23. Infrastructure-as-Code Security
Where Terraform, CloudFormation, Kubernetes manifests, or similar technologies are used:
- ☐ IaC repositories protected
- ☐ Code review required
- ☐ Security scanning performed
- ☐ Secrets excluded
- ☐ Production changes controlled
- ☐ Infrastructure configuration version controlled
- ☐ Security configurations reviewed
- ☐ Drift detection considered
24. Container Security
Where containers are used:
- ☐ Base images approved
- ☐ Images vulnerability scanned
- ☐ Unnecessary packages removed
- ☐ Containers run with minimum privileges
- ☐ Secrets managed securely
- ☐ Container registry access restricted
- ☐ Images protected from unauthorized modification
- ☐ Runtime monitoring considered
- ☐ Container updates managed
25. Cloud Security
For AWS/Azure/GCP environments:
- ☐ IAM reviewed
- ☐ Privileged access protected
- ☐ Network segmentation reviewed
- ☐ Public exposure reviewed
- ☐ Storage permissions reviewed
- ☐ Encryption enabled where required
- ☐ Secrets management implemented
- ☐ Logging enabled
- ☐ Monitoring configured
- ☐ Security alerts configured
- ☐ Backup configured
- ☐ Cloud security findings addressed
26. Logging and Monitoring
Confirm that the application generates sufficient security-relevant logs.
Events
- ☐ Login success
- ☐ Login failure
- ☐ Password changes
- ☐ MFA events
- ☐ Privileged actions
- ☐ Access-control failures
- ☐ Administrative changes
- ☐ Security configuration changes
- ☐ API activity
- ☐ Data exports
- ☐ Security exceptions
- ☐ Application security events
Logging Controls
- ☐ Logs protected
- ☐ Log access restricted
- ☐ Retention defined
- ☐ Sensitive data excluded where unnecessary
- ☐ Monitoring implemented
- ☐ Alerts configured for important events
27. Error Handling
- ☐ Errors do not reveal passwords
- ☐ Errors do not expose secrets
- ☐ Stack traces not exposed to end users
- ☐ Internal system details protected
- ☐ Security events logged appropriately
- ☐ User-facing error messages are controlled
- ☐ Error handling tested
28. Data Protection
- ☐ Data classification completed
- ☐ Data minimization considered
- ☐ Sensitive data identified
- ☐ Encryption implemented where required
- ☐ Data retention defined
- ☐ Data deletion supported where required
- ☐ Data export controlled
- ☐ Data access restricted
- ☐ Privacy requirements addressed
- ☐ Backup copies considered
29. Security Testing
Before release, determine applicable testing:
| Test | Required | Completed | Result |
|---|---|---|---|
| SAST | ☐ | ☐ | |
| DAST | ☐ | ☐ | |
| Dependency Scan | ☐ | ☐ | |
| Secret Scan | ☐ | ☐ | |
| Infrastructure Scan | ☐ | ☐ | |
| Container Scan | ☐ | ☐ | |
| API Security Testing | ☐ | ☐ | |
| VAPT | ☐ | ☐ | |
| Penetration Test | ☐ | ☐ | |
| Manual Security Review | ☐ | ☐ |
Not every test is required for every project. Applicability should be based on risk and organizational requirements.
30. Security Defect Management
Security findings should be tracked to closure.
| Finding ID | Source | Finding | Severity | Owner | Target Date | Status | Retest |
|---|---|---|---|---|---|---|---|
| SD-001 | SAST | Injection vulnerability | High | Developer | [Date] | Open | Pending |
| SD-002 | DAST | Access control issue | Critical | Developer | [Date] | Fixed | Passed |
| SD-003 | SCA | Vulnerable dependency | High | Engineering | [Date] | Fixed | Passed |
Security Defect Lifecycle
Identify → Record → Assess → Assign → Remediate → Test → Retest → Close
31. Release Security Review
Before production release:
- ☐ Security requirements completed
- ☐ Architecture approved
- ☐ Security testing completed
- ☐ Critical vulnerabilities closed
- ☐ High-risk findings addressed or formally accepted
- ☐ Access controls verified
- ☐ Secrets verified
- ☐ Logging verified
- ☐ Monitoring verified
- ☐ Backup/recovery verified
- ☐ Security exceptions approved
- ☐ Residual risks assessed
- ☐ Required security approval obtained
32. Production Deployment
- ☐ Production environment approved
- ☐ Deployment authorized
- ☐ Production credentials protected
- ☐ Configuration reviewed
- ☐ Security settings verified
- ☐ Monitoring enabled
- ☐ Logging enabled
- ☐ Backup enabled
- ☐ Rollback procedure available
- ☐ Deployment record retained
- ☐ Post-deployment validation completed
33. Post-Deployment Security Review
After significant deployment:
- ☐ Application functioning as expected
- ☐ Security controls functioning
- ☐ Logs generated
- ☐ Monitoring operational
- ☐ No unexpected exposure
- ☐ Security alerts reviewed
- ☐ Access verified
- ☐ Vulnerability findings reviewed
- ☐ Incidents identified
- ☐ Lessons learned documented
34. Security Incident Readiness
Confirm that the application can be supported by the organization’s incident management process.
- ☐ Incident reporting mechanism available
- ☐ Security contacts identified
- ☐ Application logs available
- ☐ Relevant events traceable
- ☐ Incident escalation defined
- ☐ Customer communication process considered
- ☐ Regulatory requirements considered
- ☐ Evidence preservation considered
- ☐ Recovery procedure available
35. Security Findings and Exceptions
| ID | Area | Finding / Exception | Risk | Treatment | Owner | Due Date | Status |
|---|---|---|---|---|---|---|---|
| SEC-001 | Access | MFA missing for admin account | High | Enable MFA | IT | [Date] | Open |
| SEC-002 | Dependency | Vulnerable library | High | Upgrade | Engineering | [Date] | Closed |
36. Security Sign-Off
Developer / Engineering Owner
Name: ______________________
Signature/Approval: ______________________
Date: ______________________
Security Reviewer
Name: ______________________
Signature/Approval: ______________________
Date: ______________________
Project Owner
Name: ______________________
Signature/Approval: ______________________
Date: ______________________
Production Approval
Name: ______________________
Signature/Approval: ______________________
Date: ______________________
37. Audit Evidence
The following evidence may be retained:
- Security requirements
- Project risk assessment
- Architecture review
- Threat model
- Source-code repository controls
- Code review records
- SAST results
- DAST results
- Dependency scans
- Secret scans
- Vulnerability assessments
- VAPT reports
- Penetration test reports
- Security defect records
- CI/CD configuration
- Cloud security configuration
- Access reviews
- Security exceptions
- Risk acceptance
- Release approval
- Deployment records
- Post-deployment validation
38. Secure Development Checklist – Final Review
Planning
- ☐ Security requirements identified
- ☐ Risks assessed
- ☐ Architecture reviewed
- ☐ Threats considered
Development
- ☐ Secure coding practices followed
- ☐ Repository secured
- ☐ Code reviewed
- ☐ Secrets protected
- ☐ Dependencies monitored
Testing
- ☐ Security testing completed
- ☐ Vulnerabilities assessed
- ☐ Critical/high findings addressed
- ☐ Retesting completed where required
Deployment
- ☐ Production security configuration verified
- ☐ Access controls verified
- ☐ Logging enabled
- ☐ Monitoring enabled
- ☐ Backup/recovery verified
- ☐ Release approved
Post-Deployment
- ☐ Security monitoring operational
- ☐ Security findings tracked
- ☐ Incidents monitored
- ☐ Lessons learned captured
39. Startup-Friendly Minimum
For a small SaaS startup, the minimum practical secure-development process can be:
1. Define Security Requirements
↓
2. Perform Project Risk Assessment
↓
3. Review Architecture
↓
4. Secure Repository and Access
↓
5. Secure Coding + Code Review
↓
6. Scan Dependencies and Secrets
↓
7. Perform Appropriate Security Testing
↓
8. Fix Critical/High Findings
↓
9. Review Production Configuration
↓
10. Approve Release
↓
11. Monitor After Deployment
A startup does not need to implement every security activity at the same depth for every application. The level of control should be based on the application’s risk, data, exposure, technology, customer requirements, and business criticality.
40. Relationship With Other ISMS Documents
The Secure Development Checklist should connect with:
- Project Security Requirements Template
- Project Risk Assessment
- Security Architecture Review
- Threat Model
- Vulnerability Management Procedure
- Access Control Policy
- Change Management Procedure
- Incident Response Plan
- Backup and Recovery Procedure
- Supplier Security Assessment
- Security Testing/VAPT Reports
- Risk Register
- Statement of Applicability
The overall flow is:
Security Requirements → Risk Assessment → Architecture → Secure Development → Security Testing → Remediation → Release Approval → Monitoring → Improvement
41. Final Principle
Secure development is not simply:
Build → Test → Fix
A stronger lifecycle is:
Define → Assess → Design → Develop → Review → Test → Remediate → Verify → Approve → Deploy → Monitor → Improve
The objective is to build security into the development lifecycle so that security weaknesses are identified and addressed before they become production incidents.