SPFx npm audit results in high and critical vulnerabilities

Question

Despite the fact I am using latest version of SPFx tooling (1.13.0) released 5 days ago, when I run npm install/ npm audit I get 96 vulnerable dependencies while over 40 high and 3 critical.

Majority of them are tied to @microsoft/sp-build-web which should mean lower the risk, as the dependencies does not make it to actual package, but still it is something one does not want to see in the audit report. Manually fixing the dependencies is surely no way to go, especially when the Microsoft packages are not open sourced.

Are there some vulnerabilities checks in the SPFx tooling dev group before the packages are released?

Answer 1

Are there some vulnerabilities checks in the SPFx tooling dev group before the packages are released?

The answer is: very little / no checks are done. In fact, that would be nearly impossible. As Waldek Mastykarz says:

Nowhere in the documentation, does Microsoft state that they did a security audit of all the dependencies they use in the SharePoint Framework tooling. In its toolchain, SharePoint Framework uses many open-source packages that are not owned or even managed by Microsoft. What’s more, new vulnerabilities are discovered every day, so unless Microsoft was continuously auditing their dependency tree, the audit would have limited value.

I really like the point below. If you properly separate your dev environments from Production, then these vulnerabilities are unlikely to end up in your packaged and deployed SPFx solutions:

When it comes to dealing with reported vulnerabilities, you need to consider what the vulnerability allows attackers to do and whether that attack vector is relevant to how you use the package (tooling vs. production). For example, a regex DDoS vulnerability in SPFx toolchain is unlikely to be exploited and is a risk that you could decide to accept given its low probability.