Is Fission-AI/OpenSpec safe?
https://github.com/Fission-AI/OpenSpec/
Fission-AI/OpenSpec is a legitimate open-source AI agent workflow management CLI tool (spec-driven development planning). The SKILL.md content is benign with strong operational boundaries (all tools restricted to Bash(openspec:*)). Sensitive file access events during monitoring appear attributable to SSH/PAM system processes rather than the skill, and canary integrity checks confirm no exfiltration. Primary concerns are an unaudited npm postinstall script that executes during npm installation, a dynamic context-injection mechanism that could be abused by a malicious openspec/config.yaml in a target project, and a historical prompt injection vulnerability (now fixed) documented in the project's own security audit.
Category Scores
Findings (6)
MEDIUM Unknown postinstall script executes during npm install -20 ▶
package.json declares scripts/postinstall.js as the postinstall lifecycle hook, meaning it runs automatically during npm install. The content of this script was not examined in this audit. While the package is open source and the script name suggests benign setup work, unknown postinstall scripts are a supply chain attack vector. This risk applies only to npm-based installation, not git clone.
MEDIUM Canary credential files accessed during monitoring window -15 ▶
Inotify filesystem events captured OPEN and ACCESS events against .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and .config/gcloud/application_default_credentials.json at 13:24:53. These are the honeypot files. However, auditd process-level monitoring reports no sensitive file accesses from tracked processes, canary integrity check passes, and the access timestamps precisely match concurrent SSH/PAM authentication events (pam.d, nsswitch, login.defs reads). Attribution to the skill is unlikely but not definitively excluded.
LOW Dynamic runtime context injected into agent prompts from CLI output -10 ▶
Multiple skills (openspec-apply-change, openspec-archive-change, openspec-bulk-archive-change) call openspec instructions --json and use the returned context and operationGuidance fields as prompt-level inputs. A malicious openspec/config.yaml in a target project could inject adversarial instructions through these fields. Guardrails require conflict reporting and preservation of controlling values, but the attack surface exists.
LOW Historical prompt injection via store content (fixed) -7 ▶
The project's own internal security audit (gauntlet.md) documented finding G8: hostile remote strings, store spec IDs, and Purpose summaries rendered verbatim into instruction output, allowing newlines/control characters from a hostile clone to forge instruction lines. This was confirmed and fixed in commit 37ad867. The fix is live but the historical vulnerability demonstrates this attack class was not initially prevented.
INFO Codebase scanning during spec conflict resolution exposes source code -5 ▶
The openspec-bulk-archive-change skill searches the codebase for implementation evidence when resolving conflicts between parallel changes. This is intentional behavior but means the skill reads arbitrary source files (src/, test/) looking for function implementations, file paths, and code patterns.
INFO Restricted tool surface via Bash(openspec:*) allowlist 0 ▶
All skills declare allowed-tools: Bash(openspec:*), restricting agent tool use exclusively to OpenSpec CLI subcommands. This prevents the skill from executing arbitrary shell commands, reading files directly, or making network connections outside the openspec CLI abstraction layer. This is a significant positive security control.