Keeping the DevOps balance between security and speed [Q&A]
With DevOps gaining in popularity at many companies, the tension between speed and security is an ongoing issue. This tension exists because the common perception is that security slows down agile development and the CI/CD pipeline.
We spoke to Manish Gupta CEO of continuous application security platform ShiftLeft to discuss the dynamics within DevOps that create this tension and how IT organizations can achieve both speed and security.
BN: What role does automation play in terms of converting security requirements into code?
MG: DevOps adoption is growing at such a rapid pace in large part because much of what IT used to do manually is now automated through code. For example, when a new application was ready for production, IT used to manually provision a server, deploy it and install the application. Now they use code to provision a server on AWS or Azure and run the application, almost automatically.
I strongly believe that something similar needs to happen with security within DevOps. The current prevailing process of determining security requirements for a particular app is very manual. Security asks developers what kind of data the app handles and then provide the requirements (for example, security requirements for a mobile banking app are very high). Successful organizations, however, now can use application security tools to scan the application to determine the type of data it handles and convert requirements into code automatically.
BN: How important is speed of code scanning?
MG: The agile relationship between engineering and IT operations is a necessity in the age of rapid digital transformation. DevOps allows companies to excel at swiftly iterating and delivering new software products and updates across devices, applications, networks and more.
The agility of the DevOps process demands that security tools deliver application-specific security rapidly, specific to each version of each application. This eliminates inefficiencies like policy tuning and false positives and minimizes performance impact on the applications. For this reason, speed of code scanning is fundamentally important.
At the same time, most organizations still rely on large, monolithic applications that drive their revenue. The larger the code base, the more complex it is, which means more security mistakes. Code complexity and application size cause several issues for static application security testing (SAST) vendors, including declining performance speed, due to machines’ inability to successfully complete vulnerability scans of large, monolithic enterprise apps.
Organizations, therefore, need to demand solutions that overcome obstacles to speed in scanning large applications.
BN: What is the proper mindset that companies should have in order to balance speed and security within DevOps?
MG: An integral part of the mindset of inserting security into DevOps is that it is a shared responsibility. It is a process where the entire team works together to achieve an agile SDLC.
What we're talking about here is shifting security left. There isn't one specific place where security should be done in this process. Security should be inserted in each stage of the process, automated, and made a shared responsibility. The DevOps mindset then becomes one for releasing and managing applications securely. Each stage is owned by a different persona who each have unique insights. The security goal is to leverage each person's expertise to enhance security without slowing them down.
BN: What are the personas that exist within DevOps teams and why is it important to leverage each person’s expertise?
MG: Each person within engineering and security teams has a crucial role to play depending on the stage of the DevOps process they own. Let’s take a closer look at each stage to illustrate this.
Architects establish requirements in the 'Plan' stage, such as encryption and data handled by each microservice based on the sensitivity of the data it handles. Developers own the 'Code' and 'Build' phases, where they should ask questions like, "am I using an open-source library that makes my application vulnerable?" or "am I encrypting all the important data that my code is dealing with?" The key is to accomplish this with high fidelity within minutes of each build. Otherwise, security becomes a burden -- and abandoned. The 'Test' and 'Release' phases should reveal unique security insights based on the application being subjected to test traffic. The 'Deploy,' 'Monitor' and 'Operate' stages are where most security tools are deployed. These tools should not disrupt the DevOps process but should be effective and efficient at protecting the applications, while not requiring each customer to do a lot of work to tune them to their environment.
BN: What is necessary for code analysis tools to be better used and trusted by developers?
MG: Static code analysis tools (SAST) have a bad reputation. The legacy tools are slow and generate a lot of false positives, which has caused both security and developers to dislike and mistrust SAST. As a result, application security needs to be fast (an analysis that takes minutes, not hours), accurate (minimize false positives), handle custom code analysis and analysis of third party code, and help identify hard-to-find business logic flaws.
BN: How does the increased use of APIs and third-party software components change the speed vs security dynamic?
MG: More and more applications that companies build today use third-party software, including open source libraries and frameworks. In the case of one of our customers, 80-90 percent of an application’s code comes from third parties. The concern is that if developers use more third-party software, it creates more paths for bad actors to hack an application. Organizations need to ensure that the software supply chain is taken into account as part of inserting security into the DevOps process.
BN: You mentioned business logic flaws earlier. How can helping developers identify business logic flaws benefit them by moving even faster?
MG: Business logic flaws represent a distinct category of vulnerabilities that are specific to an application and business domain. Traditional SAST tools do not understand the business domain workflow, logic of the programmer and ways in which logic can be tampered with or bypassed. This demands a code analysis tool that easily incorporates the requirements from the customer that speaks to their specific business flow, specific types of data that they consider important, their encryption requirements and more. It also increases the need for a specification model to query for vulnerable conditions, business logic flaws and insider attacks that might exist in an application's code base.