08-24-2021
As more and more mission-critical systems move into the digital space, the importance of building secure applications and programs has expanded — and as all high profile security failures demonstrate, the consequences of bad actors exploiting lapses in a product’s security can be severe. At a bare minimum, developers cannot afford to take security for granted or assume, for example, that a new iteration of a product is secure because an older version passed a security scan. Delivering a truly secure product means keeping security considerations front of mind throughout the development process. Embedding security into the lifecycle from the start — or “shifting security to the left” in the process — allows developers to validate security continuously, reduce the likelihood of vulnerabilities in production, and ensure product integrity. To be effective, however, it is not enough to simply introduce security considerations earlier.
Processes
Engaging with security throughout the development process
Practices
Designing with quality in mind and security-centered thinking up front
Technologies
Employing technologies that integrate into existing workflows and toolsets
“Shifting left” starts with integrating security-minded thinking into development culture, where all team members are expected and empowered to adopt secure coding habits and best practices. At an enterprise level, this means embracing processes that foster organization-wide improvements, practices that embed security-centered thinking into the development process, and technologies that enable more and faster security and testing capabilities.
Implementing effective processes
Where adoption of best practices and new technology are important building blocks for shifting security left at scale, processes are what drive and define them. The practices that underpin mature development culture and allow for effective use of tools are ultimately born out of process and policy. Integration with independent verification and validation (IV&V) teams should be done early, and can be done through automation; likewise, it is crucial to work in concert with operations teams to test non-functional requirements. The gate review process alone does not constitute “embedding security from the start”: shifting security left means engaging with security throughout the development process, rather than at fixed points.
An essential process to drive security at scale is to adopt a principle of least permission — granting only the access functionally needed for a given role — and defining and assigning permissions based on role classifications rather than individual users.
By reviewing permission sets for roles, not individual users, organizations can employ a shift-left security stance at scale, taking a concept from a theory to a business practicality.
With certain applications, integration with an identity and access management (IAM) system allows for central management of secure functions, increasing the efficiency of permissions management without sacrificing added security and, consequently, allowing secure development to scale as a result.
Internalizing best practices
Shifting security left must begin with developers employing and internalizing best practices and, by extension, with the organization as a whole adopting a stance that reflects a security-first, security-throughout mindset. Setting the tone for this mindset at the top makes it simple for teams to adopt, use, and maintain secure coding practices. At a team level, it is crucial for developers to write resilient code and preemptively avoid security vulnerabilities (e.g., by sanitizing inputs to prevent SQL injections or “fuzzing” code to prevent an adverse response when receiving an improper input, such as letters or special characters in a date field). By consistently reinforcing these habits, product security can be reliably fortified, making its performance more robust under both testing and real-world conditions.
Good practices go beyond the technical writing of the code itself: a healthy approach recognizes that good code quality improves overall code security, reducing the likelihood of introducing vulnerabilities in the development process. While automation is essential to boosting the efficiency of quality testing, only human testers can be context-aware and understand why code was written as it was and thus why it fails.
As part of a security best practices mindset, developers should design with quality in mind, leveraging automated tools to consistently check code quality while proactively commenting code to enable context awareness for peer review.
For their part, peer reviewers should go beyond searching for issues covered by automated test scripts and examine for “rainy day” vulnerabilities — outside-the-box conceptions of potential security failures. Once identified, those test scenarios can be incorporated into later automated tests, further improving a shift left in product security.
Employing securitizing and testing technology
While changes to development culture make shifting security left possible, adoption of technologies to better secure and test products make it efficient at enabling quick delivery of secure products. At an enterprise level, this means emphasizing and employing technologies that integrate into existing workflows and tool sets, complementing developers’ work rather than disrupting it. Technology considerations begin with the environment itself: when employing containers, for example, it is essential to create secure and consistent environments to reduce the attack surface. Secure containers should be established at the outset and paired with a mature development culture for the highest possible security benefit. Mature DevSecOps environments use containers only for short periods and with the minimum necessary elements to run the needed code, rather than using them as effective virtual machines. When not in use, containers should be torn down, limiting the impact of a successful malicious attack.
Automated deployment tools and CI/CD pipelines enable a shift-left approach at scale: rather than having to manually test each product at or near the end of the development process, automation allows for quick and effortless testing at any stage.
When all developed code moves through CI/CD pipelines, security scanning happens continuously and automatically, flagging vulnerabilities for remediation. These tools not only save valuable time for developers and testers, but also allow security vulnerabilities to be detected and resolved early — and, by extension, prevent a cascade of overlapping security failures that might otherwise occur if, instead of shifting left, security was handled at a fixed point immediately before release.
Avoiding common pitfalls
Whether because of a failure to understand the nature or purpose of shifting security left or because of poor execution in doing so, it is important to recognize where efforts to shift left can go wrong — and, by extension, be proactive in addressing these areas to ensure that they go right. Drastic cultural changes in how security is introduced into the development process, for example, can push the limits of what developers can internalize. They may need external help to be comprehensive in their security testing. Introducing a “security champion” — a liaison with access to security subject matter experts (SMEs) — into scrum teams can go a long way toward easing the cultural transition. Likewise, taking small, actionable steps allows for easier adaptation of security into the DevOps process, with concrete actions that developers and engineers can take right away. Any incorporated technology should be in support of the development team; tools alone cannot implement a shift left in security, and if developers and testers do not use purchased tools, both employee time and organization funds are wasted. Tools should align to processes — not the other way around.
Ultimately, for security to be effective, it must be accommodating. If security measures make it difficult to carry out a task, or if they are too difficult to implement in the first place, they will go unused, and the net effect will be akin to producing an unsecured product.
Shifting security left is not about moving cumbersome barriers to an earlier point in the process; rather, it is about making security less cumbersome so that it can be addressed earlier and integrated from the very beginning of development.
