With the prevalence of Ransomware attacks and Vulnerabilities being discovered in commonly used libraries such as Log4J, security is not an after thought anymore. In this multi-part article, we start with DevSecOps from a 50,000 ft level and drill deeper to examine both Open Source and commercial products that serve this space.
In this Part 1 of the series, we throw light on background of DevSecOps, how it came to play and create impact on Software Development Life Cycle.
What is DevSecOps ?
DevSecOps stands for Development, Security, and Operations. It makes application and infrastructure more secured in each phase of Software development life cycle(SDLC). DevSecOps brings a new paradigm to the security testing in application development lifecycle. It makes everyone accountable for security with the objective of implementing security decisions and actions.
Shift left is a concept of DevSecOps. It encourages software engineers to move the security from right (end) to left (beginning) of the DevOps process. In a DevSecOps environment, security is an integral part of the development process from the beginning.
DevSecOps also means that security is a shared responsibility and everyone involved in the SDLC has a role to play in building security into the DevOps CI/CD workflow. According to DevSecOps philosophy, organisations should integrate security into every part of the DevOps life cycle, including inception, design, build, test, release, support, maintenance and beyond.
DevSecOps is the practice of integrating security into a continuous integration, continuous delivery, and continuous deployment pipeline. By incorporating DevSecOps values into software security, the security verification becomes active and integrated part of the development process.
Why DevSecOps?
DevSecOps divides and shares the security responsibilities into corresponding phases such as design, development, testing, deployment and maintenance.
The purpose and intent of DevSecOps is to build a mindset that everyone is responsible for security.
DevSecOps integrates security audits and testing into agile development and DevOps workflows, where security is built into the product rather than applied to a finished product.
When software is developed in a non-DevSecOps environment, security problems can lead to huge time delays and fixing the security issues will be time consuming and expensive as well. The rapid and secure delivery of DevSecOps saves time and reduces cost by minimising the need of repeating a process, to address the security issues after the incident.
Throughout the development cycle, the code is reviewed, audited, scanned and tested for security issues and are addressed as soon as they are identified. Security problems are fixed before additional dependencies are introduced. When protective technology is identified and implemented early in the cycle, security issues become less expensive to fix.
DevSecOps - Phases:
Security checks are added in each phase of DevOps Pipeline from plan, code, build, test, release, deploy and maintenance.
Plan đ
Planning is the first phase of DevSecOps where discussion, review and security analysis is handled. The team should list down all the phases of development life cycle and prepare the security testing methods & approaches on each phase, followed by creating a plan on how and when it should be done.
Code đ¨âđť
The spotlight of code phase is to enable developers to write secure codes. DevSecOps tools are used to review and analyse the code for each commit and pull request. The key process in this phase is to perform Static Application Software Testing(SAST) on the source code.
In this phase, the code will be scanned to identify the security vulnerabilities like auth key detection, bug detection, code vulnerability and security breaches. This helps developers to identify the security issues during the development phase. Thus, security issues can be identified and fixed at the very early stage, which makes the application more reliable and reduces the cost of addressing it later. Security checks on the code can be done in multiple stages, such as when code being written, committed and merged to the target branch. Also, PR can be rejected, when security vulnerabilities are found in the the source code.
Build đ
The build phase starts when developers push the code to repository. Another type of risk is security vulnerabilities on open source libraries. In the modern development, application will include 60%-80% open source libraries to achieve the business logic and requirements. Developers regularly install and build upon third-party code dependencies and libraries, which may be from an unknown or untrusted source. External code dependencies may accidentally or maliciously include vulnerabilities and exploits.
During the build phase, it is very important that organisations do not neglect open source security checks on third-party dependencies and libraries. It is equally important to deploy a dedicated solution that will track and alert users about open source risks throughout the DevSecOps pipeline.
Security measures should focus on automated security analysis, against the build output artifact and security practices including Software Component Analysis(SCA), Static Application Software Testing (SAST). The tools used are similar to code phase, but run on a sanitised build environment.
Test đ
Test phase starts once a build is created and successfully deployed in the testing environments. In this phase, functional and end-to-end testing will be done to check the functionality of the software where security checks are missed. DevSecOps brings the security checks in functional and end-to-end testing, to find the security vulnerabilities and breaches in the software application.
Testing phase is of two types as follows :
IAST: IAST (Interactive Application Security Testing) scans the code for security vulnerabilities while the application is being tested(manual/automated) or during the application interaction. IAST produces more accurate results with very less false positives. It helps developers to identify the exact line of code which causes security issues. DAST: DAST (Dynamic Application Security Testing) aka black box testing is to detect live application flaws. It interacts with both the Web Application & API like an external user and perform all the security related checks, thereby identifying the known vulnerabilities and security issues.
Release đ¸
The focus of the release phase is to ensure security on the infrastructure by validating the environment configurations such as secret data management, user access control and network firewall access.
This phase acts in accordance with the Principle of Least Privilege (PoLP) to ensure securities in the configurations. PoLP is that any user, program, or process, should be given only those privileges that are needed to complete the task. If a user or program does not need an access, then it shouldn't have it. Release phase involves validating API keys and access tokens to ensure that it has only required access. In the absence of this phase, the access right, that has access to the non-related areas of the system makes application more vulnerable.
Deployment đĽ
In the Deployment phase, configuration differences among the production environment, previous staging and development environments are identified. Results of previous phases' security tests need to be validated and verified. Also, limits can be set to stop the deployment if the result doesnât meet the expected standard. In addition, nowadays organisation move towards containerisation to make deployment easier in multiple environments but also opens up spaces for vulnerabilities. In this phase, security issues and vulnerabilities in the containers and images will be scanned and reported for the same.
Maintenance đ§
After an application is deployed to the production environment, its behaviour should be monitored. Organisation should implement automated security checks, to monitor and observe the live application for any attacks or suspicious activities.
A dedicated team can perform penetration testing to find security vulnerabilities without compromising a system. The organisation may also conduct a bug bounty program that pays external individuals who report security exploits and vulnerabilities in the application. The organisation should also have setup a protocol to monitor the incidents and capture the enough information to identify the root cause of the incident and automated alerting system, to inform the security issues ASAP.
Watch out for our next article to take a deep dive into each phase and the tools being used in that space.