SDLC Security Controls

When having conversations on how to better secure the technology infrastructure, the term security controls is very often associated with network perimeter, firewalls, intrusion detection systems, etc. When trying to use the same term in the Software Development Lifecycle (SDLC), technology practitioners tend to also steer the conversation in the same direction. We must recognize they are not the same. Software has always been considered the culprit of security vulnerabilities for very good reasons.

Due to the disconnect between security requirements and the use and development of software, the traditional adoption of a strong security posture has relied on infrastructure security controls to secure the software. Even though these controls provide value, the reality is security vulnerabilities where attackers can circumvent and bypass Multi-Factor Authentication, access controls, etc. provide good evidence for the need to secure software. And that task goes beyond the standard adoption of infrastructure security. Thinking that strong security relying solely on infrastructure is enough to secure an organization is not just underestimating the potential impact of threat vectors, but also lacks comprehensive coverage.

To reduce the potentially devastating impact of security vulnerabilities against the organization requires a shift in the mindset of many security practitioners. To really reduce the risk against potential attacks will require early detection and a more aggressive “shifting-left approach” during the development of software. It is right here that the enforcement of security controls in the SDLC comes into play. When dealing with securing the software, there are three key concerns. The SDLC security trinity encompasses concerns associated with the definition of the code during development, the identification of components increasing the risk of a potential compromise, and the potential malicious behaviors caused by the interaction of multiple software components. Let's discuss how the industry has responded to these three key concerns.

‍

First, the most basic landscape where security vulnerabilities are identified is the source code itself. Without any potential help to the developer, he/she could be introducing a SQL Injection inadvertently which will manifest in a production environment. To reduce the potential risk associated with this kind of behavior and minimize the cost of the remediation, the industry developed the Static Application Security Testing (SAST) tool. This security control is the closest tool to the developer which helps with the early identification of security threats. 

Second, almost every piece of software being created today uses 3^rd party software one way or another. The days when developers were creating standard features from scratch and maintaining them are over. The open-source community has provided a lifeline to reduce the cost of managing these standard components while allowing organizations to focus on innovative solutions. Despite these benefits, these components carry risks. This is where Software Composition Analysis (SCA) tools provide great visibility of the associated risk and empower development teams with the required information needed by the remediation of vulnerable components. If we need a real-life example of the value behind SCA, we only need to evaluate the SCA detection capabilities against the Log4jShell vulnerability. 

Finally, the last component of the SDLC security trinity is the malicious behaviors associated with the integration of software components. The ability of an attacker to exploit a Cross-Site Scripting attack relies on the interaction of multiple components. To be able to detect these risky behaviors, the Dynamic Application Security (DAST) tools or the Interactive Application Security (IAST) tools provide the identification of exploits associated with component interactions. This type of detection requires a higher level of complexity evaluation and the DAST/IAST tools were designed to expose these risky behaviors.

The use of these three security controls in the SDLC is not a silver bullet. Threat actors will always try to find ways to compromise the organization. With the right skill set, they can create code to help themselves in their endeavor. Nevertheless, implementing security controls in the SDLC will help significantly minimize the risk of software weaponization. This is not only a must-have but an important step in achieving a comprehensive defense strategy. Securing the organizations against cyber-attacks requires the full commitment of the industry. Implementing security controls in the SDLC will help our technology ecosystem reduce potential compromises caused by the lack of security concerns in the SDLC.

‍