Review OpenSSF npm Best Practices

[jmbowman]

On September 1st, the Open Source Security Foundation released a guide on how best to avoid security problems when using npm. We should review this and ticket any of its recommendations which make sense for Open edX and aren't already in place. Here are the announcement and the guide itself.

[arbrandes]

@ishahroz, do you have any recommendations based on the guide? Anything we should work on adopting, or are we good?

[ishahroz]

@arbrandes, you can find my observations according to what was proposed in the OpenSSF documentation.

TLDR: We are already on the good terms to parallel the most of the recommendations as posed by the mentioned documentation. Rest, you can read more in depth below.

CI configuration

• Follow the principle of least privilege for your CI configuration. The idea is that only the minimum necessary rights should be assigned to a subject that requests access to a resource and should be in effect for the shortest duration necessary (remember to relinquish privileges). I believe this is already in effect in all the repos.

• There was also a suggestion to install the OpenSSF Scorecard Action to let consumers know how safe it is to use the relevant project (it basically adds a score to repo on the basis of security heuristics in place). This step is not very common and very few big repos like Tensorflow, Flutter, Angular displays it on their repos.

Dependency management

This step offers following recommendations:

• Before using any dependency, keenly try to thoroughly know its trustworthiness and relevant security posture by going to the dependency github repo (check correct dependency name, contributors, stars and issues reported etc.). We are already working on mitigating dependency related issues for the edx repos. [In-Progress]
• Use package-lock.json file for the dependency reproducible installation (means the same copy is installed for everyone). Only change this file when there is need to (like updating a package or adding / removing dependency), otherwise big no. This is already catered in the projects.
• Vendoring dependencies (means keeping a local copy of all the dependencies (direct and transitive) in the repository ) should not be encouraged. We are already using package.json and package-lock.json files for dependency management, so not a problem.
• It is crucial to update dependencies periodically, particularly when new vulnerabilities are disclosed and patched (use a tool such as dependabot or renovatebot). Already implemented on Github for organization wide repos and if not, we should make sure it should be this way.

Release

This step offers some recommendations like enabling 2FA for developers npm accounts, package signing and verification (done in default by npm), use proper auth tokens when publishing dependencies on the npm registry. I believe all these steps are already incorporated in the context of publisher accounts on npm.

Private packages

The idea is to stay safe from dependency confusion attacks (a malicious dependency with a name same as project dependencies’ is published on the public registries) by using scopes in package.json file. A "scope" is a @-prefixed name that goes at the start of a package name. For example, "@edx/edx-bootstrap" is a scoped package. By scoping packages on the public npm registry, we restrict them to be only published by the user or organization associated with it. Also, build will fail with error 404 if the dependent package is removed rather than silently falling back to fetch untrusted dependency from the public registries. It is already incorporated for the internal / organization dependencies by using proper scopes.

[arbrandes]

I've reviewed the guide and @ishahroz's comment above, and I'm in agreement: we're already following pretty much all of important bits (haven't seen the OpenSSF Scorecard Action in use elsewhere, either).

That's not to say our dependency vetting is perfect, but as mentioned above, there is already work in progress to improve this and replace packages that are no longer supported or not up-to-par.