PT0-002 Practice Question: A penetration tester is reviewing a Python script…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Replace subprocess with os.system()

  Why it's wrong here

  os.system() is fundamentally insecure because it relies on the system's shell to parse the command string. When user input is concatenated into that string, shell metacharacters like ;, |, or $() are interpreted by the shell, enabling command injection. Unlike subprocess with shell=True, os.system() does not even allow passing arguments as a list, so there is no safe way to separate command from arguments. It also returns only the exit code, making output capture difficult and forcing even more shell usage.

• ✗

  Use the 'shlex.quote()' function to sanitize user input before passing to subprocess

  Why it's wrong here

  shlex.quote() can reduce injection risk by escaping shell metacharacters, but it is not a complete defense. The quoting logic has had historical edge cases on different platforms, and when user input is placed in a shell command line, quoting mistakes or unusual shell behaviors can still lead to injection. More importantly, this approach still invokes the shell, meaning the attack surface remains; a single missed quote or a shell-specific expansion can compromise the command. The safest practice is to avoid shell interpretation altogether rather than trying to sanitize input for a shell.

• ✓

  Avoid using shell=True and pass the command as a list of arguments

  Why this is correct

  Passing the command as a list of arguments while omitting shell=True is the correct mitigation because subprocess then executes the executable directly via execve or similar system calls without invoking a shell. With shell=False, the shell's metacharacter interpretation is completely bypassed; characters like ;, |, and $ are passed as literal arguments to the command, not interpreted. This eliminates shell injection by design, because user-controlled values are always treated as data, never as code. This is the recommended approach per Python's official subprocess documentation for security-sensitive applications.

• ✗

  Use the 'exec()' function to run the command

  Why it's wrong here

  exec() is a Python built-in that compiles and executes a string as Python source code, not as a system command. Passing a shell command string to exec() would raise a SyntaxError unless the input happens to be valid Python, and if user input is interpreted as Python code, it introduces arbitrary code execution vulnerabilities of a different and equally dangerous kind. exec() does not provide any sandboxing or command isolation; it is intended for running dynamic Python code, not for secure subprocess management. Thus, using exec() is neither a valid replacement for subprocess nor a safe way to invoke OS commands.