Mengapa
Ditemukan sesi audit sebelumnya (issue di docs/agent-usage-guide.md "Known limitations"): security --check taint cuma cover Python/JS/TS/TSX — zero taint coverage untuk Rust, padahal pada workspace nyata (Tauri app) ada Command::new(...) sink di .rs yang di-feed dari std::env::var(). Ini genuine gap keamanan untuk kelas aplikasi Tauri yang makin umum.
Ini juga contoh konkret ide "dream tool": taint analysis yang berhenti di batas bahasa (grep/tool lain juga begitu) tidak bisa lihat bahwa data dari frontend TS masuk ke backend Rust via IPC — padahal itu jalur yang justru paling sering jadi celah nyata di app Tauri/Electron.
Konteks
ast_taint_engine.get_supported_languages() return ["python", "javascript", "typescript", "tsx"] — Rust genuinely tidak ada rule set taint sama sekali (bukan bug, cuma belum dibangun).
Membangun taint analysis penuh untuk Rust (source/sink rules + AST walker) adalah proyek multi-hari. Issue ini SENGAJA di-scope kecil: MVP satu pola spesifik dulu (Tauri IPC boundary), bukan taint Rust general-purpose.
Tujuan
MVP: deteksi taint path yang melintasi IPC boundary — invoke("command_name", {...}) di sisi TS/JS (source: argumen ke invoke) menuju fungsi #[tauri::command] fn command_name(...) di sisi Rust (kalau parameter itu lalu mengalir ke sink berbahaya seperti Command::new(), path traversal, atau SQL string concat di function body yang sama).
Constraint
- JANGAN coba bangun taint Rust general-purpose di issue ini — itu scope terpisah, butuh design doc sendiri kalau mau dilanjutkan.
- Reuse
ast_taint_engine.py's existing source/sink rule format kalau strukturnya cocok — jangan bikin engine kedua yang terpisah tanpa alasan kuat.
- Wajib design doc di
docs/design/ (feature-class, engine baru) sebelum PR — sesuai convention repo.
Definition of Done
Mengapa
Ditemukan sesi audit sebelumnya (issue di docs/agent-usage-guide.md "Known limitations"):
security --check taintcuma cover Python/JS/TS/TSX — zero taint coverage untuk Rust, padahal pada workspace nyata (Tauri app) adaCommand::new(...)sink di.rsyang di-feed daristd::env::var(). Ini genuine gap keamanan untuk kelas aplikasi Tauri yang makin umum.Ini juga contoh konkret ide "dream tool": taint analysis yang berhenti di batas bahasa (grep/tool lain juga begitu) tidak bisa lihat bahwa data dari frontend TS masuk ke backend Rust via IPC — padahal itu jalur yang justru paling sering jadi celah nyata di app Tauri/Electron.
Konteks
ast_taint_engine.get_supported_languages()return["python", "javascript", "typescript", "tsx"]— Rust genuinely tidak ada rule set taint sama sekali (bukan bug, cuma belum dibangun).Membangun taint analysis penuh untuk Rust (source/sink rules + AST walker) adalah proyek multi-hari. Issue ini SENGAJA di-scope kecil: MVP satu pola spesifik dulu (Tauri IPC boundary), bukan taint Rust general-purpose.
Tujuan
MVP: deteksi taint path yang melintasi IPC boundary —
invoke("command_name", {...})di sisi TS/JS (source: argumen ke invoke) menuju fungsi#[tauri::command] fn command_name(...)di sisi Rust (kalau parameter itu lalu mengalir ke sink berbahaya sepertiCommand::new(), path traversal, atau SQL string concat di function body yang sama).Constraint
ast_taint_engine.py's existing source/sink rule format kalau strukturnya cocok — jangan bikin engine kedua yang terpisah tanpa alasan kuat.docs/design/(feature-class, engine baru) sebelum PR — sesuai convention repo.Definition of Done
docs/design/NNNN-tauri-ipc-taint.mdsecurity --check taintmendeteksi minimal 1 pola nyata:invoke("cmd", {path: userInput})di TS →#[tauri::command] fn cmd(path: String)yang lalu dipakai distd::fs::atauCommand::new()tanpa sanitasismart-tax-assistancesudah punya pola IPC + Command::new sink yang cocok untuk test case ini)