Minimum Viable Secure Product
The MVSP website is a great starting point when considering how secure your product is.
Today I learned about the Minimum Viable Secure Product website. As a big fan of being secure and of lists of things to keep me right, this website is perfect for me.
From the website:
Minimum Viable Secure Product is a minimalistic security checklist for B2B software and business process outsourcing suppliers.
MVSP doesn’t claim to be a complete guide to everything you will need to get your product enterprise-ready, but it does give you easy-to-follow advice on what the minimum someone could expect from your product.
Let’s look at “4.4 Backup and Disaster Recovery”, for example. The guidance is as follows;
- Securely back up all data to a different location than where the application is running
- Maintain and periodically test disaster recovery plans
- Periodically test backup restoration
Now, I know from helping companies complete IT questionnaires around enterprise sales that if you responded to a question about backup and disaster recovery with;
We securely back up all data to a different location, we maintain a disaster recovery plan, and we test our backups periodically.
The IT person isn’t going excitedly green light the project, thinking you are the safest potential vendor they’ve ever spoken to. However, most of the time that person is so busy with other tasks that meeting these basics is enough for them to tick a box and get on with their day.
The point of the site, as I see it, isn’t so much about what you could or couldn’t write in a response to security questions, it is more that if you weren’t prepared to be able to do backups in the way they’ve suggested, then you likely won’t get any boxes ticked from that busy IT person.
How I’m going to use the site
Two of the things we do at Tosbourn Ltd. do web development for folk, and do tech guidance for them.
When it comes to writing code, I will make sure that anything I write won’t make it harder for the project to achieve the stated goals of this document.
For example, part of “2.3 Security Headers” states you should “Set a minimally permissive Content Security Policy”. This is something that is easy to do at the start of a project and incredibly difficult to retrofit in to a project.
When it comes to advising companies, I’m going to share this link with them and suggest they consider the items on it as part of a roadmap, if selling into the enterprise is something they’d care to move towards.
Thanks to Keith, for sharing this resource with me!