Over the past decade the “shift left” movement has been gaining traction. The premise is that if we tool-up with cyber security earlier in the development lifecycle, we should get better and more secure product/code. At first glance, this appears logical and totally makes sense: let us prevent things from happening instead of fixing things that have already happened.
Shift left testing and validation is designed to prevent the following:
- Insufficient resources allocated to testing – Insufficient testing. Test earlier and often.
- Undiscovered defects/errors and design flaws in requirements, architecture, and design, along with significant effort wasted while implementing them. – We’ve always done this to some extent in “waterfall software development” – I’d suggest this is nothing new.
- Difficult and complex testing which results in reduced code coverage during testing
And so on …
Has It Worked?
I am sure that metrics are available citing the savings, efficiency, training, and awareness of development relating to security vulnerabilities, etc., which all point to the positive. But “the problem,” “the elephant in the room,” “the mini donkey in the cottage,” “place your favorite metaphor here,” is that global metrics point to the fact that things are worse than ever…
“It’s the Software, Stupid…”
(Software is defined as the following: applications, API, OS, firewall, cloud, load balancers, browsers, web servers, toasters, etc. …)
“Secure software only does what it was designed to do. Anything else is weakness.”
We can argue about network vs. web application vs. mobile vs. API vs. ransomware vs. bots vs. quantum AI, but the fact remains that threat actors present different problems; breaches are based on different scenarios, and each attack requires a different solution.
This is an arguable but fair statement.
The method of breach, pivot and exploit is all the based on a couple of weaknesses;
Point 1: Logical weaknesses which include poor authentication, poor authorization, poor business logic design; and
Point 2: Technical weaknesses which are vulnerabilities in software- those weaknesses which can be exploited via tools, manual knowhow or “commercial grade” exploitation toolkits
- Point 1 above is due to poor design, peer review, understanding use cases and environment, and lack of awareness of potential threats/risks to the system. We have always had to contend with this.
- Point 2 is all about the software, stupid. Even though we have “shift left” coursing through our veins, even the biggest and most profitable/experienced enterprises are still producing critically weak systems which are widespread, amplifying the problem.
Most of the companies in the enterprise space have adopted a shift left approach which is great, but it certainly cannot be the sole solution to addressing the problem of software insecurity.
Shift left is static: the full stack system is being tested in an environment which does not change around it.
Change gives rise to risk:
Our environment is always changing. Even in the systems where the developer code is not subject to too much change, the landscapes in which they live are. Vulnerabilities in the browser, the web server, the cryptography, and the firewall all rely on each other and combined, deliver the system solution.
Change occurs when:
- A system does not change: Over time critical vulnerabilities are discovered. Patches are released. Yesterday I was secure, today I’ve a Critical Risk. Need to patch/Redeploy.
- When a system changes: new features deployed, new services exposed, larger attack surface, more exposed, more to attack, more headaches…
For example, an Enterprise System Defined by Numerous Components.
Many of them open-source, third party, with various degrees of secure design and development.
- A deployment environment developed by a third party, subject to vulnerabilities and human error.
- A custom web application developed by the enterprise.
- A firewall, WAF etc., also prone to vulnerabilities, coding errors.
- A third-party client-side component
- A B2B service to deliver a function we purchased and built.
In 90% of cases, Shift-Left Security would only help assure point 2 above– the developed code. We hope this highlights our main point and have painted a landscape of castles made of sand….
We Need to Shift Left, Right, and Across the Full Stack…
Shift Left makes sense when approaching system resilience and developing secure code, but NOT when it comes to effectively measuring a system’s security posture in the wild, where all the components are working in tandem.
We need to focus on run-time assessment, using automation for scale and efficiency, but we need accuracy and depth also. Shifting right addresses some of this by virtue of production safe testing of an application in its living environment. We need continuous assessment and attack surface management to continuously monitor the asset, and the environment in which it is deployed….
“Let’s get Shifty…”
Let’s discuss how the Edgescan platform can help you!
