Integrate Semgrep for static analysis (SAST)

[connorcarpenter15]

Summary

This PR integrates Semgrep into the project on a dedicated testing branch named for the tool and documents installation, run artifacts, and an assessment of the tool.

---

1. Evidence of successful installation (trackable file changes)

The following files were added or modified to install and configure Semgrep:

Change	File	Purpose
Added	requirements-semgrep.txt	Python dependency list for Semgrep; install with pip install -r requirements-semgrep.txt.
Added	.semgrepignore	Ignore patterns (e.g. node_modules/, vendor/, build/, public/language/, *.min.js) so the scan focuses on project code.
Modified	package.json	New NPM script: "semgrep": "semgrep scan --config auto" so the tool can be run via npm run semgrep after Semgrep is installed (Python/pip).

Note: Semgrep is distributed as a Python package, not an NPM package. No new NPM packages were added; the script assumes semgrep is on PATH after installing from requirements-semgrep.txt.

---

2. Artifacts demonstrating successful run

The following artifacts show that Semgrep was run successfully on this repository:

• semgrep-output.txt — Full human-readable report (1,868 lines) from semgrep scan --config auto, including all findings with file paths, line numbers, rule IDs, and messages.
• semgrep-output.json — Machine-readable JSON output of the same run (e.g. for CI or tooling).

Summary from the run:

• Findings: 188 (all blocking under the default config)
• Rules run: 305 (from community “auto” config)
• Targets scanned: 1,549 files (tracked by git)
• Skipped: 4,197 files matching .semgrepignore (e.g. node_modules/, public/language/)

---

3. Assessment: pros, cons, and customization

3.1 Customization

A priori (before use):

• Installation: One-time install via pip install -r requirements-semgrep.txt. No NPM packages; the only project change is the semgrep script in package.json and the config/ignore files above.
• Config: We use --config auto, which pulls the community rule set. No custom rules were written for this test.
• Scope: .semgrepignore was added to exclude node_modules/, vendor/, build/, public/language/, coverage/, .nyc_output/, and *.min.js, reducing noise and scan time.

Over time:

• Tuning: Rules can be disabled or customized in a local config (e.g. .semgrep.yml) or by choosing a subset of rule IDs. Severity and blocking behavior can be adjusted.
• CI: The same command can be run in CI; exit code is non-zero when there are blocking findings, so the pipeline can fail on new issues.
• Custom rules: Semgrep supports custom rules (e.g. for project-specific patterns); we did not add any for this evaluation.

3.2 Strengths (with evidence)

• Multi-language and broad coverage: The run applied 305 rules across JS, YAML, JSON, Dockerfile, bash, HTML, etc. (e.g. 864 JS files, 309 YAML). One tool covers many surfaces.
• Actionable, linked guidance: Each finding includes a short message and a “Details” link (e.g. https://sg.run/...) to documentation and remediation.
• Structured output: JSON output includes CWE/OWASP metadata, severity, and line/column ranges, which supports automation and reporting.
• Low integration cost: No new NPM deps; a single script and an ignore file are enough to run it locally or in CI.
• Useful infra/security checks: It flagged real configuration issues (e.g. Docker Compose services without no-new-privileges or with writable root filesystem) and common app-security patterns (e.g. path traversal, regex injection, prototype pollution, session/cookie settings).

Quantitative:

• 188 findings in one run; many are in a small set of files (e.g. path-traversal and regex rules account for a large share), which helps prioritize.
• Severity mix in this run: 174 WARNING, 12 ERROR, 2 INFO (from JSON summary).
• Top rule by count: path-join-resolve-traversal (113); others include detect-non-literal-regexp (17), express-path-join-resolve-traversal (8), prototype-pollution-loop (7).

3.3 Weaknesses (with evidence)

• False positives and noise: Several rules are conservative. For example, many path.join/path.resolve usages are flagged as possible path traversal even when inputs are constrained (e.g. internal config or fixed segments). Tuning or disabling rules per file/pattern will be needed for a clean baseline.
• No NPM integration: Semgrep is Python-based, so teams that only use Node/npm must install Python and run pip install -r requirements-semgrep.txt. There is no npm install-only story.
• Blocking-by-default: With --config auto, 188 blocking findings may be too strict for an initial rollout; teams may want to start with a smaller rule set or non-blocking severity and then tighten over time.
• Limited project-specific context: Rules are generic (e.g. “ensure CSRF middleware”); they don’t know this app’s actual CSRF setup. Some findings (e.g. in install/web.js) may not apply to production code paths.

Quantitative:

• 113 of 188 findings are from a single rule family (path-join-resolve-traversal), which can dominate the report and require bulk review or rule customization.
• 4,197 files were skipped via .semgrepignore; without that, the run would be slower and noisier.

3.4 Conclusion

Semgrep is a strong fit for broad, multi-language static analysis with minimal setup. For this repo, it quickly surfaced infrastructure and application-security issues and produced both human- and machine-readable artifacts. The main follow-up work is to reduce noise (e.g. by adjusting or disabling rules and refining .semgrepignore) and to integrate the command into CI with a policy for which findings are blocking.