In a previous post, I wrote about “Security Scanning SharePoint Framework” components. This post is a continuance of this.
When you have set up your workstation for SharePoint Framework Development, the last step is to execute the following command:
yo @microsoft/sharepoint
Everything for the SharePoint Framework project is then downloaded and added to the modules folder. This process is called “scaffolding.” At the end of the “scaffolding” process, a message identifying any missing dependencies and security vulnerabilities displays.
It also displays a message to execute “npm audit fix” to resolve them.
During this “scaffolding” process, components retrieved and added to the project are checked against the current list of known vulnerabilities. NPM Audit automatically runs each time you install a package using NPM. You can also run NPM Audit manually on any locally installed packages, which will conduct a security audit for the specified package.
The severity of the vulnerability is determined by the impact and exploitability of the weakness in its most common use case. The level can be any of the following:
Severity – Recommended action
Critical – Address immediately
High – Address as quickly as possible
Moderate – Address as time allows
Low – Address at your discretion
The output of the command provides a report of dependency vulnerabilities and, if available, suggested patches.
To execute a manual check, use the following steps:
1. On the command line, navigate to your package directory by typing:
cd path/to/your-package-name
2. Press Enter
3. Check that the selected package directory contains the following two files:
package.json
package-lock.json
4. Type “npm audit“, then press Enter
Using one of the examples identified within the SharePoint Framework, we can execute a manual check for example on the library “parsejson.” To check this reference, change the directory of the console to the module. Within a project, all modules are within the “node_modules” directory, with the name of the package is a subfolder. Use the following steps to execute the manual check:
1. Change the directory to the specific package using the following command: cd “node_modules/parsejson”
3. Execute “npm audit”
4. If it fails due to a missing “package-lock.json“, execute the following command: npm -i package-lock-only
5. Run “ls” and ensure the “package-lock.json” file now exists
6. Execute “npm audit”
The report should now be displayed with the specifics of the vulnerabilities explained.
Here is the complication, the issue within a specific library may not be from within the library you are scanning. For example, the “parsejson” library has a “High” and “Critical” issues that come from other dependencies. The problem then becomes how do you fix it, when the actual issue could be within dependencies of a dependency or even further.
To resolve the problem every level of the dependency needs fixing. If the path in the initial audit is:
The path for the dependency would require in this instance fixes for all of the following:
“sp-webpart-workbench”
“sp-build-core-tasks”
“gulp-core-build-karma”
“karma”
“socket.io”
“socket.io-client”
“engine.io-client”
“parsejson”
The process for resolving this is lengthy and can be complicated. Due to each library needing checking, the resolution is complicated. There are three options for addressing potential problems:
Update dependent packages if a fix exists
If a fix exists, but packages that depend on the package with the vulnerability have not been updated to include the fixed version, you may want to open a pull or merge request on the dependent package repository to use the fixed version
Fix the vulnerability
If a fix does not exist, you may want to suggest changes that address the vulnerability to the package maintainer in a pull or merge request on the package repository.
Open an issue in the package or dependent package issue tracker
If you do not want to fix the vulnerability or update the dependent package yourself, you can open an issue in the package or dependent package issue tracker.
Most of the time, security items like this, don’t factor into a typical development cycle. Personally, they should, and it needs to be a change you make as soon as possible. However, I am not naive to think that in reality when deadlines are important that “NOT” having to do this would be better. If you wanted to, you could disable the NPM Audit checks, so you would never see any messages, similar to the way SharePoint Administrators delete all the Health Analyzer issues, so there is no red bar to see in Central Administration.
To turn off “npm audit” when installing a single package, use the –no-audit flag:
npm install “Package Name” –no-audit
To turn off “npm audit” when installing all packages, set the audit setting to false in your user and global “npmrc” config files:
npm set audit false
The next question is really “Should you implement the quick fix?” or “Should I ignore the alerts?“. That is a question only you can answer, and determining the answer comes down to how security conscious you are and want to be.
For me, I like to know that my code is secure and that any dependencies are vulnerable free as well. If that is what you are looking for too, then taking the time to resolve every dependency may be the right approach. However, a more significant issue here is with the SharePoint Framework components, REQUIRING specific versions within the dependency chain, leaving you out of the picture. It is a hard one to answer, yes you should, no you shouldn’t and then well you can’t as it breaks it all.
For the SharePoint Framework components, then you don’t have any choice. However, for libraries that you include, then check them, check them and recheck them. If referencing them from a Content Delivery Network (CDN) make sure they are from the correct source. Also, check them to make sure they contain the actual code you are expecting. Nothing would be worse than including an incorrect reference or library that is then modified by a malicious actor leading to your application code executing tasks it was not originally designed to do, or leaking data outside its boundaries. This is where automated tools can really help. Adding these tools to your development lifecycle can remove the burden from you the developer to an automatic system that validates all references and even code before builds are created. This ensures that potential issues like this are captured and mitigated before the solution is deployed into a production environment.
Lastly, if there is one piece of simple advice, I can give you specifically for SharePoint Framework, it is:
The real message here is that no matter what code you are creating, a management lifecycle is required, validating code against best practices, and security practices. The application you choose to help you with this needs to provide the following features:
Known Vulnerability Checks
Memory Leak Detection
Code Analysis and Validation
Quality Gate and Best Practices
Why not check out the Security in and with Office 365 using Secure Code eBook by Jethro Seghers. This eBook is solely dedicated to explaining and helping you improve the Security in and with Office 365. Download this eBook for free today!
This blog post was originally posted on Liam’s blog