Organisations that want to integrate Security into their DevOps pipelines should adopt tools and practices that unite application development, IT operations, and security teams under a common DevSecOps rubric.
DevSecOps is about introducing security earlier in the life cycle of application development or in delivery/deployment pipeline to minimise vulnerabilities and misconfigurations.
Everyone - developer, operations and security folks - becomes responsible for security.
This process change is about trying to automate core security tasks in the DevOps workflow. For instance, this could be automating compliance assessment, testing cloud infrastructure configuration, or testing code vulnerabilities continuously.
DevSecOps is become more and more important because of the shift to dynamic and frequent provisioning on Public Cloud. « Big bang » launches are becoming less frequent with the move to agile methodologies and DevOps workflows. More frequent releases are not compatible anymore with legacy security practices that were triggered at the end of the release process.
Security is often seen as counter-productive for innovation and time to market. Benefits are simple if DevSecOps is introduced and deployed wisely. No one should conceive that one team would roll out an application and then hand it on to another team to worry about security.
So far tools and techniques to provide security at the stages of DevOps workflow are still maturing.
The main security topics to handle in DevSecOps strategies are :
- Application architecting
- Vulnerability scanning (OS and code level)
- IAM configuration
- Firewalling (level 4 and 7)
- Protect and encrypt data at all layers
Security policies are usually already in place and well-defined. Then we need to tie the policies with the DevOps workflow.
More automation from the start decreases the likelihood of mistakes and reduces the time to fix them at an early stage. Like setting-up DevOps, DevSecOps requires new mindsets, upgrading processes and tools.
Mindset change from security teams is needed as security folks need to adhere to the collaborative and iterative nature of DevOps, to make security as seamless as possible in the new DevSecOps workflow. There are several approaches. For example, when treating the infrastructure as code, the security element can be included before coding and design the infrastructure, or assessed later. Another example in a dev factory with developers that can can vulnerabilities locally or in the CI/CD job run by JenKins/TravelCI/GitLab, … or do both.
Several companies had positive results that are often measured with reduced delay for fixing vulnerabilities or misconfiguration.
Besides the lack of skills is something that would slow the adoption of DevSecOps.
This market is not mature yet and many new comers will emerge these next 3 years. There is not a single product that could be plugged and automatically fulfil all the needs. Development stacks and processes are many, and there is no one-size-fits-all tool and approach.
This transformation includes mindsets change and it can not happen without DevSecOps evangelists from large startups or software companies.