0 comment

NPM 6.0 and SharePoint Framework – Security Reporting

In case you recently upgrade NPM to Version 6.0 and created a new SharePoint Project through the Yeoman generator. There is a chance that you recognised the following new notification at the end of the NPM installation process.

Security Report after SPFx installation

Security Report after SPFx installation

What there are five vulnerabilities, one with severity low and four with severity high and I can run ‘npm audit’ to get a detailed report?

Don’t start to scream “fire” and run in panic through your office, uninstall all your SPFx projects from all your tenants, clean up your CDN, keep calm and learn the reason why this gets now reported after the installation.

1 – Open Source – A house built on trust

With an open source project, you have to trust or research that none of your packages contains malicious code. You used jQuery in the past, and this is a trustful source? Yes in general it is but there multiple reports where jQuery got replaced with malicious code. In September 2014 the website of jQuery was compromised and served malware.

It doesn’t have always been that extreme. In some cases, bugs in the libraries can put your server in danger. Bugs you are not even aware of and hard to spot either.

Especially with NPM, you have to trust that the package is well written or performance a costly detailed security analysis. An analysis you have to do again when a new version gets released. To some extent you have to trust it won’t harm your final product.

2 – NPM Security Issue

Yes, there is no doubt about that some scripts available on NPM are potentially insecure or contain bugs that can cause security issues in your application.

Waldek Mastykarz has an excellent article on his blog concerning external scripts in general. “What external scripts is your SharePoint Framework solution using?“.

On Medium there is another article that I highly recommend you to read. This article is named “The Node.JS Ecosystem is Chaotic and Insecure“.

Like Waldek’s post, this article describes that you should use NodeJS and NPM responsible and not install any ‘is-odd‘ package just because you read somewhere in a forum that this solves all your problems.

To make sure to become more secure the people behind NPM started to implement better security in future. The security scanner is the first step in the process and should raise awareness for potential security issues. You cannot avoid this scanner because now it gets automatically launched whenever you install a new NPM package.

Security report after jQuery installation

In the screenshot, I installed jQuery to test this behaviour. The result is that we still have five potential security issues. This installation has not increased the overall issue count.

3 – What does it mean for SPFx

The command ‘npm audit’ appeared first in NPM version 5.10 and performed a security analysis. The result is a detailed analysis of possible issues solutions how to make your application more secure.

In case of SPFx, the reported issues are ‘gulp’ related, and the only solution would be to upgrade to a newer version.

The problem, you cannot upgrade to a newer version because there are significant changes that might break your development environment and your projects. You might be unable to open workbench or embed your web parts in Office 365.

Full npm audit report

Over time I’m pretty sure Microsoft will update ‘gulp’ to a newer version, which doesn’t mean that other possible security issues rise again, but at least those potentials are secured.

The Gulp issues are all related to the build pipeline and not to the final package you get and install on Office 365 this means that you are only insecure when you run gulp locally.

You can use Gulp to run a fully operational server installed on the internet your application that might be at risk, but in case of local development, the risk can be neglected and only affects you maybe, potentially maybe, when you develop a solution.

The majority of the SharePoint Framework is written and owned by Microsoft. The reduced all the surrounding packages as much as possible to provide a robust framework and development environment. One reason why only five issues get reported.

Personally, I try to reduce the number of NPM packages myself on my NodeJS projects as much as possible. In case of my SimpleStyle Guide, the result looks more catastrophic.

SimpleStyle NPM Audit report

Again this issues only arise when the style guide application is running and not when the output of HTML, JavaScript and CSS gets loaded from a static website.

4 – Use NPM Audit – it is a chance

Keep an eye on the ‘npm audit’ and check your source code regularly. Especially when you install a fancy UI library that creates lovely responsive sliders for example. They might contain unwanted security issues.

It is only a first small step to make NPM more secure, but it is an important one because it raises the awareness of potential issues.

The next step to make NPM more secure is to sign packages to prevent man-in-the-middle attacks. Such mechanism should make sure that the package you downloaded is the package you wanted.

Leave a Reply

Required fields are marked *.

This site uses Akismet to reduce spam. Learn how your comment data is processed.