Bringing in a third-party package to your project might save you time and effort but could be a mixed blessing, as demonstrated by recent supply-chain attacks perpetrated via packages in the NPM registry.
The potential risk posed by the unknown nature of such packages reminds me of the Schrodinger's Cat thought problem but not because of the cat being both alive and dead. Instead of asking what state the cat will be when I open the box, I wonder with it be a pussy-cat or a ferocious tiger, poised to pounce and bit my head off? A bit extreme I agree but my point is that adding code to your project without checking it thoroughly is a risky strategy.
Every time I hear the phrase "but why 'reinvest the wheel'?" it always strucks me a odd given just how many varieties of wheel there are (see hero graphic). I don't know about you, but I know which variant I would prefer my aeroplane to use!
Modern software development is heavily dependent on packages, whatever the technology stack. What proportion of your project is bespoke code and not there just to glue packages together, not much I would bet. All languages that employ 3rd-party packages (NuGet, Mavern, Pypi, crates.io, Composer) are vulnerable but NPM (and JSR), and the JS ecosystem, is particularly exposed.
This is why I drafted the following check list. Before increasing our exposure I have decided to ask some questions about candidate packages prior to inclusion.
My NPM dependency checklist
1 Read the ReadMe and the associated website (if one is provided) to confirm it meets your specific use cases, and is not more than you need.
2 Does the required version contain any known vulnerabilities? A useful tool for checking this is the Snyk Vulnerability Database.
3 Does the package employ an acceptable (Open-Source) licence. First look at NPM and if unsure, check the OPS.
Another place to check in the Open Source Initiative.
4 Other things to check on the NPM page (section illustrated above) include:
• Is it a populate package (weekly downloads)?
• Is it a major version?
• Is the size of the package acceptable?
• Is it being actively maintained?
• Is it being maintained by a single developer or a group of collaborators?
5 Check dependencies and version history.
• Is the very latest version possibly a little too cutting-edge, is there a slightly earlier version that is still being maintained?
• When was the last update?
• Are there too many or any concerning dependencies?
6 If you have more than one option, check how frequently each are downloaded using something like npm trends.
7 If hosted in GitHub, check how many issues there are and how frequently issues are being resolved.
8 Also, check how active the discussion section is and if there is a security section, check that out as well.
9 Finally, before committing to integrating the package, if there are any doubts it might be worth checking the package with the OWASP Dependency Checker
Top comments (0)