Born Left vs. Shift Left Security, and Your First Security Developer/Architect

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.

If you search for shift-left security you’ll get 377,000,000 results - I kid you not.

Search for a ‘minimum viable secure product’ and you’ll get 127,000,000 results, many of them published since October...

Why am I telling you this? Because if you’re the CTO or VP R&D of a start-up that wants to sell to enterprise customers, you’re probably acutely aware that the security stakes for 3rd party software (that’s you, by the way) are on the rise, and that’s putting it mildly.

Cloud product security 1.0: shift-left security

The explosion in the number of Cloud apps has put pressure on security teams and as a result, shift-left security and DevSecOps have started to gain momentum. The reason is that development organizations realized that leaving security to the end of the development process is costly and can have disastrous consequences. This is of course true for many product development activities that have been shifting left such as testing, QA, and operations.



Is shifting security left enough?

Security today is orthogonal to product functionality. Essentially, a product can be perfect from a functional point of view, yet completely flawed from a security perspective.

According to Devopedia, “The principle of Shift Left is to take a task that's traditionally done at a later stage of the process and perform that task at earlier stages.” Shift left is concerned more with the timing of an activity than with its owner or its essence.

Agile provides us with a perfect example: a scrum team is comprised of developers, testers, product owners, automation engineers, technical writers, operations… All the different functions are engaged early in the dev process, but they are still different people with different responsibilities.

So while shift left may foster more collaboration and shed light on possible issues early, it retains the traditional distributed responsibility model: developers are responsible for product functionality, while security people are responsible for product security.

The problem with that is that when security isn’t owned by the dev team, it grows as an unmanaged technical debt and becomes painful if/when an external security team tries to enforce security and compliance controls.

Introducing born-left security

Let me explain that point by introducing a new concept we at Jit like to call “Born Left”. In born-left, the developers have end-to-end ownership of the risk and security of the product they are building. In an analogy, we see more and more advanced development organizations that do not have a QA department anymore. Quality is the responsibility of developers, and as they develop code, they also define the required tests and build the automation scripts to test it. That is born left in quality. A similar transformation took place with production operations, and now progressive engineering organizations own that function with Continuous Deployment (CD)

In the same manner, to meet the velocity demand of modern software teams and to meet the rigorous security and compliance demands of security-conscious enterprise customers, product security must begin with the first line of code. It must be “born” with the first line of code - “born left” - and encompass the whole tech stack (or product boundary in security lingo). In our talks with startups, we’ve been noticing more and more CI/CD dev organizations that have a strong technical person stepping up as ‘security champion’. These security champions give their best effort to make sure their product doesn’t incur excessive unmanaged security debt.

Wait, but..

The problem? Most developers aren’t security experts. Even if you are one, you would have to invest a significant amount of time keeping up to date with the evolving threat landscape, as it relates to all the layers and technologies that make up your tech stack. Just like security engineers. In fact, it is virtually impossible for developers to hold the type of knowledge that will allow them to own security for the cloud app they are building and still maintain an agile framework. Add to that the fact that the plethora of ‘shift left tools’ - some open-source, some commercial - usually address only a specific layer or technology in the ‘product boundary’. The accumulated effort makes the task insurmountable.

The path to developer ownership of product security - a “minimum viable” mindset

For developers to really own security for the cloud app they are building, security needs to behave like all other parts of the development environment. Just like MVP for product development, security requires a minimum viable security (MVS) mindset. Start with a minimalistic approach to product security, and iteratively and continuously evolve it, just like any other function of the product.

If you’re the CTO or VP R&D of a start-up with a highly progressive, everything-as-code developer organization, you will naturally want to implement product security in the same as-code manner. Once you find or compile the ‘CTO security checklist’ for your product-tech-stack, you’d want to automate things and that will be the task of your first ‘born left’ security developer hire.

A security developer/architect enters the room

Here’s what to look for when hiring your first Security Software Developer or a hands-on Security Software Architect.

First, you’re looking for an experienced software developer who is passionate about security and building services that keep your customer data secure in the cloud.

You want them to join your highly progressive dev organization as the first security-focused developer and drive built-in security from the ground up. You basically want them to define the security architecture and direction for your rapidly-growing, early-stage company.

By hiring your first security developer/architect, you will get born left and end-to-end delivery of security-related features and services that are automatically documented.

You should also expect them to be a key contributor within the company, helping to define and drive security best practices and direction for the entire team.



What to look for in the first security hire for your startup

In a nutshell, you’re looking for a Senior Security Engineer/Architect who is:

• Excited to dive in on Day 1 to understand the current security posture and identify and prioritize security work;
• An accomplished software developer -  Experienced (100+ years) in designing and implementing innovative features related to cloud security;
• Passionate about security - Understands the evolving security and threat landscape and is eager to help define and drive progress against a security roadmap;
• A security leader - In addition to delivering security features, will also help review other engineers’ designs and code from a security perspective, and will help to define and evangelize security best practices within the larger engineering team;
• Customer-driven - enjoys meeting with current and potential customers to sell its team security posture and longer-term vision, and to understand key security requirements.

Alternatively - you can get Jit. One thing to know about Jit - she’s not human and is totally automated. Oh, and Jit is free.