By Arun Balakrishnan, Vice President of Product and Customer Success, ShiftLeft
Shifting security left has become a catchall phrase that can be applied in haphazard ways that may put unrealistic expectations on developers and create inefficient development practices. Incorrectly defining and implementing ‘shift left’ can actually reduce security while demoralizing developers. Too often, shifting left is interpreted as “Let’s make developers fully responsible for AppSec for their applications and in particular for microservices and cloud native components.” In other words, developers that primarily code will also be tasked with configuring firewalls, setting API policies, and more. This flies in the face of common sense; we have been sub-specializing in IT and development roles, more, not less, over time. That’s why we have so many “Ops” categories now and jobs that are relatively new, from SRE to Platform Engineer. To successfully shift left, it’s really important to determine what this means for developers and, equally important, how this might apply at different stages of the software development lifecycle (SDLC). In this article, we will explain the three different stages of shifting left and what they mean for developers and AppSec teams.
Shifting Security Left Stage 1: Teaching Security Coding and Threat Models
As applications are coded from scratch, shifting left means applying best practices for writing secure code. Developers need to code for functionality and efficiency as a baseline. But in this early stage, AppSec teams should focus evangelism and education efforts with developers on how to write more secure code and sanitizing applications to minimize future problems. Broadly, this means applying “least privilege” as a general principle and writing code that fulfills its spec but reduces attack surface. AppSec teams can work in tandem with development teams to build threat models for applications under development; this process is a great way to familiarize both sides with the application plumbing and teach development teams more secure coding practices by teaching them to think about their applications like an attacker, too.
In this stage, shifting security left means:
- checking against common OWASP vulnerability classes
- turning off unused portions of libraries, network segmentation
- establishing proper API rules and policies with rate and retry limits
To validate that secure coding processes were properly followed and that the development team has established a baseline “least privilege” security stance for its applications, AppSec teams should help them test the code with software composition analysis (SCA), static application security testing (SAST) and, potentially dynamic application security testing (DAST) tools. DAST is clunky and time-consuming so it might not be practical. It is important to note that AppSec is working closely with developers to shift security left; this establishes trust and also builds a foundation for more independent shift left work over time by development teams. The conclusion of the early stage of the SLDC is the initial deployment of applications into production.
Shifting Security Left Stage 2: Prioritizing Fixes, Finalizing Processes
In this stage, code is almost ready for production and may be running in test environments or in internal canary deployments. AppSec should go over results from the SCA, SAST and DAST scans to identify the most critical problems in near production-ready code. Less advanced versions of these tools can yield significant false positive or false negative rates. To address this problem, AppSec needs to analyze and triage scan results based on “reachability” of the vulnerabilities. Reachability means that attackers can actually access a vulnerability, as demonstrated through analyzing data flows and application logic. You can’t determine reachability without combining insights from SAST and SCA, then overlaying the two. SAST tests for common OWASP problems like cross-site scripting or SQL injections, SCA tests for dependencies on insecure open source packages. Combined, they can work together to provide accurate assessments of attacker reachability. This can reduce false positive rates from upwards of 50% to less than 10%.
Based on reachability findings as a primary screen and prioritization filter, AppSec teams can then stack rank fixes required before an application can go live. It is unrealistic to assume that all fixes must be made before code can go live. The reality of continuous integration and continuous deployment is that fixes are constantly being made and developers are constantly burning down a queue. With this in mind, AppSec should set up a workable long-term triage and remediation process that allows developers to focus solely on the most critical fixes, and on a timetable that allows them to continue successfully shipping code to iterate applications.
At this stage, AppSec should help developers tune security settings and controls including:
- firewalls
- API management and gateways
- authentication and certificate rotation
- other security practices.
These should be the baseline deployment settings for security controls; you don’t want to force development teams to have to become security infrastructure experts. Developers and AppSec should work closely to test and review the impact of baseline security settings to make sure that there are not too the settings are not too restrictive, harming performance or user experience. Once established, this is the baseline to be applied each time new code pushes through the CI/CD pipeline.
Shifting Security Left Stage 3: Into Production and Beyond
The manual hard labor of battle-testing an application and applying initial fixes is done. Now, AppSec needs to automate shift left for developers by creating a semi-autonomous triaging process. This process should integrate tightly into developer workflows and tooling, constantly providing development teams with a stack rank of security fixes required. The AppSec team must recognize that assigning too many fixes will break the process by overwhelming the development teams and turning them into full-time security coders. The process should automatically pull scan findings and prioritize them correctly (with attacker reachability as a primary filter) and push an arbitrary number of the most important fixes to the developers as pull requests, viewable in their IDEs or development environments. The AppSec team should work with the DevOps team to make sure that required fixes are applied as part of release criteria for new code. For development teams, it is critical to make security fixes part of their normal coding process in sprints. Security-by-fire-drill on a quarterly or annual basis results in less focus and doesn’t as effectively build long-term comprehensiveness and competency in secure coding.
To make this last stage observable and accountable, and to automate key processes, AppSec should create easy ways to drill down into the status of ongoing “shift-security-left” work. This can be dashboards and reports or other easy ways that help AppSec, DevOps and developers stay on the same page about the progress of shift left processes and code fixes. The reporting capability is key for generating comprehensive application security metrics and reporting. This allows CISOs and senior executives to quickly see where they stand in terms of shifting left enterprise wide and to telescope in and out of shift left down to the level of individual microservices and small applications.
Conclusion: Shift Security Left the Right Way At the Right Stage
The power of “shifting left” is that everyone immediately understands the basic concept – that developers must be more responsible for security and operational tasks in a world of distributed, cloud native applications. Effectively shifting left means a thoughtful progression that mirrors the SLDC and uplevels team skills while building out repeatable processes. By following the stages of shifting left, AppSec and development teams can build a ‘shift-left’ muscle memory which empowers developers to write more secure code without affecting productivity and AppSec teams to offload the right parts of their jobs at the right time to coders. Done right, shifting left is a powerful way to drive continuous improvement in production code and development processes, at every stage.
##
ABOUT THE AUTHOR
Arun has 12+ years experience in cyber security across product management, product marketing, customer success, and engineering functions. Prior to ShiftLeft, Arun worked and consulted for security companies including Symantec, Imperva, McAfee, and Trend Micro.
Arun earned his M.B.A. from the Tuck School of Business at Dartmouth and B.S in Computer Science and Engineering from Cochin University.
