Software Development Life Cycle (SDLC) is an organized process of developing a secure application throughout the life of the project. Secure SDLC (SecSDLC) integrates security into the process, resulting in the security requirements being gathered alongside functional requirements, risk analysis being undertaken during the design phase, and security testing happening in parallel with development.
Stages and techniques of Secure SDLC
Secure SDLC contains following stages and techniques required:
| SSDLC stage | Techniques |
| Planning and Analysis | Agile Secure software development policies Keep security requirements current |
| Software/System Design | Threat modeling Secure design requirements |
| Implementation | Confidentiality, Integrity, Availability Shift Left security Code review Unit testing |
| Testing | System testing: back box, white box, fuzzing Static analysis, dynamic analysis Structured Exception Handling (SEH) Test automation |
| Integration | Enterprise security policies Ensure compliance Integration testing Encrypting in rest and in transit |
| Deployment | DevSecOps Automated CI/CD Release management flow |
| Maintenance | Logging and Monitoring Vulnerability reports ITSM and SIEM Automation Penetration testing |
As you can see, the automation is a critical part of any stage of software development. It utilizes scripts to perform tests, deploy application continuously, scripted installations and baseline configuration templates to secure applications during maintenance. Automation significantly decreases change of human error or misconfiguration. Another key aspect of SSDLC is shifting security left, starts thinking about security as soon as possible. Keeping security requirements current and implementing security development policies will significantly increase a resistance of an application to common vulnerabilities.
Appropriate testing methodology will help to protect a system from zero day vulnerability, find security thread on earlier stages of development. And, of course, it must be closely integrated to reporting or SIEM/ITSM system.
SecSDLC principals and best practice
Below is a list of best practice which may significantly increase a system resilience against common security vulnerabilities:
| SDLC principals | Best practice |
| Confidentiality | Ensures that only authorized users can access the data |
| Integrity | Ensures that the data is not modified or altered without permission |
| Availability | Ensuring that data is available to authorized users when it is needed |
| Least Privilege | Users and processes should be run using the least amount of access necessary to perform a given function |
| Defense in Depth | Layering of security controls is more effective and secure than relying on a single control |
| Never Trust User Input | Any input that is received from a user should undergo input validation prior to allowing it to be utilized by an application |
| Minimize Attack Surface | Reduce the amount of code used by a program, eliminate unneeded functionality, and require authentication prior to running additional plugins |
| Create Secure Defaults | Default installations should include secure configurations instead of requiring an administrator or user to add in additional security |
| Authenticity and Integrity | Applications should be deployed using code signing to ensure the program is not changed inadvertently or maliciously prior to delivery to an end user |
| Fail Securely | Applications should be coded to properly conduct error handling for exceptions in order to fail securely instead of crashing |
| Fix Security Issues | If a vulnerability is identified then it should be quickly and correctly patched to remove the vulnerability |
| Rely on Trusted SDKs | SDKs must come from trusted source to ensure no malicious code is being added |
Let’s do some example how to apply the principals to some of commons application vulnerabilities.
| Vulnerabilities | Description | SDLC principals |
| Insecure Components | Code Reuse, Third-party Library, Software Development Kit (SDK) | Rely on Trusted SDKs Fix Security Issues |
| Insufficient Logging and Monitoring | Any program that does not properly record or log detailed enough information for an analyst to perform their job | Logging and monitoring must support your use case and answer who, what, when, where, and how Fail Securely |
| Weak of Default Configurations | Any program that uses ineffective credentials or configurations, or one in which the defaults have not be changed for security Many applications choose to simply run as root or as a local admin Permissions may be too permissive on files or directories due to weak configurations | Create Secure Defaults Least Privilege |
This is important to choose an appropriate SDLC models which is better for developing secure software in part because their iterative approach makes it easier for changes to occur at any time should vulnerability remediation be necessary. Implementing security first approach and working on smaller chunks of code also means fewer unintended consequences; bugs have less of an impact and are easier to fix. Furthermore, the continuous release cycles of agile models have shifted security left to prevent testing bottlenecks. It should notice, developers now handle much of the security work by reviewing and testing code far earlier in the SDLC.
Remember, the best result is only available with the best tools.
Be an ethical, save your privacy!