What is Minimum Viable Security (MVS) and how does it improve the life of developers?

Last year, Google shook up the cybersecurity and software development community by launching the Minimum Viable Security Product (MSVP). 

Developed in collaboration with Salesforce, Slack, Okta and others, MSVP's goal is to create baseline security standardization for third-party software developers, ensuring companies in the supply chain can rely on a minimum level of security practices and standards when building their products.

For fast-paced startups building software products in the B2B or B2C or even the B2D industry (like ourselves at Jit), MSVP is great, but it represents a significant development that needs consideration. 

What even is the concept of Minimum Viable Security EXACTLY? And how can developers successfully  learn how to follow and comply with these new high level requirements?

It’s no news that with the need to deliver software products quickly and continuously, the tech world has seen a shift in operations towards DevOps, DevSecOps and ‘Shift Left Everything’ approaches. These practices were created to support short, iterative and continuous cycles, and also to avoid running quality and security tests as an afterthought and delay the release.   

But the reality isn’t running as smoothly as the theory. 

Due to multiple issues, many professionals in the industry are starting to think about taking Shift Left practices a step further through 'Born Left.' This happens today mainly in software testing that is entirely owned by the engineering team as a native function, rather than by a siloed QA or Ops teams. 

“Born Left” means that the engineering organization takes full ownership of the testing as part of the processes, known as Continuous Integration (CI), and operations through Continuous Deployment (CD). 

But what about security? 

The natural progression of this strategy puts security next in line, with Continuous Security (CS) becoming an emerging standard.

The problem with shift-left security (or anything else)

The problem with making developers responsible for more and more areas of the software cycle is the potential for overwhelming the team due to added tasks out of their domain expertise, frustrating them and causing them to be delayed with their main coding tasks. Quality, operations, security – the requirements quickly add up, and these domains often require expert knowledge, and this is particularly true when it comes to security. The cybersecurity landscape is constantly evolving with a range of ever evolving new threats to consider and the proliferation of new shift-left security tools designed to combat them.

Herein lies the problem: how can software based companies achieve dev-native security while maintaining development velocity? 

That's where the  Minimum Viable Security (MVS) approach comes into play.

What is a Minimum Viable Security and how does it relate to software development?

We are all familiar with, and many of us follow the concept Minimum Viable Product (MVP)—a product is initially built with the minimum set of features needed to test market fit and ensure the business strategy without first expending all the resources. Then, the product continues to be optimized with an MVP mindset, adding minimum viable new features or capabilities every cycle. In fact, many of the most popular software products brought by brands we all know and respect are built that way. 

During the software development, this is done iteratively, focusing on delivering a minimum baseline value with every single version.

The MVP approach to the product is analogous to the MVS approach to security.



In the image above - an MVP concept, each release is a stand alone viable one.

For developers to be willing to take over security responsibilities and fully own them, the process must work like any other aspect they are familiar with: starting small/lean, improving in a continuous and agile manner, automating as much as possible along the way, and running security 'as code.'

Let’s take this a step further. 

Minimum Viable Security in Details 

Starting with a Minimum Viable Plan

While different security checklists that can be found all over the web are available to engineering leaders, such as  Google's newly developed MVSP mentioned above, they are hardly helpful if you want to come up with a minimum security plan that is operational. 

It is crucial to always keep in mind the distinction between a high level security checklist and a product-tailored actionable plan.

A Minimum Viable Security Plan is not a checklist, but a detailed, actionable, step by step plan, that includes all of the processes and needed tools, but most importantly, defines the minimum amount of steps developers should take to make a product secure enough for a specific purpose - just in time. 

For instance, consider a security baseline that is based on a checklist and it codifies the most up-to-date knowledge and strategies designed to deal with specific threats to a company's tech stack. It needs to be as simple as possible, still to cover the entire product boundary, be continuously updated, and follow GitOps principles (with customizable code).

You can’t expect developers to master such a task without properly equipping them. 

The first obstacle developers face is knowledge. They need to be in the know of the security threat landscape, in addition to the relevant tooling (and there are many of them). They must keep updated, codify the plan and keep the codified plans evergreen. 

Unlike a checklist, an MVS plan should easily codify this knowledge and create the initial capability to continuously and automatically update the product’s security. 

As mentioned above, the plan must also constantly evolve and include additional plans at each stage to support the constantly maturing product.  A serverless plan, for instance, isn’t a SOC2 compliance plan, and isn’t an OWASP Top 10 plan and so forth. 

A codified plan is a necessity for developers that are lacking security domain expertise.

Images below taken from Jit platform: a couple of different MVS (minimum viable security) plans available to automatically activate:



Born left MVS? Security as Code

Identifying and selecting the optimal tools (open source or not) that are required as part of  implementing the plan is a resource   intensive, tedious task that takes a lot of time and effort. Integrating OSS tools into relevant stacks, testing them, and plugging them in to run automatically via CI/CD in a security-as-code format is another heavy task that is also a key part of the born left, dev-owned security mindset.

On top of that, if you wish to be effective, tool selection and integration must be continuously updated due to the nature of cyber threats and security vulnerabilities. That means it should therefore be fully automated, and properly orchestrated, both as part of the development environment and as part of the pipeline - following the concept of MVS as code.

If you expect developers to initiate the above on their own, a common problem is overstretching an already busy team. 

Adding new responsibilities in fields where developers aren’t experts take a toll, resulting in 'Shift Left fatigue’ (as seen in many discussions). That’s making the case for a Born-Left approach even more compelling, given that the born-left approach is an alternative, offering the relevant tooling to actually do the heavy lifting including the automation and orchestration. 

To summarize, automating and implementing product security plans as code and following GitOps principles in familiar development environments significantly reduces the Shift Left burden. Image below: The inventory of security actions that are included in specific MVS plans; some are shared across plans:



MVS Step 2: Security built into the CI/CD; hosted in Github

Now is the time to automatically execute the selected codified MVS plan by running necessary security tests. 

Today, as things are far from being efficient, and as products evolve and the number of security checks and tools grows, analyzing and fixing security testsresults, switching between various security tools on each pull request, and sifting through results (up to 45% false positives) can be too much even for the most competent and enthusiastic dev team. It’s just doesn’t make sense. 

However, having results, mitigation options, and risk prioritization all accessible directly through the dev environment (Github) ensures developers can work much more effectively.  



Maintaining Velocity and Avoid Developer Burnout

To meet MVSP requirements while maintaining development velocity and not burning out your developers, adopting an MVS mindset and taking an automated approach to product development is essential.

This includes automation of:

• Continuously updated and constantly evolving MVS plans
• MVS plans-as-code, with security tests generated by multiple tools. 
• Integration and orchestration of multiple security controls, in a unified and consolidated interface, as part of the dev environment and pipelines. 

There are many things to consider when it comes to MVS requirements. The tech industry has already united to formalize some  guiding principles and define standardization practices that match the evolving threat landscape, the next step is the implementation as code. 

Feel free to get started here >>  www.jit.com

‍