zai-org / zai-org/feedback

[plugin mimosa] path-traversal call-site false positives on test fixtures + PreToolUse heredoc ergonomics

Open
#657 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

priority: P2
Dominant language
No language data
Stars
22
Forks
1
PR merge metrics
No merged PRs in 30d

Description

Environment
  • Plugin: mimosa@zcode-plugins-official 1.0.3
  • Context: ZCode review gate deep scan (mimosa scan) over a Python repo with security-test fixtures; macOS
Problem 1: path-traversal rule family — call-site matching false positives on test fixtures

When new test files enter the scan's project graph, the path-traversal family reports ~10 highs on open() calls inside test fixture helpers (stubs like fake_orca / fake_ps that simulate CLI tools) plus a few stock open() sites in production sentinel scripts. Same pattern as the SSRF family (see #300): the verdict is call-site-based with no taint/flow modeling — the helper's path argument comes from the test, not from user input, but there is no way to express that. Combined with the missing suppression channel (#300 / #613 / #526), these findings re-fire on every scan and drown the signal.

Ask: same as #300 — verdict-level allowlist + sanitizer/wrapper awareness; or at minimum a scan-scope/profile knob that excludes designated fixture directories from entry-point rules.

Problem 2: hook ergonomics — writing files via heredoc in Bash is misreported as "Bash writes source code directly"

The PreToolUse hook flags git commit -F <file>, PR bodies, or any heredoc that mentions in-repo paths as "Bash directly writing source files", even when no source file is being written at all (the target is a temp file outside the repo, or the string is just a path reference in prose). False-positive ergonomics aside, the message trains users to ignore the hook.

Ask: tighten the heuristic (only fire when the redirect target is actually a repo-tracked source path), and/or record the matched pattern in the denial so users can see exactly what tripped it.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing both cases with mimosa scan: fixture-helper open() calls in the Python project graph and PreToolUse heredoc commands such as git commit -F <file>. Trace which path-traversal and Bash-write patterns produce the findings, then verify that designated fixtures and non-source heredoc targets no longer trigger false positives while genuine violations remain visible.

Written by the indexing model from the issue text.

Assessment

Tech stack
bash, python
Domain
cli, security, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.