DevSecOps is an evolution of the DevOps paradigm. It involves transforming the processes, very much like the DevOps transformation, to integrate Security into the DevOps workflow and not as an afterthought. This is more so applicable in organisations where security compliance and security teams traditionally exist as a separate function. Like with a DevOps transformation, the process calls out for a fundamental change in which the security functions are treated as parts of the same value units in a development lifecycle with closer communication and visibility within the team, instead of existing as separate silos.
What Changes
As described in a previous blog post, any transformation exercise involves people, tools and processes. For this to be successful there will need to be a cultural change in how Security is thought about in the organization. Traditionally when security is treated as a separate function, it becomes an afterthought to development teams. This means that an app or a feature is developed and then security is applied at the end. These security audits are often manual and time consuming. Being implemented at the end of a development lifecycle, with any issues found feeding back into the developers and end up causing longer life-cycles in the development process, which DevOps methodology tries to avoid.Â
With the DevSecOps approach, security becomes embedded into every aspect of the application and a ‘shift-left’ approach is implemented for the security reviews. It means that security considerations for the application, its infrastructure and its data becomes built-in and iterated upon at each step and happens much earlier in the life-cycle compared to traditional approaches. The cultural change involves the security team to be more visible throughout the process with communication of known vulnerabilities, risk analysis and compliance requirements. The security team’s insights need to be shared with the DevOps personnel and the DevOps personnel also need to take ownership and accountability of security in respect to the parts of the application they own and thus transforming from DevOps to DevSecOps. Training may also need to be provided to the people involved to enable them to work together smoothly and to change their thought process, so that security is treated as part of the delivery pipeline.
Implementing DevSecOps Automation
When talking about security becoming part of the delivery pipeline, it also includes how a developer codes, i.e the development environment. There are a number of different processes that can be put in place as part of the development and operational activities to ensure security compliance is automated throughout the pipeline with a variety of tools that can be used to ensure that this is the case.
Let’s go through a basic DevSecOps life cycle for an application. It starts with the developers writing secure code that meets the security requirements. The Developers IDE (Integrated Development Environment) can have extensions that scan the code being written as they are being written and reports on issues to the developers based on its compliance to the security requirements.
When pushing this code into a Version Control repository, hooks can be configured to scan the code being pushed to identify any vulnerabilities. Also suppliers like GitHub provide automated tools (Dependabot) to scan any external libraries or extensions being used as part of the application that can be leveraged for ensuring that the code for the application itself is made secure.Â
The next step would be to release this secure code into a security hardened environment. With a focus on Cloud based environments, Golden Images (Golden AMIs for AWS) for traditional server based applications can be built, scanned, patched and stored on a cadence to be used as part of the Continuous Delivery pipelines. Tools like AWS Inspector, Nessus or Tenable.io can be used to scan these images for vulnerabilities and then feed on to tools like AWS Image Builder or Ansible and Packer to create these Images or Image configurations.Â
For containers and serverless based applications, the container images in the container registry can be scanned automatically on push as part of the pipeline as well. AWS ECR for ECS has this feature inbuilt to enable scanning of the container images. With respect to Serverless function environments like Lambda, the patching happens by updating runtime versions, whereas other aspects like compute patches are AWS’s responsibility since lambdas are a managed service. Â Automated events can be setup to identify releases of new runtime versions against which automated testing can happen and be released.
Also if infrastructure as code is implemented, then tools like cloudconformity and cfn-nag can be used to identify any insecure configurations in the infrastructure like security groups that are too open or incorrect NACL configurations.Â
Moreover all of these tools can become an automated and integral part of the CI/CD pipelines to enable security practises being implemented as part of the application lifecycle.Â
Our recommended DevSecOps posturing
- Automate Security updates
- Perform Common Vulnerability scanning on EC2 images by leveraging AWS Inspector
- If leveraging community AMIs, ensure that a copy of these community AMIs are hardened by doing these checks
- Perform regular patching and create GoldenAMIs to be used
- Validate and test code as it’s being written and on commit to the version control system.
- Leverage tools like GitHub actions and or Amazon CodeGuru to perform code reviews
- Scan Cloudformation code using tools like cfn-nag / cloud conformity to identify any security issues
- Isolate environments, application layers and microservices with ‘Deny’ by default and allowing only explicitly allowed communication
- Ensure Data layers are encrypted at Rest
- Ensure Data transfer between different application layers and in-between microservices are both encrypted
- Ensure Security policies in place for TLS encryption are the latest
- Ensure application dependencies are scanned and fixed for vulnerabilities by leveraging tools like Dependabot in Github
- Ensure runtime versions for lambdas are kept uptodate
- Have secure API Gateways as entry points and implement Web application firewalls that have learning capabilities, so that the rules can be automatically updated
- Ensure Data classification and integrity tagging policies are in place along with monitoring to identify issues
If you would like to know more or would like to have a conversation with us regarding DevSecOps practises and how we can enable you to implement this in your organisation please feel free to drop us a message via our contact page
