The Post-Spectre Web Development doc that the W3C's WebAppSec group is putting together contains some advice which seems to me to hit a forward-looking minimum bar. Some bits and pieces are old as the hills (X-Frame-Options, X-Content-Type-Options, etc), others are a little newer, but critical for a reasonable defense against side-channel attacks (COOP, COEP).

I think it's worth talking about how to incorporate that document's recommendations into the MVSP definition. What's a reasonable forum in which to have that conversation?

/cc @ChrisJohnRiley

The wording for 2.6 is somewhat confusing as it talks about "within 1 month of release" and I immediately align that with my own product/service. Working through the list of Application Design Controls, my mind is in the context of my own product/service release cycle. How can I ensure something is patched within 1 month of my own release? It didn't make sense.

Then it hit me, 🤦 this is about dependent libraries - when others release a fix for a dependant security vulnerability I need to patch my own application and release that within 1 month.

The FAQ clarifies my misread. (:facepalm: x2)

Can I suggest it would be clearer on first read to add the wording "dependent" libraries in some way to 2.6?

That would clarify the context and draw a stronger line between sections 2.6 and 3.4.

When I try yo install the package, I got an error like

error code EUNSUPPORTEDPROTOCOL
error Unsupported URL Type "workspace:": workspace:*

Which is generated by the Lines in the package.json

"@mvsp/doc": "workspace:",
"@mvsp/parcel-namer-mvsp": "workspace:",
"@mvsp/parcel-resolver-mvsp": "workspace:*",

May I know how to resolve this error?

Nodejs and npm versions:

verbose node v14.19.1
verbose npm v8.5.5

Mobile menu appears, but doesn't react on touch making mobile browsing problematic.

• Correct issue in page.njk
• Mirror fix into other njk files as required

I've read Royal's 10/27 blog post, but I'm unable to determine how or if MVSP relates to SLSA. Any insights you can offer would be appreciated. Today, SAG-PM (TM) looks for a URL to a SLSA/in-toto package in a Vendor Supplied Response File in an element called SDLCEvidenceDataURL, which it downloads as part of a risk assessment. I'm trying to determine if I need to add a separate element for MVSP in the open source Vendor Response File schema: https://github.com/rjb4standards/REA-Products/blob/master/SAGVendorSchema.xsd or if MVSP data will be incorporated into a SLSA package.

Thanks for you insights.

Dick Brooks
[email protected]
Reliable Energy Analytics, LLC
Co-Founder and Lead Software Engineer for SAG-PM (TM)

MVSP should simply reference existing standards & compliance when they exist & are widespread / widely adopted.

Otherwise, MVSP is at risk of becoming "YACR" (yet another compliance regime). I believe having YACR to map things to is not actually improve the state of affairs in the industry. Indeed there is a whole market of tools and consulting practices that results from having so many different overlapping and sometimes conflicting worldwide cybersecurity compliance regimes. I can not imagine adding another will help (ref: https://xkcd.com/927/).

For example - there are huge swaths of MVSP that could be removed and replaced with "implement according to NIST 800-53", thus ensuring that they will never get out of sync and that all of the context around the 'why' is readily available.

I further believe a better target for MVSP would be to create an easy-to-consume checklist, in plain english, for small vendors and open source projects to follow to implement some amount of already existing compliance, instead of create a new way to measure compliance. IE - help get people to implement the most important parts of, say, NIST 800-53, without having to read it all.

SLSA is a leveling framework for software supply chain integrity, with a big emphasis on provenance (understanding how an artifact was built). SLSA has some overlap with mvsp in terms of requirements. At the minimum, it seems like mvsp could benefit from a requirement around the provenance of the B2B software being delivered so producers of software can better assert as to what they are providing to their consumers, and consumers can verify they've received what was intended. One way to implement an improvement here is to require producers of the software to cryptographically sign the final package/binary. The sigstore project would be an easy way to implement the signing/verification flow. Thoughts?

I believe we are missing a piece to the MVSP checklist and that's several checklist items that involve secure software development processes. I believe the best place to add these is in section 2 under the "Application Design Controls" heading. The five additional items that I can think of now are:

1. Continuous integration and delivery processes should be required to automate the implementation of security and other tests as well as to provide an audit capture point for all changes that are pushed to prod
2. Sofware source code scanning tools to stop the developer from embedding credentials and secrets in code
3. Software source code scanning tools to stop the developer from embedding vulnerable third party or open-source libraries in code
4. .gitignore files should be required so that sensitive data and potentially malicious files are not allowed into source code repositories
5. Pull requests or merge requests should be enforced and so that all changes to environments are seen by at least one additional developer whose job it is to enforce security requirements for all code changes

All 5 of these suggestions have been vetted (in my head) against the simple test laid out in the MVSP contributing guidelines that I'm including here: "Could I consider a vendor secure if they did not comply with the control I am adding?" To my mind, no vendor could be considered secure if they didn't enforce all five of these suggestions. I mean, if we are suggesting that CSP is a requirement, which less than 10% of websites currently now use, should we not also require the use of continuous integration and associated security tests? .gitignore files and git hook scripts should be required for all software engineers as these stop potential data leaks.

Could I please request the current MVSP “checklist” contains a version number as the listed historical versions do?

The use of the term “Latest Stable release” will not help when the current version becomes legacy.

Practically, an adopter would want to enforce against a named “checklist” version, ensuring that compliance doesn’t compromise other auditable frameworks. If compliance compromises are identified, an organisation may require time to modify activities in adjacent standards areas, before moving to the next version of the MVSP “checklist” version.

See https://mvsp.dev/mvsp.en/

Regards
Nigel

Some or much of this can go under 2.5 Security libraries.

• "Simply do not" rely heavily on C and C++. There's no reason a new product trying to meet security requirements would use them.
• We can say a bit more about template languages, such as what specifically we're trying to avoid: eval-type bugs (XSS, SQL injection, shell injection, et c.). For example, Go's html/template is good, Trusted Types is good; while some other web frameworks treat DOM-XSS as the fundamental feature. Basically, we need to explain Why.
• Similarly, while SQL ORMs can be good (or bad), parameterized queries are free and worth a mention.
• I don't see any mention of fuzzing.

The README.md should have a link to the MVSP website (mvsp.dev).

Currently it does not even appear in the first two pages of Google results for "MVSP security", all that shows are media articles and blogs. The website where this code lands, is very hard to locate.

Probably a dense question, I presume there's a simple answer as to how to publish this on an internal QA web instance to poke around and try it out ?