Running `brief threat-model` on workspace projects (Cargo workspaces, Go workspaces) returns fewer threats than expected because dependency detection only parses root-level manifests, not workspace member manifests.
Found this testing against real projects:
zizmor (Rust) — `reqwest` is in `crates/zizmor/Cargo.toml` but the root `Cargo.toml` only has `[workspace]` with no `[dependencies]`. brief detects Rust and Cargo workspaces but doesn't find reqwest, so the `rust/reqwest.toml` tool def never matches and the SSRF threat doesn't fire.
syft (Go) — similar pattern. Go workspace with nested `go.mod` files in subdirectories. Dependencies in member modules aren't found.
forgejo (Go) — pgx was detected (maybe because it's in the root go.mod?) but other deps in nested modules may be missed.
The fix would be: when a workspace is detected (Cargo workspace, Go workspace, pnpm/yarn/npm workspaces), also parse member manifests. The workspace detection already identifies the root — the member paths are in `[workspace] members = [...]}` for Cargo, `use` directives in `go.work`, and `workspaces` in `package.json`.
This affects all the new security-relevant library defs from #28 since they're detected purely via the `dependencies` primitive. A Django project in a monorepo with `pyproject.toml` in a subdirectory would have the same problem.
Running `brief threat-model` on workspace projects (Cargo workspaces, Go workspaces) returns fewer threats than expected because dependency detection only parses root-level manifests, not workspace member manifests.
Found this testing against real projects:
zizmor (Rust) — `reqwest` is in `crates/zizmor/Cargo.toml` but the root `Cargo.toml` only has `[workspace]` with no `[dependencies]`. brief detects Rust and Cargo workspaces but doesn't find reqwest, so the `rust/reqwest.toml` tool def never matches and the SSRF threat doesn't fire.
syft (Go) — similar pattern. Go workspace with nested `go.mod` files in subdirectories. Dependencies in member modules aren't found.
forgejo (Go) — pgx was detected (maybe because it's in the root go.mod?) but other deps in nested modules may be missed.
The fix would be: when a workspace is detected (Cargo workspace, Go workspace, pnpm/yarn/npm workspaces), also parse member manifests. The workspace detection already identifies the root — the member paths are in `[workspace] members = [...]}` for Cargo, `use` directives in `go.work`, and `workspaces` in `package.json`.
This affects all the new security-relevant library defs from #28 since they're detected purely via the `dependencies` primitive. A Django project in a monorepo with `pyproject.toml` in a subdirectory would have the same problem.