Dev-Native Product Security- Here’s Why Born-Left Security is Taking Over Shift-Left

About

This content is brought to you by Jit - a platform that simplifies continuous security for developers, enabling dev teams to adopt a ‘minimal viable security’ mindset, and build secure cloud apps by design from day 0, progressing iteratively in a just-in-time manner.

‍

‍

Shift-left. We’re all aware of the trend; coupling traditionally end of life-cycle software development activities such as testing and security more closely with the start of development, to avoid bigger issues down the track that will result in an aftermath and interfere with velocity . But is the shift left enough to solve DevSec challenges? 

Born left approach and tools are built differently in nature, to allow developer organizations to completely own product security in the sense of being committed to it and responsible for it, rather than just using appsec tools, with someone else owning it as a KPI.  

By the 90s, it was clear that the waterfall software development lifecycle (SDLC) model was out of date, and shift left was born out of a burning desire to successfully produce quality software. We wanted better quality code and we wanted it faster; this new way of operating facilitated just that. DevOps was to become a call for practice across development houses worldwide, to help automate production, testing, and more, heading towards a continuous everything future.



The shift left model is now well-regarded as best practice in the industry. Beginning critical software development tasks as soon as possible results leads to better use of resources. 

For example, it’s well-known that defects are more difficult and expensive to fix when they’re uncovered later in the SDLC. Per an IBM study, it’s 100 times more expensive to fix a defect found once it has been released or closer to it: 



source: https://www.cigniti.com/blog/integrating-performance-testing-into-app-development-process/

Shifting Security Left and DevSecOps

While DevOps practices may be mature in many organizations, there is often a missing factor that has not yet been fully shifted left: security. Enter: DevSecOps, the mash up of shifted left security with operations and testing.

Product Security is a perfect candidate for shift-left, and, along with already operationalised DevOps tools and practices such as Continuous Integration and Continuous Delivery (CI/CD), can be potentially automated to address product security from the beginning of the SDLC. When executed correctly, applications will be by their very nature more secure - a huge benefit under an ever-growing threat landscape. Not less importantly, shift left can solve the aftermath nature of traditional security practices, that compromises on velocity and on security.  

However, in practice, shift left security is far from being perfect today, and a further shift is needed. 

When Shifting Security Left  Goes Wrong



Resentment. We all know it’s there. Well, why is there resentment? 

While all the concepts and best practices to do with cloud application security sound better when you prefix them with ‘shift left’, it can be extremely tough to implement.

Within almost any organization, there is probably a lack of specialized knowledge for building a shifted left product-security program that won’t frustrate the engineering team. 

Not only this, with a wide range (I am being very gentle) of controls and interfaces, plus a need for overlaying product  security processes where human interaction is required, it’ll dawn on the organization that complete automation simply isn’t feasible.

When asked about the challenges to implementing shift left security in a satisfying way, the answers you’ll get from various teams and roles will invariably be lack of leadership support, as well as lack of engagement from developers. It’s true that without buy-in from both these sides changing practices is doomed to failure.  When you dig in further, you will learn that this lack of support is natural as today’s shift-left tools and practices are simply not enough. 

Developers are required to chase velocity, keep things agile, and with all respect to the level of automation of shift left controls, they are creating endless noise, which easily leads to alert fatigue. 

Not only this, you still need a wide product security knowledge to implement the right tools and according to a solid security plan. Where would you start? 

Shift left tools are mainly security tools that were modified for developer use - for instance a native experience in Github - but they are interfering with the main mission in keeping velocity and agility of developers and the project itself at maximum levels.

Think about today’s startups. We are talking about ultra lean organizations, where almost every aspect of the product is owned by the engineering organization. But, even with the plethora of shift-left security controls, this is just too complex to be managed properly. There’s no organized strategy, or a solid plan that is used to manage product security challenges, nobody knows which tools should be implemented, how to properly implement them, what calibrations to make, which alerts to ignore, which others to insist on fixing, how to ensure that a minimal viable security standard is met, and… you get the idea. 

So, product security is being compromised, and a bunch of developers are becoming frustrated along the way, and they develop not only software, but also resentment. 

Born Left Security - Startups will Lead the Trend (Again) 

While shift left security continues to come of age, there  will now come the rise of born left security to disrupt things further. 

When I talk about born-left solutions, I refer to solutions that were built for developers as landowners, not just users. Such tools have the KPIs of supporting velocity while managing security, and prioritizing the developer experience on top of everything else. 

When developers build solutions for their own kind, they do things differently. After all, nobody understands the pains better than they do… 

To be practical: If you want developers to love a security solution, you need to solve these challenges: 

1. It has to start with (and therefore include) a solid product-security plan that is tailored to their product (or industry, or the marketplace they are adding their apps to) and that is accessible for them. 
2. The plan should be standardized, and not something that developers are required to create - they are software engineers, not security experts. They need to be able to get it off the shelf. In practice, think of a Minimal Viable Security plan like the one described in an article in OpenView 
3. Such a solution should include full automation of the plan execution, including orchestrating the needed controls - end to end. 

Of course more advanced features can include multiple capabilities such as noise reduction, wide product security aspects, AI capabilities on top, knowledge share between developers and moe   

Born left solutions will not run over shift left, as they will have to leverage shift left controls,  but they are the only way that dev organizations can truly own product security without compromising on their underlying mission. 

To summarize, Born left security tools can be managed by DevOps, DevSecOps, or by a security developer, but they are different in nature from shift left tools. This is because they revolve and originate from the product security plan and are fully aligned to the main KPIs of the dev organization - seeing these as the only stakeholders that they are serving.

This will eliminate the anxiety and alert fatigue, remove objections and constraints, and will not add extra overheads for developers, but rather the opposite - eliminating time spent returning to code to fix security issues that arise too late. 

A special bonus - they will make compliance processes much easier to manage …

We have something to write home about 

While born left security is still in its budding infancy, as many organizations still grapple with the challenges in moving to a shifted left security process, there are sparks and upstarts who are on the precipice of an existing new time for security. 

And we all know that in tech things move fast… 

Developers, fear not. Born-left automated product-security for engineering teams will alleviate the pain. 

‍

‍