It’s been almost 15 odd years since the DevOps movement began, drastically altering the way in which software is shipped across the world; with increased speed and focus on shipping releases of software as quickly as possible so that the customers have the best experience they can.
But this meant moving away from the regular software development methodologies; and that includes changing the way in which we embedded security into these very software development methodologies. Previously, with the decreased speed at which software was being shipped, it meant more time for security teams to look into the code and architecture, and perform security reviews and code scans with ample time to fix the vulnerabilities. But with Agile methodologies and DevOps taking over, this meant little to absolutely no time for the security teams to perform their activities diligently. And hence, security took a hit. It was simply not possible for security teams to adopt at such a scale, and complete their tasks to match the speed at which developers were releasing code and deploying it into their cloud/self-hosted instances. And hence came the DevSecOps (also known as SecDevOps) movement.
DevSecOps essentially means Developer Security Operations; referring to integrating security into the very DevOps pipelines that the developers and DevOps engineers use to develop and ship code at lightning fast speeds. While it sounds easy to accomplish, DevSecOps is best explained as a mindset and an intersection of tools with automation. Security teams can no longer operate in their traditional methods, scheduling time for security reviews, manually providing the sign-offs, escalating vulnerabilities, etc. As is with all things that must be hastened, automation comes to the rescue.
With automation now in the picture, Security teams can now focus more on creating such automation workflows and integrating them into the DevOps pipeline. Once done, it is simply a matter of optimization until it is a fully functional pipeline. It would look something like this. Developers code in their IDEs, where security can integrate code scanning tools to recommend secure ways to code and find static security vulnerabilities even before the code is deployed, thus saving effort. This further enhances the speed of resolving the security vulnerabilities that any traditional SAST solution would detect, since we are embedding this solution directly into the IDE of the developer; or in other words, we are shifting such security scans and processes to take place earlier (Considering a horizontal pipeline, this would mean shifting left) in the DevOps pipeline. This concept of shifting left is more popularly known as the “Shift Left” approach to security, where we move every tool induction and process as “left” as possible in our pipelines. Shift left is done to ensure that the cost of fixing the vulnerabilities, if it were to be introduced, is minimized. For example, say you’re running SAST after code is committed into the repository, and after QA testing is done. In order to fix the vulnerabilities found by SAST, the
developer now has to fix it, and then the code must be committed, the code must pass QA testing again, and only then it has reached its earlier state, where it passed the QA testing. If the SAST was integrated way earlier into the pipeline, say when the developer is coding in the IDE itself, then the time and effort taken to fix this vulnerability will be minimal, as the vulnerability would pop up in the IDE itself, and the developer can fix it there itself. There wouldn’t be a requirement to commit the code, and have the code pass through QA again before the vulnerability is found.
Referring back to the fully functional pipeline, once SAST is integrated into the developer’s IDE, we can integrate SCA/SCT/SBOM tools as well, so that the BOM for the product is readily available, in case of any zero-day attacks. We can integrate DAST as well post deployment, as that is as early as DAST can be integrated into the pipeline, due to the hard dependency on some sort of deployment instance where DAST can be run. VAPT can also be done post DAST, to confirm that no vulnerabilities as far as the tools and human experience are concerned, creeps into the product. There are several other tools such as Privacy scans and License scans that can be run to ensure that the data or PII information is not leaked, and no license violations are unintentionally introduced into the software being released.
With this shift in mindset, from security being more of a developer support functionality and less of a monolithic controller of security operations for the product, the goal of DevSecOps teams is now to ensure that while software is shipped fast, it is also shipped secure. And for that, teaming up with the developers and ensuring that they aren’t blocked anywhere during their development process is vital; as that would defeat the very purpose of DevOps. DevSecOps isn’t just here to stay. It’s here to transform the way in which we look at and practice Security in our organizations.
—
Riyaz Rafi Ahmed
Security Software Engineer – DevSecOps @ Chargebee
