nodejsscan: a SAST scanner for Node.js that wraps Semgrep and libsast

What nodejsscan scans and who it is built for

nodejsscan is a static application security testing tool that reads Node.js source and reports security problems. It is not a runtime monitor and it does not instrument a running process. The README describes it as a "Static security code scanner (SAST) for Node.js applications powered by libsast and semgrep", which places the detection logic in two external engines rather than in hand-written checks inside this repository.

The audience is narrow and fairly clear. Developers who want a scan before a commit, and DevSecOps teams that want a scanner inside their own pipeline instead of a hosted service. The README lists GitHub Action, GitLab CI/CD and Travis CI integrations, plus Slack and email alerting, which is the shape of a tool meant to run unattended on a schedule or on push. If you are auditing a single file by hand, the web UI is more machinery than you need.

One structural detail matters for anyone evaluating the codebase: the primary language reported for the repository is CSS, not Python. The templates and static assets dominate the file count. That does not change what the tool does, but it does mean a quick skim of the repository will tell you very little about the scanner itself. The Python side lives in nodejsscan/ and web/, and the detection rules live in the separate njsscan project that requirements.txt pulls in.

How libsast and semgrep produce a finding

The data flow is a chain of three pieces. Your source tree goes in. libsast handles the scanning orchestration and the pattern matching layer. semgrep supplies the rule engine that libsast drives. Findings come back to the nodejsscan web application, which stores them in Postgres through Flask-SQLAlchemy and renders them in the dashboard and charts shown in the README screenshots.

The dependency list makes the split explicit. requirements.txt pins njsscan==1.0.1 alongside flask, gunicorn, jinja2, psycopg2-binary, GitPython and Flask-SQLAlchemy. njsscan is the scanner library that carries the Node.js rules; nodejsscan is the web application and persistence layer around it. GitPython is present, which is consistent with scanning a repository rather than a loose directory, though the README does not spell out the clone or fetch behaviour.

That layering is the main design decision to understand before adopting it. Rule quality is not something this repository controls directly. When you upgrade nodejsscan, you may or may not be upgrading the underlying rule set, and the pinned njsscan==1.0.1 in requirements.txt is the version you actually get unless you change it. Anyone comparing nodejsscan against a hosted scanner is really comparing the njsscan and semgrep rules against that vendor's rules, with nodejsscan contributing the UI, the database and the alerting.

Installing nodejsscan with Docker and running a first scan

The fastest path is the published image. The README gives two commands, and the container exposes the web UI on port 9090.

docker pull opensecurity/nodejsscan:latest
docker run -it -p 9090:9090 opensecurity/nodejsscan:latest

After the container starts, the interface should be reachable at http://127.0.0.1:9090. The docker-compose.yml in the repository describes the same service with hostname nodejsscan, a single replica and a restart policy of on-failure, mapping the same 9090:9090 port pair. If you prefer compose, that file is the starting point.

A local install is more involved because it needs Postgres. The README says to install Postgres and configure SQLALCHEMY_DATABASE_URI in nodejsscan/settings.py or as an environment variable, then run the following from a clone.

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
python3 manage.py recreate-db
./run.sh

The recreate-db step is described as a one-time schema creation. run.sh then serves the UI at http://127.0.0.1:9090, the same port as the container. Note the platform constraint stated plainly in the README: from version 4 onwards, Windows support is dropped. The Dockerfile itself is built on postgres:12.12 and installs python3.9, so the image and the local instructions assume a Linux or macOS host.

For pipeline use, the README points at the separate njsscan project for the command line interface and Python API rather than documenting flags here. That is where you should look if you want findings as exit codes instead of as a dashboard.

Windows is out, and the release cadence is slow

The Windows limitation is not a footnote. The README states it directly: "From version 4 onwards, windows support is dropped." If your developers work on Windows machines and you want them running scans locally, nodejsscan is the wrong tool for that workflow. The container route works, but that pushes every developer toward Docker or WSL rather than a native install.

The release history is the second constraint. The most recent release listed is v4.8 from 2023-09-02, preceded by v4.7 in 2022-07-17 and v4.6 in 2022-01-31. The last push to the repository was on 2026-09-21, so the codebase is still receiving commits, but tagging has not followed at the same pace. A team that pins to a release tag is working with a rule set that was packaged in 2023. A team that tracks master gets the newer commits with no release notes to read.

There is also a scope boundary worth stating. This is a Node.js scanner. It will not review your Dockerfiles, your Terraform, your Python services or your front-end dependencies. If the Node.js application is one component of a larger system, nodejsscan covers one slice of it and you will need something else for the rest. The README does not describe any multi-language mode, and the dependency on njsscan suggests the rule set is JavaScript-specific.

How nodejsscan differs from Semgrep and Snyk

The closest comparison is semgrep itself. nodejsscan drives semgrep through libsast, so the underlying pattern engine is the same family of technology. The difference is packaging and opinion. Running semgrep directly means you choose the rules, write your own if the registry does not cover your framework, and wire up your own reporting. nodejsscan arrives with a Node.js rule set already selected, a Postgres-backed findings store, a web dashboard, and Slack and email alerting configured through settings.py or environment variables. You trade control over rule selection for a working default.

Snyk is a different proposition. It is a hosted product with a commercial model, and it covers dependency vulnerabilities as well as code patterns. nodejsscan is self-hosted and GPL-3.0 licensed, and the repository material describes source scanning rather than dependency auditing. If your main concern is a vulnerable transitive npm package, nodejsscan is not the tool being described here.

CodeQL is the other name that comes up in the related searches. It is a query language and analysis engine with its own build-and-query model, and it is not a drop-in replacement for a Node.js pattern scanner. The practical distinction is effort: nodejsscan is two Docker commands to a running dashboard, while a CodeQL setup requires you to define the database creation and the queries you want to run. That convenience is also the limitation, since you inherit whatever rules the pinned njsscan version carries.

Licence, upgrade cost and what to verify first

nodejsscan is licensed under GPL-3.0, and the repository carries a LICENSE file at the top level. The practical consequence of a copyleft licence is that if you distribute a modified version, the GPL obligations attach to that distribution. Running it internally as a service is a different situation from shipping it inside a product. This is not legal advice, and the specifics depend on how you deploy it, so the licence text is the thing to read rather than a summary.

Upgrade cost is mostly a dependency problem. requirements.txt pins gunicorn==21.2.0 (listed twice), flask==2.3.3, jinja2==3.1.2 (also twice), psycopg2-binary==2.9.7, GitPython==3.1.35, Flask-SQLAlchemy==3.0.5 and njsscan==1.0.1. Those pins are what the image builds against. Moving the njsscan pin forward is how you would pick up newer detection rules, and it is also the change most likely to alter your finding count between runs. The README does not document a migration path or a rollback procedure for a rule-set change, so a diff of results before and after is the only way to know what moved.

The database is the other upgrade surface. Postgres is configured through SQLALCHEMY_DATABASE_URI, the Dockerfile provisions POSTGRES_USER, POSTGRES_PASSWORD and POSTGRES_DB as root, root and nodejsscan, and manage.py recreate-db creates the schema. That recreate command is described as a one-time step, and the README does not say whether it preserves existing findings. Treat any schema change as something to test against a copy of your database first.

Editorial conclusion

Adopt nodejsscan if you want a self-hosted Node.js SAST pass that runs through Semgrep and libsast and reports into Slack or email without sending source to a vendor. Skip it if you need Windows support, a maintained release cadence, or a scanner that covers languages beyond JavaScript. Before rolling it out, run the CLI against one repository and read the findings, then check whether the pinned njsscan==1.0.1 in requirements.txt still matches the rule set you expect.

Frequently asked questions

Official sources

1. ajinabraham/nodejsscan on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases