Minimum Viable Secure Product

If you broke the practice of securing a company into software security, network&#x2F;platform security, and corpsec, I think the proper prioritization from an engineering perspective would be corpsec &gt; software security &gt; network&#x2F;platform security.<p>Thankfully, this checklist doesn&#x27;t lead startups into a quagmire of stupid network security tools, scanners, and assessments. But it also leaves out corpsec almost completely (&quot;single signon&quot; is an application security control in the checklist, which <i>wildly</i> misses the point), so we&#x27;ll call that a wash.<p>What I&#x27;ll say is that if you&#x27;re concerned about closing deals and filling out checklists, the appsec controls here aren&#x27;t going to move the dials much for you, and the corpsec stuff that it&#x27;s missing is going to trip you up. I&#x27;m not in love with it.<p>Also: for most companies, you&#x27;re going to want to be well past product-market fit before you start engaging consultants to assess your code. Most startups are well past 30 engineers before they have their first serious assessment. Crappy assessments can hurt as much as they help, and they&#x27;re the kind you get if you&#x27;re shopping for $5k-10k pentests while delivering with 5 engineers.

I dislike any compliance document that requires paid &amp; external vendors, so would love to see that factored out<p>SOC I vs SOC II helps get at these kinds of distinctions in practice. I&#x27;ve seen a lot of conversations enabled by that. &quot;We did the SOC I software checklist. At some point, we&#x27;ll pay vendors $50K-250K for SOC II, feel free to fast track that now as part of our contract.&quot;<p>I get why it&#x27;s there, but this kind of thing is also why, despite being designed to address a real need, initiatives like FedRAMP have been slow &amp; expensive disasters in practice. We should be pushing to self-serve &amp; automated accreditation, and all the way to 1 person projects. Anything that puts third parties, people, and $$$ in the critical path needs to be split out.

I feel the lack of a &quot;motivation&quot; blurb for every recommendation may lead to blindly checking boxes.<p>Going through a grueling security compliance process at a previous job taught me that no single list of recommendations covers all the edge cases and complexity of modern software. At least with a &quot;motivation&quot; section, I was able to piece together what was actually expected of me. It also helps with prioritization if the &quot;motivation&quot; includes the consequences of non-compliance.<p>For example: the &quot;data flow diagram&quot; is probably meant to be part of threat modeling, where you&#x27;re forced to think like an attacker. That may sound like a tedious paper-pusher task that could be put off, but actually IMO it&#x27;s really nice to do early on since a threat model can help tell you where to focus your &quot;minimal&quot; security efforts: <a href="https:&#x2F;&#x2F;owasp.org&#x2F;www-community&#x2F;Threat_Modeling" rel="nofollow">https:&#x2F;&#x2F;owasp.org&#x2F;www-community&#x2F;Threat_Modeling</a>

IP address logging can be problematic, my company considers it to be PII to have the full IP (but not if you remove the last 3 digits). I wouldn&#x27;t include that as a minimum. I also think it&#x27;s weird to include SSO without including some form of opt-in 2FA. TOTP isn&#x27;t all that difficult to implement if you are already storing passwords. Note also that I said opt-in so if 2FA is inconvenient, that is fine.<p>I also don&#x27;t feel like all of the requirements should be the minimum. Good examples of minimum requirements are the redirect to TLS requirement. External pen testing is one of the requirements that feels like a nice to have rather than a minimum bar. Minimum standards should be stuff that if you don&#x27;t do it, technically savvy people would be very concerned if someone uses your product. Stuff like lack of TLS, plain text passwords, lack of input sanitization, using an ancient web server, etc.

Very conflicted on SSO. I love it in an enterprise setting where it is assumed that your information is shared for insurance, payroll, or just work related needs. But I hate it in a consumer setting where I just want good ol’ username and password. Of course the password&#x2F;phrase should be long, uncompromised, and unique and salted and hashed and all of that, but there is just so much friction for me in SSO. I’ve even seen Next JS’s default authentication module basically drop support for username&#x2F;password under the dubious claim that it is inherently insecure.

&quot;Ensure non-production environments do not contain production data&quot;<p>Yeah right, so how can you reproduce some bugs that only appear on production data, on other environment that is not production?

Some items where alright, but I agree with what tptacek wrote elsewhere in this thread (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29102385" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29102385</a>).<p>Another list that I think is better for most startups: <a href="https:&#x2F;&#x2F;www.goldfiglabs.com&#x2F;guide&#x2F;saas-cto-security-checklist&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.goldfiglabs.com&#x2F;guide&#x2F;saas-cto-security-checklis...</a>

Great idea.<p>Currently still missing a lot of stuff I&#x27;d consider to be minimal on the corpsec side; the earlier it&#x27;s implemented then the easier it is to keep in the company rather than trying to add it later after inertia sets in. Namely:<p>* Enforce security keys on the SSO side * Set up email security - SPF, DMARC, explicitly enumerating every source of email sent from your domain with full enforcement to catch new sources before they become critical and untracked

It&#x27;s a good start but I feel like this should go hand-in-hand with privacy by default. Security is about protecting data (as well as preventing fraud and some other things) and data minimization reduces the attack surface.<p>In other words this reads a bit like how you can protect your safe full of wads of cash when the real question should be whether you need to store that money in cash in the first place.

“Minimum” secure product is interesting, I’ve definitely gone down the slippery slope of going too secure, and it doesn’t feel like the wrong thing at the time but looking back it slowed us down. Very hard to craft a minimum.

Maybe a way to help that would be to see if a library&#x2F;framework is compliant. For example, Dream in OCaml automatically adds CSRF tokens to your forms <a href="https:&#x2F;&#x2F;aantron.github.io&#x2F;dream&#x2F;#forms" rel="nofollow">https:&#x2F;&#x2F;aantron.github.io&#x2F;dream&#x2F;#forms</a> which would comply with a subpoint of point 3.3. I took that example since OWASP compliance is one of the big points and it&#x27;s not well known, I don&#x27;t want to start a framework war here. Since there are constantly new developers, I think it would help to talk more and show more security best practices.

My challenge with this guidance is the lack of focus in what is truly minimal as this list is quite extensive. As a security practitioner, I would simply threat model the product and provide minimum requirements to release.

This seems kinda cargo culty. An MVP necessarily meets the security requirements of its customers else it would not be purchased and hence is not an MVP as it is unviable in the market.<p>If your product is solving a pain point things like SOC compliance will be granted exemptions or an attestation will be provided until an audit is completed, this allows the customer to reap the benefits of the product while the i&#x27;s are dotted and t&#x27;s crossed.

I&#x27;d love if <a href="https:&#x2F;&#x2F;mvsp.dev&#x2F;mvsp.en&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;mvsp.dev&#x2F;mvsp.en&#x2F;index.html</a> was a checklist rather than bullet points and tabular data - it makes it actionable an include as part of design&#x2F;code review

That&#x27;s a great idea!<p>I hope that the idea takes hold.

I wanted to say something snarky (oh they added &#x27;secure&#x27; to mvp, better call a patent laywer). Ok I would have thought about it and come up with something, but this looks great. I went through the checklist and it makes a ton of sense, covers so many important things that people often miss, and will certainly help improve security if used.

What are &#x27;insecure JavaScript functions&#x27; mentioned in 3.3?

how would the list differ for B2C users?

Your page ( <a href="https:&#x2F;&#x2F;mvsp.dev&#x2F;mvsp.en&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;mvsp.dev&#x2F;mvsp.en&#x2F;index.html</a> ) is broken on small screens ie 13-inch laptops. This is because of the use of padding and width: 100% at the same time. You need to remove .w-full from the styles in your content.<p>Edit: I have opened a quick PR.