OpenSpec was rejected by my company security team because it has security vulnerabilities and lack of security focus

[ManikandanUV]

Feedback from my company security team after reviewing my request to approve use of openspec in our work.

"I ran the OpenSpec source code through trivy and opengrep with concerning results. Trivy identifies 8 high severity CVEs within the primary pnpm-lock.yaml file. More concerning, opengrep identified 226 findings. The majority of these findings are path traversal vulnerabilities, which appear systemic. Analysis of the project itself points to an immaturity of their security program: no SCA analysis, no static analysis, a lack of reported vulnerabilities or security defects"

Any plans on addressing the security concerns? I like openspec and would like to use it in my work, but this is not a good look.

[clay-good]

Hi @ManikandanUV, thank you for opening this issue.

The 8 high CVEs in pnpm-lock.yaml: every one is a devDependency used to build and test the project (vite, rollup, minimatch, js-yaml, brace-expansion). The published package ships dist/, bin/, and schemas/ with 10 runtime dependencies, and none of the flagged packages are among them.

Trivy scans the lockfile without separating dev from runtime scope. The only advisory touching shipped code is a stale yaml@2.8.2 pin (medium, patched in 2.8.3), which we're bumping.

The 226 opengrep findings: OpenSpec is a local CLI that reads and writes markdown in the repo you run it in, so joining user-supplied paths is the feature, not a vulnerability.

There's no server, no network listener, and no trust boundary to traverse. CodeQL, running on the same source, reports zero path-injection findings.

On the security program: we run GitHub Dependabot for SCA, GitHub Secret Scanning, and CodeQL for SAST. CodeQL currently shows 5 open alerts in shipped source — 2 ReDoS in src/core/references.ts and 3 prototype-pollution in src/core/config-schema.ts — and we're working through them.

I will follow up with a PR so you can confirm with your security team once it is merged.

[clay-good]

Hi @ManikandanUV

The CVEs are closed. Every advisory affecting the published package is fixed. All of it turned out to be a stale lockfile, so the fixes landed inside existing version ranges: vite 7.0.6 → 7.3.6, rollup 4.46.2 → 4.62.2, js-yaml 3.14.1/4.1.1 → 3.15.0/4.3.0, plus minimatch, brace-expansion, flatted, postcss and yaml.

We ran opengrep ourselves. 208 findings and 201 of them are one rule, path-join-resolve-traversal, firing on paths built from module constants, command-line arguments, or filenames returned by readdir. None takes untrusted input. One more, detect-non-literal-regexp, is fed by a hard-coded pattern list. That leaves three that pointed at real code, in our config helpers, and reading that code turned up a genuine prototype-pollution bug that neither scanner reported. All three are fixed.

Also added: a SECURITY.md with a private disclosure path and an explicit threat model, Dependabot updates with a release cooldown, dependency review on every pull request, a scheduled audit, and all GitHub Actions pinned to commit SHAs.

The fixes are on main but not yet in a published release. Until we cut one, your security team can check the source directly — no install or build required:

git clone https://github.com/Fission-AI/OpenSpec.git && cd OpenSpec
npx -y pnpm@9.15.9 audit --prod    # "No known vulnerabilities found"
node -p "Object.keys(require('./package.json').dependencies).join('\n')"

The second command lists the ten dependencies that actually ship. The package publishes only dist/, bin/, schemas/, and scripts/postinstall.js — none of the flagged build tooling is in there. I'll follow up here when the release goes out.