Software is the engine of innovation across several industries, including many that have until recently remained untouched by software. The ability to rapidly develop software and host it in elastic and easy-to-provision public cloud instances without significant capital outlay allows us to write ever more software. And very much like storage, where once stored we rarely go back to delete items we don’t need, in software rarely do organizations revisit old code to delete or re-factor it. And so we will have more and more software, much of it deployed in cloud — public or private.
The cloud providers are motivated to make it ever easier for us to write software so that they can host more of it generating more revenue. The software developers love it because they can deliver features ever faster to their customers — sometimes within the same hour.
And so the packaged software delivery model has evolved to software delivered as a service (SaaS) which doesn’t specify whether the software is hosted in a public or private cloud. With the emergence of Infrastructure-as-a-Service (IaaS) and more recently Platform-as-a-Service (PaaS), more and more SaaS is delivered on top of IaaS and PaaS. The new kid on the block is serverless which further transfers more of the responsibility to the cloud provider (Figure-1).
Figure 1: Shared responsibility model for different delivery modes
As Figure-1 illustrates, in the Legacy IT model the entire stack belonged to a company’s IT team. They focused their efforts on protecting all layers of the stack — physical data center, network, operating system, and applications. The industry spent the majority of their security budget buying firewalls and intrusion detection systems to protect the network, anti-virus and whitelisting to protect the servers, and web application firewalls and database security to protect what they could at the application layer.
As we evolve further to the right in Figure-1, the common denominator remains the application. In a modern IT environment, the security responsibilities are shared: the cloud provider is responsible for the protection of all layers except the application, leaving the IT team to focus on adequately managing their accounts and configurations in the cloud and protecting the application: i.e., your software that you are developing and hosting.
Each line of software has two sides to it: the source code and how that line of code behaves in production. Bringing the knowledge of these facets together provides a unique, comprehensive view of each line of code. And this is what makes the ShiftLeft approach unique. It provides a foundation for a platform that can be leveraged to address different needs of an organization.
ShiftLeft — our focus today
At ShiftLeft, we are initially focused on leveraging this unique approach to enhance the security of software, resulting in a unique security solution that has several benefits over traditional solutions. As an example, the ShiftLeft solution identifies the line of code that causes a certain issue in production (e.g., SQL injection or leakage of sensitive data). This reduces the time an organization spends on identifying the root cause of the issue from weeks to minutes. The other key benefit of the ShiftLeft approach is that it improves the security of your application, as opposed to traditional security solutions where the security team is constantly playing whack-a-mole, with minimal contribution to improving the quality of the application (Adrian Coyler also highlights this in his recent blog: https://blog.acolyer.org/2018/01/17/some-thoughts-on-security-after-ten-years-of-qmail-1-0/).
This alters what security teams focus on, empowering them to spend more time on higher value tasks, giving them a chance to fundamentally change the ROI of not just a product, but of the entire security organization and its contribution to the business!
ShiftLeft as a Platform
One can readily see how the benefit of bringing both the knowledge of source code and runtime information together extends to other domains. The divisions between development and runtime exist because of the legacy need for manual human intervention. However, as automation reduces the human inputs required, several aspects of the software development life cycle (SDLC) will improve and become more predictable. Application Performance Management, as an example, is a domain where the goal is to identify and address application bottlenecks. ShiftLeft’s approach is uniquely suited to addressing this problem — Figure-2 shows a portion of our current user interface that portends future functionality.
Visibility into source code via integration into CI (Continuous Integration) tools also allows ShiftLeft to identify the developer of the particular line of code. So why stop at identifying the line of code that causes an issue? Let’s also get in touch with the developer who wrote that line of code and therefore has the context at his or her fingertips — further reducing the time and effort taken to resolve the issue.
Knowledge of source code represents the “development” environment. Knowledge of runtime represents the production environment. Another perspective on ShiftLeft is that it is stitching together a workflow that brings together, for the first time, the development and the production environment. Different functions span these areas of responsibility. Developers are responsible for writing code, DevOps is responsible for hosting the software in production, and security is responsible for, well, overall security. All three functions — developers, DevOps and security — now have a single platform in ShiftLeft where they can collaborate to enhance the overall security of the applications. This is contrary to the current environment where each persona looks at a different part of the problem through a different user interface never allowing the cross-functional team to arrive at a common view of the problem — so crucial to collaboration. Isn’t this the key goal behind DevSecOps?
This is a Security Bloggers Network syndicated blog post authored by Manish Gupta. Read the original post at: ShiftLeft Blog - Medium