DevSecOps: The Essential Guide For Fortifying The Software Development Life-cycle

The rapid increase in the number and popularity of various development platforms has resulted in a substantial surge in cyber attacks. The conventional approach of initiating security testing at the later stages of software development is no longer feasible. From the very first stage and in each stage thereafter, security validations should be integrated into the development process to save both time and energy.

The embrace of DevSecOps in the continuous integration and continuous delivery (CI/CD) pipeline is a necessity. However, it should be coupled with the mindset that security is an integral part of development. Only this will facilitate the full implementation of the ‘security in-depth’ strategy.

The specific techniques of security testing utilized in each of the 6 phases of software development will be highlighted in this article.

1: Software Architecture and Design

Once an initial design of the software is put in place in the early stages of software development, threat modeling tools can be used to identify the possible threats and design vulnerabilities that can be foreseen at this stage. These vulnerabilities can simply be eliminated even before actual code writing begins. It is considered a critical step in securing the development lifecycle, as remediating design vulnerabilities in later stages can be extremely costly and time-consuming.

Some threat modeling tools would require the developer to draw a data flow diagram showing the movement of information between internal and external entities, including processes, actors, and trust boundaries; once the diagram is ready, the tool will discover possible threats based on predefined rules. Other tools have adopted “Threat Modeling as Code” by analyzing YAML files that describe the software design. Although threat modeling should become a part of a developer’s mindset, using these tools sets a point of reference for all the involved developers to utilize. Examples of open-source threat modeling tools would be Threat Playbook and OWASP’s Threat Dragon.

2: Code Development

In the Code Development stage, the use of “Pre-Commit Hooks” tools has become essential. These tools aim to protect sensitive information such as private keys, SSH keys, authorization tokens, and passwords from being leaked out or pushed to git repositories in an unencrypted format. Developers would need to install these hooks on their workstation, set-up the git repository, and choose files they wish to encrypt; once the commit is done from the developer’s workstation, the file would get encrypted and will reside with the code in the same repository. Some examples of open source pre-commit hook tools are git secret and git crypt.

On a side note, developers should not underestimate the importance of secure coding practices and guidelines in this phase!

3: Pre-Build

In this stage, Static Application Security Testing (SAST), also known as whitebox testing, comes in handy. SAST tools are designed to point out security vulnerabilities in the source code before passing the code to the next stage in the CI/CD pipeline. When analyzing the outputs of SAST, developers will get familiarized with secure coding standards, that with time they should eventually acquire themselves.

In parallel with SAST analysis tools, developers must always consider spinning Source Composition Analysis (SCA) tools responsible for identifying vulnerable libraries and components in the code. SCA tools are fully dependent on Common Vulnerability and Exposures (CVE) lists and the National Vulnerability Database (NVD) as sources of information. Bypassing SCA testing can simply leave the application susceptible to publicly known vulnerabilities.

Examples of open-source SAST tools would be FindSecBugs and PMD. As for SCA tools, OWASP Dependency Checker and Requires.io could be possible options.

4: Post Build

At this point in the process and after the build is up and running, the CI/CD pipeline should automatically start the Dynamic Application Security Testing (DAST), also referred to as blackbox testing. DAST tooling works on scanning the web application against potential security flaws that can be exploited by hackers. When leveraged correctly, these tools will give early insight into the security of the application and will ensure that the enterprise is up-to-date with emerging threats. Examples of open source DAST tools include OWASP Zap, Archini, and w3af.

Very often, DAST testing is followed by manual penetration testing, performed by a member of the information security team or a so-called “white hacker.” The reported findings are usually dependent on the adopted testing methodologies and the experience of the pen tester. Even though penetration testing is viewed as a timely process, it can reveal a different set of security vulnerabilities not previously discovered by DAST.

5: Pre-deployment

In preparation for the deployment phase in a secure CI/CD pipeline, the concept of Infrastructure as Code (IaC) has become vital for securing containerized deployments. In a technical sense, IaC tools are embedded in the pipeline to perform static security analysis for container images against huge CVE databases that aggregate public vulnerabilities. Moreover, some IaC tools have even managed to combine comprehensive testing of vulnerabilities, viruses, and Trojans. Examples of open-source infrastructure scan tools are Anchor, Clair, and Dockerscan.

Preceding the deployment phase and depending on the needs of the enterprise, security testing can also cover Compliance as Code (CaC), where deployable images are audited against security standards and requirements such as PCI DSS and ISO CIS Benchmarks. An automated compliance testing tool would guarantee that all the containers adhere to consistent configurations and controls of the compliance expert’s choice. Inspec and OpenSCAP can be utilized for CaC testing.

6: Post Deployment and Operation

At operation, it is common practice to complement the security of the deployed application with Runtime Application Self Protection (RASP) technology. Unlike the perimeter based Web Application Firewall (WAF) that relies on signatures and rule sets to detect vulnerabilities in the application network traffic, RASP tools have improved visibility of vulnerabilities that are developed from contextual awareness of the application’s behavior. Although some DevSecOps engineers still implement WAF at this stage, RASP, on the contrary, can provide real-time monitoring from the inside out of the application resulting in more efficient threat identification and a lower rate of false positives. RASP’s capability of reacting to novel attack patterns in time would enable the enterprise to cover any remaining gaps from previous security testing phases. An example of open-source RASP tools would be openrasp.

Last but not least, a DevSecOps pipeline should incorporate a centralized place where developers can safeguard and manage all their secrets throughout the stages of the pipeline and specifically at the deployment and operation. Secret Management tools usually offer a secure API for the rotation, revocation, auditing, authentication, and authorization of secrets. By means of these tools, secrets are also encrypted at transit and rest in order to protect them from being compromised or even mistakenly leaked to public repositories. When it comes to open-source secret management tools, one may consider Hashicorp Vault and Keywhiz.

To sum up, embedding security in the early stages or, as they say, “shifting security toward the left ” in the CI/CD pipeline is, without a doubt, the right decision. Let’s not forget that the whole idea behind DevSecOps is to emphasize that security is a shared responsibility that should not be confined to a certain team or position at an enterprise. DevSecOps has evolved to facilitate security testing throughout every stage of the development process. It also gained a better consciousness of and visibility into the security posture of the developed application.