When I worked as a developer many years ago, we followed the waterfall software development life cycle (SDLC). My focus was always on satisfying functional or business requirements and implementing newer technical capabilities. Deployment happened once every 1 or 2 months. Huge monolithic applications were deployed over a weekend, with almost half the company on support standby, everyone praying the release went smoothly. The security teams got involved from a production monitoring perspective. They would conduct sporadic penetration tests on applications already deployed to production. The software security group (SSG), or the security team, was solely responsible for the security of our applications.
With the adoption of newer and faster development life cycles, the scenario has changed. Monolithic software has been broken down into micro services and containers, and clouds are replacing traditional environments. Automation has been instrumental in increasing the velocity of deployment, along with streamlining the entire process. The development and the operations roles have been merged into a DevOps capability. Boundaries between various development and operational teams have been vanishing to make DevOps a success. Anyone who has migrated from a waterfall SDLC to a modified agile or DevOps SDLC will also tell you that it requires a huge shift in mind-set. Without a massive cultural change, it is difficult for DevOps to thrive.
However, what’s been missing from this new collaborative effort is security. Even though the DevOps mind-set ensures stable, faster throughput, the applications themselves may not be secure. DevOps practitioners argue that traditional security slows them down. But the risk is that security teams go missing from modified agile or DevOps cycles if they don’t hop on board this fast-moving train. And this is where the DevSecOps mind-set comes into the picture.
Security is no longer solely the SSG’s responsibility. It is everyone’s responsibility. Building security in starting from product conception decreases remediation time while making the product safer, lowering costs in the long run. Instead of measuring how long it takes for the pipeline to build, quality-test, and deploy software, DevOps organizations must start measuring the baseline with security activities included in the overall pipeline.
Application security is a subset of application quality: Quality metrics must include application security metrics, and quality tests must include security tests. The DevSecOps mind-set makes this easier to enforce. Once developers and operations start owning the security of their software, friction between all these teams decreases.
As in any harmonious relationship, give-and-take is very important. The security team must enable developers to secure their software by providing security trainings, nurturing security champions within the organization, and automating security tools for testing, ultimately embedding application security into the existing pipelines. Security teams must adopt the development processes and technologies needed to ensure a tight integration. They must respect deployment frequencies and modify their processes and activities accordingly. Conversely, the development organization must own the security of their applications along with the security team. They must understand that deploying an insecure application to production is no longer an option.
DevOps teams must realize that security is not something slapped onto a product during or after deployment. Rather, it is a combination of different activities that integrate into the SDLC right from the analysis phase. Security must be built into the product.
Ultimately, it is time to retire the DevOps mind-set and adopt a DevSecOps life cycle to make the world of rapid software deployment a safer place.