apollo (1)

Charlotte is an experienced security professional with a long history of successfully and securely leading global brands, including PwC, Hewlett-Packard, and Daimler Trucks North America. She is a Certified Secure Software Life Cycle Professional (CSSLP), Certified Information Systems Security Professional (CISSP), and Certified Ethical Hacker (C|EH), passionate about proactive and defensive security through early lifecycle improvements.

Former Director of Security Engineering

Charlotte Townsley

Focusing security efforts early in the SDLC provides proactive, impactful protection against evolving threats and attacks

## Shifting Left for Improving Security Outcomes

**TL;DR:** Shifting security to the left, or early in the Software Development Life Cycle (SDLC), creates more effective, less costly security controls, promotes developer ownership of security principles and features, and helps reduce risk to our organization.

## What does Shift-Left Mean?

Shift-left refers to a focus on security efforts early in the Software Development Life Cycle (SDLC). These early phases include early developer and technologist awareness efforts, as well as secure design, development, and deployment of software.

![SDLC](https://images.ctfassets.net/23aumh6u8s0i/7irltF8FB74O9aFLUP84Xa/9e0f7fe1f8ee1c5a16a6d03f343b8bda/image1)

Shift-left is a well-known term in the [software development and testing industry](https://dzone.com/articles/software-testing-trends-to-watch-for-in-2019). It refers to both security and non-security specific testing and evaluation of an application early in the development lifecycle. A shift-left mindset helped develop some notable non-security specific techniques such as [Test Driven Development (TDD)](https://www.guru99.com/test-driven-development.html) and [Agile methodologies](https://smartbear.com/learn/automated-testing/shifting-left-in-testing/). 

## What are the Benefits of Shift-Left?

The clear benefit to shift-left is that a focus on the early design and development phases translates to [fewer defects in the later stages](https://www.cigniti.com/blog/successfully-implementing-tdd-bdd-to-enable-shift-left-testing-approach/). Shift-left is well-recognized as an approach that [lowers the cost of defect remediation](https://www.bmc.com/blogs/what-is-shift-left-shift-left-testing-explained/). In fact, the cost of fixing code flaws [increases exponentially with each phase to the right in the SDLC that they are found and remediated](https://deepsource.io/blog/exponential-cost-of-fixing-bugs/). The 2019 Poneman study estimated that vulnerabilities detected in the early [development process cost around ~$80 to remediate. However, the same vulnerabilities can cost ~$7600 to remediate](https://resources.whitesourcesoftware.com/blog-whitesource/shift-left-testing) if detected after deployment to production. This is a _9400% increase in cost_!

It is worth noting that the term shift-left can be a misnomer, as it denotes a linear phased approach, rather than a continuous approach. In actuality, software is developed in an infinite cycle of continuous design, development, remediation, integration, delivery, and monitoring.

![Continuous Development Life Cycle](https://images.ctfassets.net/23aumh6u8s0i/3R7h35zCpEV3jm0snCemXc/b774324a5e660ff997faecf2e241f82f/image2)
Continuous Development Life Cycle

Because each phase in the infinite cycle is discrete and identifiable, the term shift-left is still helpful in understanding the efforts in moving security earlier in the life cycle. As a mindset, shift-left is both a way to train developers, and a way to design, develop, and deploy code more securely and with less cost. So while we refer to shift-left to identify our efforts, we are not promoting the abandonment of a continuous development and deployment cycle.

## What is Auth0 Doing to Shift-Left in Security?

The focus on defensive and preventive controls early in the SDLC encompasses several key initiatives at Auth0. These initiatives include the improvement of **Static Analysis Security Testing (SAST)**, the creation and publication of the **Secure Software Benchmarks (SSB)**, and the development of **Security Champions**.

The security team is improving **Static Analysis Security Tests (SAST)** for all new and existing code bases at Auth0. SAST tools automate security-specific code reviews and help identify and remediate security-relevant coding flaws that directly translate to exploitable flaws in production. Finding these flaws early adds great value to the organization in terms of risk reduction. 

SAST improvements include better traceability of flaws to [OWASP Top 10](https://owasp.org/www-project-top-ten/) and [CWE Top 25](https://cwe.mitre.org/top25/archive/2019/2019_cwe_top25.html), and improvements in the ease of integration with existing development IDEs, source repositories, and build tools.

These SAST tools support both manual deployment pipelines, and automated pipelines where controls can be integrated into a model known as [DevSecOps](https://www.sumologic.com/insight/devsecops-rugged-devops/). DevSecOps helps incorporate security into all stages of the software development workflow and thus helps to avoid security bottlenecks since [security checks are run continuously along with the phases of the SDLC](https://insight.claranet.co.uk/driven/the-devsecops-mindset) rather than only at the end of the life cycle.

![DevSecOps](https://images.ctfassets.net/23aumh6u8s0i/7l22UtdExJhSxYf40OhyBJ/47553bad506159065c5482c4ac9c453d/image3)
DevSecOps

The **Secure Software Benchmarks (SSB)** comprehensively document the expectations and implementation details for creating secure applications at Auth0. The SSBs can be used as a baseline for teams to assess the security of applications. However, their greatest value will be as an early lifecycle guide to plan, develop, and deploy their applications according to security best practices. 

The SSBs are rich in both breadth and depth and are based on industry best practices, including the [OWASP Top 10 Proactive Controls](https://owasp.org/www-project-proactive-controls/). They include details such as secure coding techniques, SAST tools integration guidance, expectations around protecting data at rest, in-transit, and in-memory, how to securely create production builds, and how to hook into monitoring controls. The SSBs are meant to be an ongoing tool for assessment and creation of secure applications.

The security training and awareness team runs a mentorship program for Auth0 developers with interest in security. The purpose of the program is to help amplify and socialize the security messages within development teams and scale security operations. Security-minded developers serve as **Security Champions** and receive training and guidance in how to implement and interpret **SAST** results. 

Security Champions will also participate in briefings with the security team to help them understand and socialize the **SSBs**. Security champions have a defined path for advancement, including apprentice, intermediate, and advanced champion criteria that define the milestones and maturation of the champions at Auth0.

The security awareness team will combine **SAST**, **SSBs**, and the **Security Champions** program in an internal certification program for Node.js developers. This **Auth0 Node.js Secure Developer Certification** expands upon the current hands-on secure code training. The certification includes general security concept training, Node.js secure coding guidelines defined in the SSBs, threat modeling, best practices for implementing and interpreting SAST, risk assessments, offensive security, secure architecture, hands-on labs, and skills formal assessment. The security team will begin the roll-out of the certification with our Security Champions, receive feedback from these champions, then open the certification to our development community within Auth0.

We are also applying shift-left to expand our machine image scanning capabilities within our infrastructure and cloud security program. Rather than scanning images after deployment, scanning will take place at the time of image creation. Scanning at the time of image creation provides early feedback for service owners as they make decisions about installed packages and versions. The scanning services are accessible via API, and thus can be automated as part of the development life cycle and seamlessly integrated with vulnerability management tools and processes. 

## What about Late Life Cycle Efforts at Auth0?

There are several successful late life cycle efforts at Auth0 that we plan to continue and grow with a particular focus on automation. These offensive and detection efforts are crucial in finding security vulnerabilities, detecting and handling incidents, and helping teams assess the security of their applications as the threat landscape continuously changes. We will continue to offer our private bug bounty program, conduct offensive security tests, encourage contributions through our Responsible Disclosure program, and offer threat modeling for secure design. We encourage submission to our [Responsible Disclosure](https://auth0.com/responsible-disclosure-policy/) program and use this disclosure program as an entry point to our private bug bounty program.

The defensive and offensive programs do not exist in vacuums. Instead, offensive programs help to inform our defensive efforts in what the security industry terms a purple and orange team functions, where [_purple_ describes how defenders (such as our Detection and Response team) learn from attackers, and orange describes how builders (our developers) learn from attackers](https://danielmiessler.com/study/red-blue-purple-teams/).

Auth0 Security strives to continuously improve our security posture. By embracing shift-left, we create more effective, less costly security controls, promote developer ownership of security principles and features, and help reduce risk to our organization. This approach results in a more secure solution for our customers at a lower cost.

<include src="asides/AboutAuth0" />

"shift-left"