Search

Contact Us

Log in

Go back to blog

Google update their Minimum Viable Secure Product

Scott Helme
Scott Helme

November 28, 2023 · 6 min read

Back in 2021, Google launched, alongside other organisations, a new security baseline for products known as the Minimum Viable Secure Product. Now, 2 years later, they’ve released an update to that standard.

mvsp

Minimum Viable Secure Product

You can read the original announcement from Google if you like, but we’ll be focusing a lot more on the update released a couple of days ago. The MVSP site is also a great place to get a lot more detail on the project and track future changes or updates.

In terms of what the MVSP project is trying to achieve, I think this snippet from the site gives a really good idea of exactly what it’s about:

Minimum Viable Secure Product (MVSP) is a list of essential application security controls that should be implemented in enterprise-ready products and services. The controls are designed to be simple to implement and provide a good foundation for building secure and resilient systems and services. MVSP is based on the experience of contributors in enterprise application security and has been built with contributions from a range of companies.

I’ve said myself many times in the past that sometimes, we need to focus on getting the basics right before we get carried away on more complex or elaborate risk reduction, and MVSP aligns extremely well with that approach. You should read through all of the requirements outlined on the site, of course, but I’m going to pick a few that are near and dear to my heart to focus on!

§1.1 External Vulnerability Reports

As I sit and write this blog post, I’m currently going through two responsible disclosure processes where I’m desperately trying to get in touch with the organisations in question. I’ve tried email to customer services, I’ve raised a support ticket, I’ve reach out to people listed as employees on Linked In and finally, I have to resort to public calls for help:

scott

This is downright ridiculous and it should not be this hard to get in touch with an organisation to let them know that they have a serious security issue!! That’s precisely what the Security.txt file is for. You can read the full details in that blog post, but the TLDR; It’s a simple text file you host with details on how people can contact you to report security vulnerabilities / responsible disclosure.

You can see mine here:

https://scotthelme.co.uk/.well-known/security.txt

https://report-uri.com/.well-known/security.txt

https://securityheaders.com/.well-known/security.txt

§1.4 External Testing

No matter how good your own security processes are, you always need another set of eyes to spot the issues you’ve missed. As a penetration tester for many years myself, I understand the value of such services form both sides of the conversation, as the ‘hacker’ conducting the test, and as the company on the receiving end. My own company, Report URI, has just had its annual penetration test completed by an external company and, as always, the full report is published for anyone to see!

pentest

I don’t think you can just have an annual penetration test and then brush your hands together and say ‘all good’, though. Penetration tests won’t find all issues, and, if you’re only having a test once per year, an issue could easily sit around for 6+ months until it’s discovered. Not good… That’s why it’s also a great to idea to use a DAST solution like Probely that can scan your application for vulnerabilities on a far more regular basis.

probely

Just like a penetration test, Probely (or any other tool), won’t find all issues, but they can find issues much sooner and much cheaper than a penetration test. There’s no point in spending thousands of dollars for a penetration tester to find and report issues that you could have found for hundreds of dollars instead. Not only that, but you can find them sooner, and we’ve all seen the graph on the cost of fixings bugs, right?

cost

Remember that all security vulnerabilities like this are basically just bugs that need fixing! The sooner you find them, the cheaper they are to fix and the less risk you were exposed to.

§2.3 Security Headers

Yeah! Who doesn’t love some Security Headers?! Not only do they recommend using Security Headers (the actual HTTP response headers), but they also recommend using Security Headers (our website!) to scan and assess your headers!

scan your site now

You can see the recommendation and link to us right here, and I’m super grateful for our free service to be mentioned like this. Head over to our site and you can perform a free scan that takes 2-3 seconds right now!

§3.3 Vulnerability prevention

After working in the Cyber Security world for so long, one thing that I realised was there are always solutions to any problem you may have, and often, they’re quite easy. The problem that I’ve always come across is that people simply didn’t know about the solution, and it’s one of the things I focus on in both training courses I deliver. You can see full details on my Training page, but here’s the summary of the two training courses I deliver:

teaching in class
practical tls and pki

Do you meet the MVSP requirements?

I’m sure that many of you reading this blog post will be able to quickly flick through the list of requirements and check them off, but can you check off all of them?

It’s really interesting to see the direction that MVSP is going in and I wholeheartedly agree with everything that’s in there. As the name would imply, this is the Minimum Viable Secure Product and not the Maximum Viable Secure Product, so you could and should be exceeding many of these requirements, especially if you’re a security focused company like we are! I’d like to leave you with this quote from the MVSP docs, highlight my own:

Minimum Viable Secure Product (MVSP) is a list of essential application security controls that should be implemented in enterprise-ready products and services.
Cybersecurity
Best Practices
Go back to blog