3 ms·

Hi there, I'm one of the authors of MVSP. Thank you for your feedback! I've carefully read all the comments in this thread, and it seems there's a misconceptio

Hi there, I'm one of the authors of MVSP. Thank you for your feedback! I've carefully read all the comments in this thread, and it seems there's a misconception that MVSP replaces or substitutes enterprise or compliance controls. The goal of MVSP is to add the "S" in Minimum Viable Product (MVP). It establishes a minimum standard for a software artifact, like a SaaS app, to be considered for purchase by companies that use MVSP as an RFP baseline. MVSP originated from the security contracts' language used by big corporations like Salesforce, Google, Dropbox, and others in the FAANG MANGA group. If you believe that certain requirements could be removed, please feel free to join our mailing list and share your feedback for discussion: https://mvsp.groups.io/g/mvsp https://mvsp.groups.io/g/mvsp Our next working group meeting in the US timezone is scheduled for September.

dogman144 3y ago
Where I think we’re not aligned is you’d secure the product to secure revenue, right? Passing RFPs makes total sense but adding MSVP into an RFP check adds another layer of checklists to go through, and if it’s for RFPs that means the checklist likely gets done prior to much else, so these checklists anchor your security program ealry on. Anchoring a startup security to the MSVP would be misguided IMO, for my reasons below. It doesn’t mean it’s not useful, but it’s not where I’d burn my social capital and budget as a sec eng to meaningfully secure a firm. That’s the goal of running a security program for a startup, ultimately - get them to Series C without a serious breach, and then build out a security team to get them to IPO and through SOC2 etc. So my concern is that if you have just one shot to standup a security program, and the goal is the above, building out a appsec program with the MSVP (which also skews into a bunch of process, beyond appsec) seems to veer far into stuff that’d be unproductive for startup security team to do. Reason being is it hits what I said above in another thread - unless you have a dev knowledgeable and willing to do all the suggested appsec controls in the MSVP, that’s a sec eng asking for each of those controls. The odds of a clean devops pipeline even existing yet seems low, as to slot in SAST and some DAST approach to catch the vulns suggested by the MSVP. Or the budget for a pentest. That’s a sec eng annoying startup devs for constant code changes for code that works and is getting revenue (bc this is how the 101 startup dev usually sees these requests). That’s also a sec eng who is usually doing semi-GRC, supporting sales processes, doing all the above enterprise sec 101 stuff, and potentially ops/IT support, as there’s usually only 1 or 2 of these hires early on. So, makes me think that the MSVP as written misses the pragmatic reality of what works for startup sec programs, although I’d agree it’d work for a product. But to secure the product given realities for a startup dev, WAF for the product endpoints helps deal with the worst appsec problems and then use defense in depth on the enterprise side. Phishing the customer service rep, SaaS breach, or sketchy packages are very commonly what gets startups.

dogman144 3y ago

Where I think we’re not aligned is you’d secure the product to secure revenue, right? Passing RFPs makes total sense but adding MSVP into an RFP check adds another layer of checklists to go through, and if it’s for RFPs that means the checklist likely gets done prior to much else, so these checklists anchor your security program ealry on. Anchoring a startup security to the MSVP would be misguided IMO, for my reasons below. It doesn’t mean it’s not useful, but it’s not where I’d burn my social capital and budget as a sec eng to meaningfully secure a firm. That’s the goal of running a security program for a startup, ultimately - get them to Series C without a serious breach, and then build out a security team to get them to IPO and through SOC2 etc. So my concern is that if you have just one shot to standup a security program, and the goal is the above, building out a appsec program with the MSVP (which also skews into a bunch of process, beyond appsec) seems to veer far into stuff that’d be unproductive for startup security team to do. Reason being is it hits what I said above in another thread - unless you have a dev knowledgeable and willing to do all the suggested appsec controls in the MSVP, that’s a sec eng asking for each of those controls. The odds of a clean devops pipeline even existing yet seems low, as to slot in SAST and some DAST approach to catch the vulns suggested by the MSVP. Or the budget for a pentest. That’s a sec eng annoying startup devs for constant code changes for code that works and is getting revenue (bc this is how the 101 startup dev usually sees these requests). That’s also a sec eng who is usually doing semi-GRC, supporting sales processes, doing all the above enterprise sec 101 stuff, and potentially ops/IT support, as there’s usually only 1 or 2 of these hires early on. So, makes me think that the MSVP as written misses the pragmatic reality of what works for startup sec programs, although I’d agree it’d work for a product. But to secure the product given realities for a startup dev, WAF for the product endpoints helps deal with the worst appsec problems and then use defense in depth on the enterprise side. Phishing the customer service rep, SaaS breach, or sketchy packages are very commonly what gets startups.