Shift Left: Create a Fast, Secure Development Lifecycle

JW Walton

Shift Left: Create a Fast, Secure Development Lifecycle

No one, neither security professionals, developers, nor executive leadership wants to release an application that leaves their organization open to exposure from a security vulnerability. However, in today’s software development life cycle (SDLC), development teams are pushed to deliver features and content to customers at an ever-increasing pace. But with development teams adopting Docker containers, platform as a service (PaaS) offerings from cloud providers, and infrastructure as code (IaC), security professionals feel as if they have less control over the environment they are charged to protect. The traditional model of security testing just before a release to production can pit security and development teams against each other, rather than working toward the common goal of delivering great, secure applications.

Shifting Left on Security

Shifting security “left” in the development process helps to remove much of this contention. Security testing early and often provides fast feedback loops allowing developers more time to fix security vulnerabilities in the code early in the SDLC, removing the remediation time crunch that can be experienced in a traditional security testing cycle. While shifting left on security is often talked about in conjunction with agile, lean, or DevOps development practices, it has an even greater impact when dealing with long delivery cycles. Security testing only at the end of the SDLC means remediating a potentially larger number of security vulnerabilities right before a release to production, which adds an even greater delay to getting features to end users.

Tactical Solutions

The common goal is to release feature-rich secure code, so what are the tactical steps that can be taken to shift left on security?

1. Get Security Involved Early

The first thing an organization can do to shift left is simply include the security team in architecture and design reviews, as well as team demos. This has two benefits: First, it allows the security team to provide direction earlier in the process, where security defects in design can be fixed at a much lower cost and second, it gives the security team “advance warning” on the types of security testing that will be needed for the application both in production and during development. This simple step costs nothing to implement, other than the security team’s time, and should, in the long run, save more time than it takes.

2. Automated Security Testing

Security teams can provide developers with automated security testing that allows them to identify issues early in the SDLC. Static analysis tools that function much like code linters for security vulnerabilities allow many vulnerabilities like those in the OWASP Top Ten to be identified during active development much like other unit tests.

Later during integration testing, automated scanning tools can be used to detect well-known vulnerabilities like common vulnerabilities and exposures (CVEs) and insufficient authorization systems, augmenting existing integration test procedures. While these solutions will not catch everything and will likely produce some false positives, once properly tuned they allow developers to catch most “low-hanging fruit” vulnerabilities without additional interaction from the security team after setup.

With automated security feedback during the development and early testing phases, developers are empowered to write less vulnerable code faster and without manual testing from the security team. With less time handling common vulnerabilities, security teams have the opportunity to focus on advanced threats or securing the entire software delivery process, examining continuous integration and continuous delivery (CI/CD) tools, secrets management, and the deployment platform itself.

3. Code Delivery Integrity

Testing the code on the developer’s laptop or the development team’s build server is an excellent step to a more secure application. But in order to avoid a new version of the “it worked on my machine” problem, that code must also run securely in production. While some modern tools like containers, PaaS, and IaC can shift some control from security and infrastructure teams to development teams, this shift does not have to mean less secure applications running in production. In fact, these technologies typically have built-in security features, which can result in a much more secure application.

Docker containers have thumbprints and can use signatures to validate that the container running in production is the same one that was tested with automated security tests during the CI/CD process. This same feature of Docker containers can be used to ensure developers always start from an approved base image, whether that is from an internally curated repository or just an image with a signature from a trusted source. Because containers should only contain and run process that are known when the application image is created, monitoring can watch for processes outside of the known pattern and alert on them (i.e., bash running inside a production container).

This is just one example of how container technology can ensure secure code delivery to production, but other modern platforms integrate similar capabilities and the development of security features is constantly improving with these platform technologies.

Modern Platforms Accelerate Security Response Times

Will there still be vulnerabilities in Docker, Kubernetes, PaaS databases, the cloud, etc.? Of course! As long as companies put applications and services on the internet, new vulnerabilities will be found and exploited. The good news is that most modern platforms make it easier to respond quickly and safely to these new threats as they arise as seen in the examples below.

My favorite recent example is a client who had not upgraded their privately hosted artifact repository application in over a year, which left it unpatched for numerous vulnerabilities. When they upgraded, they also moved to a Kubernetes environment hosting a Docker container version of the software. Less than a month later the vendor identified a new security vulnerability and released a new version of their software. Because the application was now running on an orchestrated container platform the client was able to make a change request for the day after the update came out, then roll out the new container with no downtime and a roll-back strategy that would only take several minutes. And that instance was just the first of three vulnerabilities that were discovered and patched in the next six months for this software. Each time the client’s team implemented the patch within 48 hours of the release.
During that same period of time, there was a vulnerability identified in Kubernetes and Docker. Because the client chose a PaaS Kubernetes solution, they were able to upgrade their Kubernetes platform and migrate their containerized applications including their artifact repository within a week of the vulnerability’s announcement.

These are just two examples of how modern decoupled solutions can improve overall security without impeding application delivery.

Shifting left on security produces an overall more robust security posture while reducing the friction between development, security, and operations. This results in delivering features and content to end users faster.

Maintaining the “Right Flank”

Shifting left does not mean the right flank can be left uncovered. While shifting left should produce better hardened applications, it cannot alleviate the need for existing testing solutions like hands-on penetration testing. These tests would be burdensome to shift left due to their manual nature. This also means that attacks targeting the infrastructure, such as denial of service attacks, will still require traditional solutions like web application firewalls to be part of the security application architecture.

It has become a common refrain that “security is everyone’s responsibility.” Given the right integration of security in the SDLC, everyone can help to make it a reality.

Do you need help shifting left on security while still maintaining the right flank? Interested in finding the right tools for automated testing and integrating them into your SDLC? We’d love to make a plan with you. Reach out to our DevSecOps experts at Security@credera.com.