Meera Rao, Senior Principal Consultant at Synopsys, discusses how organisations and businesses can best approach DevSecOps.
A brief history of Dev vs. Ops
Traditionally, the software development process is split into two distinct phases. The development team writes and compiles code, then releases it to the IT operations team, which then ensures that the code runs and remains stable in production environments where it can run and deploy applications safely providing reliable service for customers. IT security also works closely with the operations team, detects and prevents security issues exist before the software is deployed.
These distinct functional responsibilities often conflict with each other – enter DevOps.
What is DevOps?
Put simply, DevOps is an ideology. Brian Dawson, DevOps Evangelist at Cloudbees, summarises it as a culture in which ‘all participants in the software delivery cycle (not just development and operations) align around a shared goal: the rapid delivery of stable, high quality software from concept to customer.’
To achieve this, DevOps advocates automating manual processes and using tools that help teams operate more efficiently.
The three ways
The effective implementation of DevOps is underpinned by a set of key principles called ‘the three ways.’
The first way sends a rapid flow of work from development to operations, and on to delivery to the customer. This is achieved by making work visible, reducing batch sizes of said work (and work intervals) and building quality into the process by preventing defects from being passed downstream.
The second way generates a quick and constant feedback loop from right (operations) to left (development) at all stages. Teams boost feedback to avoid duplicating problems and enable more rapid detection and therefore recovery, gaining the ability to learn and improve.
The third way creates a collaborative, high-trust work environment that supports a disciplined approach to taking risks and experimenting, thus facilitating organisational learning from both achievements and failures.
DevSecOps: Security is first and foremost
DevSecOps makes security an intrinsic component of the software development life cycle, rather than limiting that responsibility to the security team, thus creating the more seamless, reciprocal flow of feedback necessary for a successful DevOps implementation.
DevSecOps requires several fundamental cultural and practical changes. Firstly, an organisation must integrate security into defect tracking and post-mortems by tracking security issues and development and operations work in the same system to ensure security visibility and prioritisation.
Secondly, it should share a source code repository containing security-approved libraries that fulfil specific security objectives. Thirdly, an organisation needs to automate security tests at every major commit of code by development or operations.
Finally, a DevOps organisation must fortify the security of its software supply chain by making vulnerability checking an integral aspect of inheriting and using open source components thus enabling developers to choose which components and versions to use. Integrating vulnerability checking during the CI process or within the binary repository or IDE helps ensure the security of the software supply chain.
DevSecOps: the tools
Covering custom code
Static application security testing is a type of security testing that analyses application source code, including byte code and binaries, for coding and design conditions that may indicate security vulnerabilities. It detects these weaknesses in code so they can be fixed before release. It’s essential to integrate an automated SAST solution into the SDLC to continuously identify quality defects and potential security vulnerabilities as custom code is written.
Dynamic application security testing (DAST) on the other hand, is performed on an application while it is running, which limits its use to later phases in the SDLC: testing, staging and production. While they may be easier to run and use than SAST tools, they cannot pinpoint specific weaknesses in application code, leaving the task of finding and fixing the vulnerable code to the developer.
Covering third-party and open source code
Like SAST, software composition analysis (SCA) statically analyses source code or binaries. SCA tools identify open source components in applications and any associated security vulnerabilities that have been reported against them. Often, SAST tools alone cannot identify these open source vulnerabilities, so it is important to incorporate SCA for a secure DevOps pipeline.
Automating and integrating
Continuous integration (CI) essentially means that the development team merges changes into the main code branch as frequently as possible. These merged changes are validated by creating a new build with the new code, then running automated tests against that build. These automated tools and tests help teams avoid the mess that results when developers wait until the day of release to merge changes into the release branch.
Continuous delivery (CD) allows teams to release new code changes to customers quickly and consistently. However, it also means that teams must have automated not only testing but also the release process. The benefits of continuous delivery are best realised when teams deploy to production in small batches, because it’s easier to troubleshoot when there are fewer changes to test and review.
Continuous deployment (also CD) speeds up the feedback loop with customers and allows developers to see their work in the live environment just minutes after they finish coding.
Dynamic testing prior to production
Testing app behaviour in pre-production environments
Interactive application security testing (IAST) analyses application behaviour during the testing phase using agents and additional software libraries. IAST can leverage existing functional tests or a DAST-like engine as the attack inducer.
Due to instrumentation, IAST results are more accurate and actionable that DAST because they show developers which lines of code are vulnerable, allowing them to prioritise remediation efforts and reduce risks without slowing down the production schedule.
Container composition security gives your operations teams visibility into the open source components in use and any associated security vulnerabilities that exist in your container images – and those running in production.
DevSecOps: implementation through training
Creating alignment between members of development, operations and security teams is a substantial process, which requires engaging training that is specific to each employee’s role.
This training is particularly important if security issues arise on a frequent basis and cannot be resolved independently by security and QA teams. In such circumstances, every employee must take responsibility for security. For this to be achieved organisations should adopt security training tools that are economical, time-effective and fundamentally motivational. This should help to create a security culture that is holistically competent, willing and effective.
Creating a successful DevSecOps culture
DevSecOps is a big undertaking, so start small. Empower your team by getting quick wins with simple changes in process, and then build on that momentum.
Take advantage of the continuous integration, continuous delivery, and continuous deployment tools that your development and operations teams are already using. Integrate static application security testing early on to evaluate the proprietary code your team is writing. Get visibility into and control over your open source code using software composition analysis tools. Evaluate the security of your applications by testing their behaviour using a range of tools, including dynamic application security testing, interactive application security testing, fuzzing and pen testing.
Finally, remember that education and cross-training go a long way toward helping your teams learn how to effectively build security into their DevOps process.
