Common Questions When Establishing an Organisational Culture of DevSecOps
By : Tim Mackey | Thursday, October 15 2020 - 19:05 IWST
Tim Mackey, Principal Security Strategist, Synopsys Cybersecurity Research Centre (CyRC) (Photo by Synopsys)
INDUSTRY.co.id - With digital transformation and modernisation efforts, we’re seeing many organisations moving towards a DevSecOps paradigm. Organisations are introducing security earlier in the software development life cycle (SDLC) by expanding close collaboration between development and operations teams in the DevOps movement to include security teams as well.
As the speed and frequency of releases increase, traditional application security teams cannot keep up with the pace of releases to ensure each is secure. Design flaws and security vulnerabilities in an organisation’s product can lead to all manner of unpleasantness. Although downstream customers usually bear the brunt of security incidents, product failures can lead directly to lost revenue and irreparable reputation damage for the vendor of the product containing that software.
Gone are the days of the true waterfall development paradigm, where security teams run a tool that goes and finds a hundred issues (for example) in your application, and developers fix all of them before an organisation brings a product to market. That does not fit with the organisational culture of DevSecOps. Rather, what you still have is the tool telling you that you have a hundred issues, but how those issues are addressed changes. There may easily be critical issues that must be resolved prior to shipping product, but for the remainder, a remediation plan is created. From there, you can carve away and tackle those that have been identified and work your way down according to criticality.
To achieve this, organisations need to apply security mechanisms continuously across the SDLC so that DevOps teams can deliver secure applications with speed and quality. When organisations code with security in mind from the outset, it’s easier and less costly to catch and fix vulnerabilities before they’re released. Additionally, DevSecOps aims to break down silos between development, security, and operations teams so they can release more secure software faster. However, teams are facing several common challenges on their path to DevSecOps. Here are some of the primary questions I often come across:
Where do we start?
Surely there is more to it than just buying a new shiny tool from any security vendor, right? How can our business make sure that the application security tools integrate properly into the toolchain and pipeline?
Often when using a new security tool, that tool will produce a long list of issues to address. Prioritising and triaging that output can be a time-consuming effort leading to teams viewing security tools as creating work rather than providing value. From a DevSecOps perspective, a long list of issues shouldn’t be viewed as a negative. Instead if it’s viewed as the current state of the system, then that system can be improved. So rather than attempting to address all identified issues, a development team goal could be made to introduce no new security issues and over time resolve the identified issues as the impacted areas of code are modified.
How do we ensure our application security practices keep up with the pace of development?
Development teams want to solve each problem once, and ideally have no rework of their implementation. When a testing process identifies an issue, that creates rework. If your security strategy requires a variety of disparate systems or a disproportionate level of effort, development teams could experience significant rework and are simply not going to use the tooling. It’s also important that the security concerns identified don’t simply produce noise that then requires development teams to sieve out the “important” issues to resolve.
Knowing that security tools can identify issues that specific teams might view as noise, it’s important to align security triage efforts to the output velocity of the development team. Knowing what’s important requires experienced security professionals to analyse and identify the specific risk profile for each app and its environment and from there prioritise remediation efforts.
How do we “shift security left” without bogging down the developers?
DevOps involves the concept of shifting security left (i.e., improving security by applying security practices as early within the software development process as possible), but if security requirements and policies aren’t part of specifications, then it’s difficult to ensure development teams are compliant.
This makes it important to adopt security tools that introduce minimal disruption to the way development teams operate. Knowing that developers work within their IDE, integration of security information into the developer’s environment places that information in context to the code being worked on. There are IDE plugins available on the market that enable developers to see the results of security tests directly in their IDE as they write code. By providing contextual information, the developer is freed from worrying about the long list of potential security issues identified across all the source code and can focus on delivering high quality features from the outset.
How do we maintain visibility into our security risk throughout the application life cycle?
From chief information security officer (CISO) to application developer to DevOps engineer and beyond, it is important to have true visibility so that everyone can see exactly what’s going on. What are the key targets and are you meeting them? How are the external threats playing out as you move along?
Each organisation will have its own set of metrics against which progress is measured. These security targets should be agreed upon with development and operations input and be based on information flowing between these teams. Managing weaknesses is one of many security tasks performed which means that there is no single tool that is in a position to identify all potential weaknesses or vulnerabilities in software systems. Applying multiple techniques throughout the SDLC to both confirm earlier findings and identify unique classes of vulnerabilities is key. Consolidating the results from each tool into centralised reports shared between all teams helps foster a joint sense of ownership for security while the organisation embraces a culture of DevSecOps with continuous improvement as its goal.
Modern application development is characterised by rapid feature releases and improvements. As the associated areas that play into the creation of software continue to become more efficient, it’s critically important to ensure that security, as one of those areas, be considered in that process, transforming DevOps into DevSecOps.