Skip to content

integrating retire.js vulnerability scanner and run analysis#67

Open
alexbock2 wants to merge 1 commit intomainfrom
test-retirejs
Open

integrating retire.js vulnerability scanner and run analysis#67
alexbock2 wants to merge 1 commit intomainfrom
test-retirejs

Conversation

@alexbock2
Copy link
Copy Markdown

This PR is for the integration of the static tool retire.js to find library/node module vulnerabilities within the project. NodeBB already has "retire": "^5.4.2", in devDependencies.
Files changed:
modified package.json and added "scan:retire": "retire" to the scripts.
added file retire-install-log.txt for evidence that retire was installed with npm install retire --save-dev (evidence taht I have successfully installed the tool)
added retirejs-output.txt that contains the output of the tool (artifact to demonstrate the tool has successfully run on the repo)
Run tool with npm run scan:retire. It detects vulnerabilities of various severity, including prototype pollution in lodash, stack overflow denial-of-service in underscore, and regular expression Dos in markdown-it.
Pros and cons:
Pros:
Focuses on vulnerabilities from third-party dependencies
The scan is executed quickly and is practical to be used during development or CI
Gives description of vulnerability, severity, references, and workarounds
Fast to install
Cons:
Lots of output, may be difficult to parse through if the same library has multiple instances
Repetitive output (lodash 4.17.21 vulnerability appears multiple times)
Can't make automatic fixes
Many vulnerabilities from nested dependencies in node_modules
False positives
Customizations:
Priori: Add ignore files to lessen false positives
Ongoing: ignore vulnerabilities that have been handled elsewhere

@alexbock2
Copy link
Copy Markdown
Author

Project 3B: Tool Analysis and Integration

  1. What is the name and high-level description of what the tool does? Provide a link to its documentation/source.

Retire.js is a static tool used for finding library/node module vulnerabilities within your project. It helps you detect use of version with known vulnerabilities. It can also generate an software bill of materials of the libraries it finds.
https://retirejs.github.io/retire.js/
https://github.com/RetireJS/retire.js

  1. Is the tool used for static or dynamic analysis?

Retire.js is used for static analysis. It doesn't execute the project code that it scans for vulnerabilities.

  1. What types of problems does this particular tool catch?

Retire.js catches JS libraries and dependencies with known vulnerabilities. It also catches if the version you are using is vulnerable. Some examples of vulnerabilities include prototype pollution, Denial of Service, and Command injection.

  1. What types of customization are possible or necessary?

Some customization types include ignoring directories, files, or vulnerabilities to reduce redundant reports. Retire.js can be a command line scanner, a grunt plugin, a chrome extension, a firefox extension, or a burp and ZAP plugin. It can generate a SBOM. This project may find it necessary to customize the output as JSON to integrate with CI.

  1. How can/should this tool be integrated into a development process?

This tool can be integrated into the development process as part of the CI/CD so it runs on every pull request. This would be effective since it does not overlap with lint tests and is focused on third party vulnerabilities. It could also be added as an npm script (npm run scan:retire) so that you can use the tool before committing.

  1. Are there many false positives? False negatives? True positive reports about things you don't care about?

Retire.js flags libraries and versions that are known to have vulnerabilities, but this could be a false positive if the library is not being used in a way that exposes the issue. False negatives can occur if there is a vulnerability in one of the libraries but Retire.js hasn't added it to it's database. Retire.js reports some vulnerabilities multiple times if the same library has multiple instances, which can be redundant and make the output difficult to parse through. Also some reports could be from code thats not actually used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant