The release phase of the Software Development Life Cycle (SDLC) is traditionally associated with production, deployment, and post-production activities. Which generally include maintenance and support of the software that has been developed. In this phase, post-production tasks (after deployment) in traditional SDLC models do not greatly involve development engineers. Operations admins and security engineers typically complete most of thee functions, which may include software monitoring, security testing, incident response, etc. In the Secure Software Development Life Cycle (SSDLC), developers are responsible for completing additional security tasks, which - even in the post-production stage of the release phase - integrates security with development. Other factors associated with the release phase include:

• confirming that the software works as optimally in the production environment as it did in the development environment • obtaining feedback from end-users in order to make appropriate tweaks • conducting maintenance and support tasks • confirming that the software in production meets customer and user needs according to the initial requirements.

The release phase of the SDLC is composed of many maintenance tasks, and thus it is a continuous process. Security itself is a continuous process of testing, upgrading, patching, maintaining & remediation tasks to ensure that software continues to remain secure and available. That said, in the Secure SDLC engineers are responsible for additional tasks not typically associated with SDLC models of development, including adding application logging events for security purposes. The security-based software events that should be logged include:

• Login events (successes and failures) • Authorization events (successes and failures) • 4xx errors (client errors) • 5xx errors (server errors) • Database syntax errors • Access control exceptions • Validation errors • CSRF token validation errors

A simple chart or graph illustrating all successful login attempts versus failed login attempts, where a brute force attack against the login page would result in a massive spike in failed login attempts can successfully alert teams of an attack occurring in real time. Visualizing data & metrics is a powerful method of aiding teams in mitigating security threats. The proper utilization of security metrics is key to efficiently equipping engineering teams and admins with the information needed to mitigate security threats. To this end, metrics should be made transparent to the project team - and for the sake of educating all personnel, the entire organization - to ensure that all personnel are aware of the hostile production environment that the application has been deployed in.

Establishing an efficient defensive front based on attacks (i.e. an attack-driven defense) allows for the implementation of a powerful system that combines event/log metrics and real-time traffic data, the correlation of which can be used to detect attacks as they happen in real-time based on the aforementioned attack signatures. With such an infrastructure in place, a feedback system can be incorporated allowing data to be fed back to engineering and admin teams. These teams can create additional security dashboards and sub-systems that permit incoming attacks to drive a variety of powerful defensive countermeasures. The utilization of a security dashboard based on security data is significant in that such a system can be used to identify additional attack signatures in real time, i.e. abnormal traffic volumes often associated with fuzzers, scanners, DoS programs, etc. Additionally, attack patterns and signatures can be used as grounds for modifying code in order to stop exploits from occurring, and can be used as a foundation for pre-empting future threats based on known vulnerabilities. In certain environments, such as a Secure DevOps environment, such modifications can be made in a matter of minutes in order to close security holes and mitigate software vulnerabilities.

In fact, the risk associated with using software containing known vulnerabilities is number nine in the OWASP Top 10, which comprises 10 critical web application flaws and unsafe practices that can result in a data breach. The SSDLC process should include the use of continuous monitoring tools (e.g. OWASP Dependency Check) across the entire software supply chain to ensure that all code in use is vulnerability-free. Both automated scanners & manual penetration tests are needed to ensure that code is truly devoid of the OWASP Top 10 and CWE 25 vulnerabilities. Another key step in maintaining secure coding systems is the establishment of an internal, secure code repository that includes code libraries that have been thoroughly reviewed, scanned, and approved by security teams. When protocols are set in place to allow development engineers to utilize only approved libraries and versions it is more feasible for teams to monitor them for vulnerabilities and security holes. To ensure that this system is effective, all new versions and libraries should be scanned and approved by the security team before introducing them to the package repository. This robust system can help to ensure that only secure code is used in your software applications and that insecure code is not being deployed into the production environment.