Audit

[Noobru]

Hello there,

I asked my buddy GPT Sol to run an audit based on my directives and libraries I have saved on my vault. Uploaded the whole thing to a container, ran tests and checked for vulnerabilities.

The attached md is what came out of 3 hours of tests.

I hope that might help.

2026-07-10 - Complete Security Audit - Vibe-Trading.md

[warren618]

Hi @Noobru,

Thank you for this — genuinely one of the most rigorous audits this repo has received. I went through it against current main (a few commits ahead of your audited d456025, nothing security-relevant changed in between) and independently verified the file:line evidence for VT-001, VT-003, VT-004, VT-005, VT-006, VT-008, VT-009, and VT-010 — they all hold exactly as described. I haven't re-run Trivy/Semgrep/ZAP myself, so I'm taking the VT-002/VT-006/VT-009 scanner counts at face value, but the root causes you point to (build-essential in the runtime stage, no CSP middleware, unpinned ranges with no lockfile) are all real.

Item by item:

VT-001 (Critical) — correct call, and it's a step beyond where we left it. #332 flagged the same trust boundary on 2026-07-02; we rated it Low at the time and shipped env-allowlisting + a SECURITY.md disclosure (#374), narrowing what the subprocess's own env contains, but never touching process/namespace isolation. Your PoC is what moves this from theoretical to confirmed: reading secrets back out of /proc/1/environ sidesteps env-narrowing entirely, since that's a UID/namespace property, not an env-var property — and SECURITY.md already (accurately) discloses "the backtest subprocess is still network-capable" as an accepted-risk statement rather than a solved one. Real isolation (separate UID at minimum, ideally PID namespace + no-network-by-default + no home/secret mounts for the runner) is going into active work, tracked in a new issue that references this discussion and #332/#374 as prior art. I won't promise a ship date I can't back up, but this is P0 on our side too, not backlog.

VT-003, VT-004, VT-005, VT-006, VT-008 — all confirmed, all small enough to fix directly: bearer out of query strings/localStorage onto a scoped mechanism, 0600 + atomic write for the env file, auth + rate limiting on /correlation, CSP/security headers, and splitting /health into liveness vs. readiness. No disagreement on any of these; filing as tracked issues and working through in severity order — nothing gets quietly parked as "low, later."

VT-002 / VT-009 — agreed on both. Multi-stage Dockerfile (drop build-essential from the runtime stage) and a hashed Python lockfile + digest-pinned base images/actions are real gaps; scheduling as infra work.

VT-007, VT-010 — VT-010's own docstring already discloses the pickle-cache limitation as "not a defense against local write access," which matches your read exactly. Folding VT-007's container hardening into the VT-001 sandboxing work since they're the same blast-radius problem.

Opening tracking issues for VT-001–VT-010 and linking back here. If you'd like credit in the release notes once these land, let me know how you'd like to be named (or if you'd rather stay anonymous). Really appreciate the depth — the trust-boundary diagram and the P0/P1/P2 split make this immediately actionable.

[warren618]

Tracking issue is up: #476 (checklist for VT-001–VT-010, grouped P0/P1/P2). Will check items off as PRs land against it.

[warren618]

Thanks for running this and sharing it — real Docker deployment + PoC-based audits are exactly the kind of feedback that's hard to get otherwise.

Filed as #476 to track all 10 findings in one place; all of them are now addressed on main (commit a68c685). One thing worth flagging directly to you since you did the original testing: VT-001's defense-in-depth UID-drop layer turned out not to actually work in the hardened container (Docker doesn't grant ambient capabilities to a non-root process via cap_add alone) — the fix that's actually shipped and doing the work is AST-level sandboxing of the generated backtest code (blocks network/subprocess/eval/os.environ/unsafe-open, including inside function bodies, not just top-level). Full details in #476.

If you (or GPT Sol) get a chance to re-run the suite against current main, I'd genuinely like to know what it finds.