In the world of application development, the “shift left” mentality has already transformed QA operations, which use shift left testing to make QA faster and more reliable.
The usefulness of the shift left mantra is not limited just to QA, however. Security teams can benefit greatly from shifting security operations to the left as well.
It may seem strange to suggest extending shift left testing practices into security. After all, QA and security operations don’t usually overlap very much.
However, security teams can learn a lot by borrowing some of the practices and strategies of QA teams that have embraced shift left testing. Below, I explain why and how DevOps organizations can use shift left testing as a model to bolster software security as well.
Defining shift left
Let’s start by explaining exactly what the shift left concept means, for the uninitiated.
In a few words, “shifting left” is taking a process that is typically performed later in the development lifecycle and moving it to a point left of its current position. In other words, you move the process to a point earlier in the delivery pipeline.
The main idea behind the shift left mentality is that starting a process earlier on will make the process more effective and easier to manage, while also saving time on the backend of the development lifecycle.
The benefits of shift left testing
Now, to illustrate the shift left concept, let’s take a look at the benefits of shift left testing.
The old-school waterfall development methodology taught us that the next step of the development cycle could not begin until all previous steps were completed. When it came to software testing, this meant that all development had to be completed first before any real testing of the software was initiated.
It is easy to see why this could cause problems for a DevOps organization at the backend of the development cycle. For instance, the discovery of any major bugs at such a late stage in the delivery pipeline could trigger the need for major code refactoring. Not exactly an ideal situation to find yourself in when a release, theoretically, should be right around the corner.
This approach also limits the ability of the DevOps organization to appropriately estimate the amount of time a project will require to bring a completed product to market. Performing all major testing at such a late stage results in risk and uncertainty, as it is nearly impossible to tell if the testing process will reveal major issues that set the project back to levels that were unanticipated when defining the delivery schedule.
Shift testing to the left can help significantly in the effort to avoid major code rewrites late in the development cycle, and can also help to relieve a lot of the risk that comes with starting the testing process so late. By beginning to test as early as makes sense for the project, the development team will find that they tend to catch many of the mistakes that lead to major bugs before they become major bugs.
This benefit is inherent to the process of constantly testing the application under construction. The development team never gets too far along with buggy code when testers are constantly verifying that things are in working order. The amount of time this will save the team as the development cycle winds down will be invaluable. This agile practice of continuously verifying the application’s quality will also serve to relieve stress on a DevOps process and lead to a more confident organization going forward as the majority of the issues that will be identified down the stretch will be minor in nature and, most likely, easily corrected.
How this relates to shift left security
The benefits described above are not unique to the testing process of the development cycle. These same advantages can also help to improve the security of an application.
If you continuously vet the application for security issues from the outset of development, it is highly unlikely that a major security concern would arise toward the end of the delivery pipeline. It’s more likely that only minor security concerns would exist as the application development process comes to a close. This is a direct result of providing visibility into the application’s quality by continuously verifying that security standards are being implemented properly—a huge time-saver (and potentially huge money-saver) down the line.
From Shift Left Testing to Shift Left Security: How to Make the Jump
Now that we’ve established why shift left security is beneficial, let’s talk about how to do it by borrowing principles from shift left testing.
The following are examples of steps that a DevOps organization can take to shift security left in the delivery pipeline:
Begin to take security concerns into consideration during the application design—just as you should take QA issues into consideration when doing development. When you inform developers early on of the security standards that should exist for the application, the development team can be mindful of the steps they should take to meet these standards and incorporate them into their code.
Use continuous integration effectively to aid in security. You already use CI to help speed development and QA cycles. You can also use CI to improve security. CI helps you to maintain an environment in which a current build of the application can be deployed that imitates the configuration of a production environment. By preventing this environment’s configuration from being altered in any way, the DevOps testers and operations folks can be sure that the application will exist as securely in production as it does in this environment. This will serve as a good battleground for testing any security concerns that may arise throughout development.
Conclusion
As application development evolves, it’s easy to see why so many DevOps teams are shifting processes such as testing and security to the left in the delivery pipeline. With time-saving benefits such as early detection of bugs and security issues, the development lifecycle is made safer and faster. This can only help any DevOps organization with an interest in building high-quality, secure applications quickly in a world where the deadlines for releasing software are tightening everyday.
Scott Fitzpatrick has over 5 years of experience as a software developer. He has worked with many languages, including Java, ColdFusion, HTML/CSS, JavaScript and SQL.
