What is Minimum Viable Security (MVS)?

On October 27, 2021, Google created a serious stir in the cyber security community. Together with Dropbox, Google Launced the Minimum Viable Secure Product. The goal of this manifesto is to create a security baseline for developers of third-party products; to bring about ‘bare minimum’ requirements in terms of security.

If you are a fast-paced startup that is building a software product—just like us here at Jit the MVSP checklist was designed specifically for you. But how can we follow the checklist accurately? And what is Minimum Viable Security anyway?

The need to deliver digital products quickly has created a paradigm shift in tech development encompassing Agile, DevOps and Shift Left. The basis of these practices lies in short, iterative cycles, and not leaving out important aspects–such as quality or security–of the product until the end.

Instead of simply Shifting Left, where these functions are performed at the start of development, we instead now trend towards ‘Born Left’, where tests and ops are now fully owned by the developer team as a native function, rather than by QA or Ops. Build and test used to be external functions, now with CI (Continuous Integration), it is totally owned by R&D. The same can be said of operations, which with CD (Continuous Deployment) is now owned by R&D. 

This natural progression has security as next on the list, with Continuous Security (CS) becoming an emerging standard

CI/CD/C…S, what’s next?!

The problem is that with so many areas becoming the responsibility of developers, developers are becoming overwhelmed. Quality, operations, security: more and more domains are the responsibility of developers. Domains that they may not be experts at. 

With security, the issue of expertise is especially acute. The threat landscape is constantly in flux with a plethora of security tools to fight it. Herein lies the rub: how can you achieve dev-native security and still maintain development velocity? That’s where a minimum viable security mindset comes into play.

What is a Minimum Viable Security mindset?

We’re all familiar with Minimum Viable Product (MVP)—the product build that comes with the minimum set of features needed to test the market, to ensure that the business plan and product we are making is viable, without expending all our resources. When developing, it is done iteratively, focusing on delivering a minimum baseline value in every single iteration.

Tackling security from a Minimum Viable Security mindset means taking a look at security requirements the same way we’d look at and develop features in the MVP. 

Why no one should develop minimum viable product

For dev to own responsibility for security, the process needs to work like any other aspect that the dev-team work on; starting small/lean, improving in a continuous and agile manner, automating as much as possible, and developing ‘as code’.

What are the key elements of MVS?

Minimum Viable Plan

Sure, there are security checklists for R&D leaders such as the above-mentioned Google/SFDC/SOkta MVSP checklist, but they aren’t useful without a minimum plan. Be aware of the distinction between a general security checklist and a product-tailored plan: A Minimum Viable Security Plan (aka minimum security plan) defines the bare minimum amount of work that can be done by developers to make a product secure enough.

Think about a concise security baseline presented by a checklist that codifies the most current knowledge about one’s tech stack threat landscape. It needs to be simple, cover the full product boundary, be continuously updated, and it needs to follow GitOps principles (with customizable code). 

The first hurdle facing dev leaders is knowledge: knowing the threat landscape and knowing the security threat landscape, or the tooling landscape. A plan helps to ‘codify the knowledge’, creating a context in which product security can be executed in a continuous manner. Developers generally lack security expertise, leaving it to the team’s security champion to plan and coordinate tool rollout on a voluntary basis, on top of their job. In addition, there is a need for the plan to constantly evolve per stage to support the evolving product. 

Implemented as code

Surfacing the right tools to implement the plan takes time. Integrating them and allowing them to run automatically via security-as-code is a key part of development. Tool selection and tool integration need to be continuously updated, fully automated and orchestrated, both as part of the development environment and as part of the pipeline via MVS as code.

The problem with shifting this once-separate function onto the plates of developers is that they are becoming overwhelmed. With added responsibilities, in fields where they may not be experts, it can come at a cost. Adding more tasks to their workflows can lead to  Shift Left’ fatigue which only makes the case for a born-left approach even more compelling.

Automation, and implementing the product security plan as code, following GitOps principles, in the familiar development environment can go a long way to ease the Shift Left burden. 

developer screen

TDS (test-driven security): Built-in, relevant and actionable results directly in the dev environment

Once the relevant security plan is selected, the relevant security tests are created. Initially these tests should be ‘failing’, with the goal of running integrated and automated security tools and checks to satisfy security tests and pass them as soon as possible. 

As products evolve, and the number of security checks and tools grow, analyzing and implementing the results of the security checks, switching between various security tools on each pull request, and sifting through results (up to 45% false positives) can become overwhelming.

Having results, mitigation options and prioritization accessible directly in the dev environment ensures developers can work effectively and reduce that shift-left fatigue.

The key to achieving MVSP with an MVS mindset

To meet MVSP while maintaining development velocity, and not burning out your developers, it’s essential to adopt an MVS mindset and take an automated MVS approach in product development. 

This includes:

  • Automatically generating and adding to a constantly evolving MVS plan
  • MVS-as-code, with security tests generated from security plan items
  •  Automatic integration and orchestration of various security tools, in a unified interface, as part of the development environment

Next, the tech industry needs to come together to define the ‘MVS manifesto’ and formalize its guiding principles. Stay tuned.


Ron Zalkind
Ron Zalkind

Co-CEOs @ Jit.io, serial entrepreneurs, founders of FXP, a US-Israel venture studio
Tsahy Shapsa
Tsahy Shapsa

Co-CEOs @ Jit.io, serial entrepreneurs, founders of FXP, a US-Israel venture studio
You might also like ...
Product-Led Growth
The Definitive Guide: Product Analytics for Product-Led Growth

Achieving true product-led growth takes a winning combination of free parts of your product, virality, paying users, and more. Startups spend years (and thousands of dollars) trying to figure out the right model for viral growth – and many never do. So how do you succeed at PLG. Find out here.

by Enzo Avigo, Ashley Hockney
Product-Led Growth
How an AI sidecar product drove 30% of sign-ups: Eraser's founder on building and growing DiagramGPT

Eraser founder, Shin Kim, shares why his company, Eraser, a whiteboard for engineering teams, built an AI sidecar that ultimately drove 30% of all product sign ups. Learn more here.

by Shin Kim
The Evolution of Miro's User Onboarding: Why Big Investments Didn't Stick, and Smart Iterations Won

Miro’s Kate Syuma shares how the company’s growth team iterated smart to improve the user onboarding journey for their popular collaborative platform.

by Kate Syuma