When developers are looking at security issues in their programs, they can take one of several different approaches. Historically, though, the majority of developers have focused on a practice known as ?shifting right.? To shift right, in security nomenclature, is all about identifying bugs and weaknesses after launch and then making adjustments to deal with those issues. As DevOps teams become more skilled, however, shifting right is becoming obsolete. The future of data security is now all about shifting left.
Securing The Shift Left
If shifting right is all about reacting to threats after they?ve been identified, shifting left focuses on identifying those risks before software comes to market. And no matter the particular system ? whether it?s an app or a mainframe ? focusing on a shift left in programming means that products reach their end users with fewer coding bugs and higher quality code. This is a more cost-effective approach to development and greater security for customer data. Taking a proactive approach to data security is increasingly important because businesses are dealing with more data streams and more sensitive information than ever before. At the same time, they also have more information about what may go wrong and a greater ability to predict upcoming threats. Using predictive analytics, companies have been able to reduce operational risks, identify likely target points in their product, and predict user needs and behaviors, improving the overall product development process, from concept to layout.
Modeling For Left Shift
One reason that companies have relied on right shift for so long is that it?s an easy, but reliable approach to software development. They don?t have to hunt down the problems; users report them. Unfortunately, that also means that customers are more likely to be dissatisfied with the product and experience an excessive level of risk. Shifting left eliminates the issue of risk, but identifying risks in advance, though, is much more challenging, requires advanced modeling strategies, and relies heavily on continuous testing. In continuous testing systems, development experts are tasked with creating a variety of models that can approximate potential outcomes. Known as model-based testing (MBT), there are models for backlog ? information usually captured by user reports, as well as incremental modeling used for code updates. What this all adds up to is ultimately simple: continuous testing relies on MBT to identify issues and enable a shift left.
Act Early And Often
MBT generates an enormous amount of information, and automation is increasing the amount of data exponentially. However, many continuous testing programs are not yet fully automated, despite the fact that automation is considered a best practice. Most likely, though, a growing number of developers will move toward automation, and this will facilitate a widespread shift left and move what were formerly late-stage development issues to the beginning of the DevOps cycle.
Does Order Matter?
Changing the order of the development process may not seem very important in some respects, but when software tests for bugs and security issues come at the end of the process, each test needs to be comprehensive, and fixes can require going back to the beginning. On the other hand, by informally testing the program early and often, which is the continuous testing philosophy, developers get key feedback throughout the process. This makes it easier to correct the problem code and to identify major future issues without deconstructing the entirety of the program. Shifting to the left isn?t just about overall security. It?s also an issue of deployment. Continuous testing isn?t a goal in and of itself; it supports a business?s ability to put that new code into action. In an environment in which app updates are released regularly, continuous deployment is critical. Developers build and deploy in a constant cycle, creating what David Williams of CA Technologies calls ?continuous everything.? Today?s development and deployment timelines are shorter than ever, which is why businesses need to enter the continuous everything phase of software development, but those who have already done so can attest to the benefits. In particular, by shifting from manual continuous testing practices to an automated variation, DevOps teams have been able to deploy programs 80% faster than during the manual phase. The end result, then, is a higher quality product, a product that can more quickly be adapted in response to any performance problems, and a product that can be in customers? hands more quickly. Customers may not understand the language of left shift, but they know that?s what they want. For developers, though, left shift is a challenge with its own benefits. Yes, it means reorganizing the DevOps process, but once the system is in place, it is indeed faster and more cost-effective than right shift models. Despite the current lag in continuous testing and automation adoption, once in place, DevOps professionals will see a clear difference in their project outcomes. The next frontier is to the left.
