ericcornelissen / js-regex-security-scanner Goto Github PK

Some of this project's runtime and development dependencies are explicitly tracked (in package-lock.json or GitHub Actions workflows), some system-level development dependencies aren't explicitly tracked but this is considered fine¹ (git, Make, Docker, Node.js & npm, EditorConfig), but some development dependencies aren't explicitly tracked and/or kept up-to-date but ideally are. This issue is about that last category.

Note: Feel free to comment on this issue if you think this list is incomplete or if you have any suggestions for improvements.

Overview

• actionlint: ideally tracked & kept up-to-date.
  • Tracked since #137
  • Updated since #160
• Grype: ideally kept up-to-date.
  • Updated since #160
• hadolint: ideally kept up-to-date.
  • Tracked since #172
  • Updated since #172
• ShellCheck: ideally tracked & kept up-to-date.
  • Tracked since #137
  • Updated since #160
• Syft: ideally kept up-to-date.
  • Updated since #160
• yamllint: ideally tracked & kept up-to-date.
  • Tracked since #163
  • Updated since #163

Relates to #38

Summary

Add a lint check for the Dockerfile to automatically enforce a common style and best-practices. As a start, use hadolint. Suggestion for alternatives/additions are welcome.

Summary

Add a lint check for the Dockerfile to automatically enforce a common style and best-practices. As a start, use hadolint. Suggestion for alternatives/additions are welcome.

Relates to #4

Summary

Add support for properly scanning projects that use JSX.

At v0.2.6, running this scanner on a project with JSX source code (in .js files, or similar) will result in errors like:

X:Y  error  Parsing error: Unexpected token <

This change should include adding .jsx and .tsx extensions in the scope of the scanner.

Summary

This is an idea to set up automation (preferably available locally and run in CI) that runs commands found in the documentation to ensure they succeed and are thus (by some definition) correct.

When tests are ran in the continuous integration setup they commonly time out, leading to either inaccurate CI results or having to rerun (sometimes multiple times, up to 8 times) the workflow. This is inefficient and annoying.

[...]
✖ Timed out while running tests

5 tests were pending in tests/main.test.js
[...]

This should be improved upon, even if it means slower CI times.

Summary

Add support for linting JavaScript snippets inside of MarkDown documentation in order to catch problematic regular expressions advertised in documentation. Regular expression appearing in documentation might be copied by readers and thus end up in code. As such, problematic regular expression in documentation should be reported on, to avoid such regular expression ending up in code (that isn't being scanned for problematic regular expression).

It should be possible to provide support for this using eslint-plugin-markdown.

Add continuous validation of the licenses of dependencies used by this project. This should make sure no dependency is introduces that's incompatible with this project's license.

This could potentially be built on the SBOM that is already being generated.

Relates to #46

Summary

Per the Release Guidelines when creating a release it's necessary to update the test snapshots. This is because the scanner output always includes the current version number.

It's not really necessary to always output the version number, and having to update snapshots every release just for this reason is not ideal. Hence, ideally this is fixed by either:

1. Updating the tests so that the snapshots don't need to be updated.
2. Updating the scanner to not output the version number by default. (preferred)

Summary

The concept of a reproducible build aims to provide some guarantees on the relation between source and output artifact, namely that building from the same source twice always results in the same output artifact. For this project that roughly means that the container image resulting from make build is reproducible.

The goal of this issue is to

1. Determine if the build is reproducible and under what constraints (e.g. target architecture)
   A. If it's not reproducible, fix that
2. Implement a test in order to continuously verify the build is reproducible

Relates to #204

Summary

Resolve outstanding TODOs for GitHub Action job egress policies:

• publish.yml
• reusable-audit.yml

Relates to #539

Summary

Dependabot is currently not configured to update the base image in the Containerfile because it does not support the file name. When Dependabot supports this file name, its configuration should be updated to enable automated update for the base image.

Summary

GitHub recently released a blog post announcing the adoption of a new MarkDown extension for displaying alerts (documentation). This issue exists to track the updating of the documentation to adopt this new extension.

To get an idea of the scope of this issue, most instances of existing "alerts" in the documentation can be found using this GitHub search query. (If you work on this locally, searching the entire codebase for the string > ** should give the same result.)

Relates to #36, #160

Summary

Find a way to avoid the duplication of the list of tools between .tool-versions:

and nightly.yml:

Relates to #12, #55

Summary

Add support for specifying (custom) file patterns that should be ignored by the scanner.

Example

When scanning ericcornelissen/svgo-action (with v0.3.1) the output will contain violations only for lib/index.cjs. While somewhat helpful, most of the code in that file is from external vendors and so is not directly relevant. In this case, it should be possible to scan the project's own source code separately from vendored code.

Relates to #38, #65, #70

Summary

Add a linter to automatically validate and enforce a style and (optionally) best-practices for JavaScript files. Initially this would probably be scoped to just the tests/. The contents of testdata/ should NOT be linted.

When a project uses ESLint itself and has in-code eslint-ignore-* comments, running this project on it results in errors/warnings about unknown rules. For example:

[...]

/project/path/to/some/file.js
  2:1  error  Definition for rule '@typescript-eslint/no-explicit-any' was not found  @typescript-eslint/no-explicit-any

[...]

This is not ideal because it introduces noise and makes the exit code (ref #3) useless.

Currently the scanner ignores the node_modules/ folder but nothing else:

This can be expanded upon to avoid scanning other files/folder that probably shouldn't be reported on.

As a source of inspiration, GitHub's Node.gitignore template can be used as inspiration. Other suggestions are welcome, even after this issue is closed.

Caused by #302, #306
Relates to #265

Summary

Resolve the following temporary logic from the reusable-audit.yml workflow configuration upon the release of v0.4.5/v0.5.0:

Related to #2

Set up security scanning of dependencies (at least the Docker image and npm). Ideally these are scanned for all changes, as well as periodically for the HEAD of development as well as the latest released version.

Relates to #1
Relates to #18

Summary

Create a RELEASE.md file with Release Guidelines.

Relates to #263

Summary

Resolve the following temporary logic from the configuration after/upon the release of v0.4.3/v0.5.0:

Summary

Upgrade from Node.js v18 to new LTS major version Node.js v20, release 2023-04-18.

To achieve this the following should be changed:

• Contributing Guidelines prerequisites
• Dockerfile base image
• package*.json files engines.node value
• CI workflows node-version values

This change should also be recorded in the changelog.

Relates to #12

Summary

In general regexes in tests with bad runtime performance aren't a big problem. So, to reduce noise, this scanner shouldn't report on bad regular expressions in tests.

Patterns to consider:

• e2e/
• test/
• tests/
• spec/
• specs/
• __mocks__/
• __tests__/
• __specs__/
• .{spec,test}.{cjs,js,mjs,ts}

Despite the intent being that the scanner scans .mjs (ESModule) and .cjs (CommonJS) JavaScript files, this is currently not the case due to two typos in the Dockerfile at line 44:

Relates to #539, #591, #592

Summary

Create a default audit command to audit container images (i.e. Containerfile) so as to stay on secure base images.

Suggestions, tips, thoughts are welcome.

Goals

The solution:

• (must) be runnable by anyone.
• (must) allow for ignoring specific vulnerabilities manually.
• (ideally) allows for ignoring vulnerabilities without fixes.

Update the Dockerfile to use some LABELs. Some ideas (suggestions are welcome, even after this issue is closed):

• name: The name of the scanner.
• description: A description of the scanner.
• version: The version of the image.
• license: The license of the image.

Summary

Given this scanner just runs ESLint with a specific configuration, and many Node.js based projects use ESLint anyway, it would make sense to guide users to adopt eslint-plugin-regexp within their project instead of using this scanner. Using the plugin directly would be easier as well as (probably) provide quicker and more frequent feedback on regular expressions in their project.

To clarify, I still believe this scanner has value as it has its own use cases, e.g.:

• By project owners of contributors while there are still problematic regular expressions that need to be addressed and so errors by ESLint are not yet as useful.
• By a third-party to scan a project without having to change the configuration of the project they're looking at.

Relates to #38, #65

Summary

Add a linter to automatically validate and enforce a style and (optionally) best-practices for YAML files. Suggestions for a linter are welcome.