Hardening: Avoid shell-based popen usage in InspectFile operator

[praneet390]

This PR proposes a security hardening improvement to the InspectFile operator external command execution path.

Currently, InspectFile::evaluate constructs a command string and invokes it using popen(), which executes via the system shell.

While current usage paths (e.g., FILES_TMPNAMES) pass engine-generated sanitized filenames and are not attacker-controlled, invoking a shell with concatenated arguments is a fragile pattern and increases risk if future variable sources expand.

This PR starts discussion toward replacing shell-based execution with argument-safe process execution (execve/spawn with explicit argv array), removing shell interpretation from the execution path.

Security benefits:

• removes shell metacharacter interpretation risk
• prevents command injection under misuse
• enforces argument boundaries
• improves defense-in-depth

This PR currently adds a security hardening note and opens discussion on the preferred cross-platform implementation approach for v2 and v3.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[praneet390]

Context: This PR comes from a security review of the @inspectFile operator execution path.

While current data flow does not allow command injection due to engine-controlled inputs (e.g., FILES_TMPNAMES via mkstemp), the popen + concatenated string pattern is shell-based and fragile by design.

Opening this draft PR to discuss a possible migration toward argv-based exec/spawn for defense-in-depth and safer future semantics across v2 and v3.

Happy to implement the change following maintainer guidance on preferred cross-platform approach.