Python's popularity, ease of use, and widespread adoption make it an attractive target for malicious actors. It is commonly pre-installed or readily available on developer workstations, servers, and cloud environments, giving attackers an easily accessible tool for misuse.

Python itself does not implement **privilege separation** within the interpreter to limit the attack surface when executing code. Once an attacker gains the ability to run arbitrary Python code, they inherit the full privileges of the process running the interpreter — typically those of the user account executing the program. This often grants broad access to the filesystem, network, environment variables, and other system resources.

While true privilege separation cannot be reliably enforced *inside* Python (due to the large attack surface of the interpreter), it can be applied externally by running Python code within a sandboxed environment (e.g., using containers, seccomp filters, virtual machines, or tools like GraalVM isolates). However, no sandbox is 100% secure — escapes and bypasses remain possible, as demonstrated in various real-world vulnerabilities.

Vulnerabilities in Python programs are commonly exposed through:

- **Untrusted or malicious input**

Attackers can supply malicious data via APIs, corrupted files, or insufficiently sanitised user input. Examples include malformed XML/JSON/YAML triggering parser bugs, poisoned data files, or insecure REST endpoints lacking proper validation and security controls.

- **Insecure third-party modules**

Dependencies from PyPI or other sources may contain vulnerabilities, supply-chain compromises, or malicious code.

A particularly significant risk is Python's ability to **execute arbitrary code provided as data**. This capability underpins many injection and remote code execution (RCE) attacks, such as unsafe deserialisation (e.g., via the `pickle` module), `eval()`/`exec()` misuse, or dynamic code loading from untrusted sources.

Beyond general environmental risks during execution, certain threat vectors are inherent to Python applications and often stem from gaps in the **Software Development Life Cycle (SDLC)**:

- **Lack of security auditing**

Many Python codebases receive little or no internal security auditing, static/dynamic analysis, or architectural/design reviews tailored to the target environment. As a result, vulnerabilities can persist undetected from development through to production for years.

- **Insufficient security awareness**

A significant number of Python developers lack formal training in secure coding practices. This leads to the introduction of common weaknesses. Modern AI-assisted coding tools can exacerbate the issue by generating code riddled with security flaws that readily become exploitable vulnerabilities.

- **Unreviewed code**

Substantial portions of Python code — across development, staging, and production — undergo no security-focused peer review. Static Application Security Testing (SAST) is rarely performed comprehensively; when it is, coverage is often limited to only a minimal set of issues.

- **Over-privileged accounts and processes**

Developers, testers, CI/CD pipelines, and automated processes frequently operate with excessively broad permissions. Upon compromise, attackers can exploit these elevated privileges for lateral movement, data exfiltration, persistence, or full system takeover.

The combination of Python's powerful dynamic execution features and longstanding systemic weaknesses in development practices — such as minimal code review, inadequate dependency management, and reliance on over-privileged accounts — creates a particularly fertile environment for compromise.


:::{tip}

Many Python code weaknesses are detected in the #1 **Open Source** Python SAST tool, [**Python Code Audit**](https://nocomplexity.com/codeaudit/)

:::

You cannot understand specific Python security vulnerabilities without better understanding how Python runs. This section should cover the bytecode compilation, the PVM (Python Virtual Machine), and how Python handles memory and dynamic typing.

To understand which security threats are relevant to Python code, knowledge of the internal workings of the Python interpreter is required.

:::{note}

Understanding how Python source files (`*.py`) are executed is crucial from a security point of view.

:::

The default and most widely used interpreter is CPython, distributed by the Python Software Foundation (PSF). The core CPython source code cannot be easily compromised; multiple defensive measures are taken to prevent weaknesses in the code and to protect against supply chain attacks. While trust is essential, verification is better: the open-source nature of Python allows anyone to inspect the code or validate the PSF’s processes if required.

Most secure Unix distributions and all BSD systems require that CPython is built from source. Some distributions use reproducible builds to minimise the risk of supply chain attacks on the CPython code.

While Python is an interpreted language, it involves a compilation step where source code is converted into bytecode (`.pyc`). This bytecode is then executed by the Python Virtual Machine (PVM).


Detailed Execution Steps:

1. **Source Code**: Python code is a file with a `.py` extension.

+++

2. **Compilation to Bytecode**: When the program is run, the Python Compiler first translates the source code into an intermediate format called bytecode. During this phase, it also checks for syntax errors. This bytecode is a set of instructions tailored for the Python Virtual Machine. This bytecode is a platform-independent representation that is not specific to any operating system or hardware. The compiled bytecode is then stored in a .pyc file. For faster loading in future runs, the bytecode is saved as a `.pyc` file in a `__pycache__` directory. If a script is run directly, e.g. python `myscript.py`, Python compiles it to bytecode in memory only. After execution no bytecode is saved. So `.pyc` files are only created when a file is imported and when chasing is enabled (which is by default).

+++

3. **Execution by the Python Virtual Machine (PVM)**: The bytecode is then passed to the Python Virtual Machine (PVM), which acts as an interpreter. The PVM reads the bytecode instructions and translates them into machine-specific (binary) code that the computer's CPU can understand and execute.

+++

4. **Execution and Output**: The computer's CPU executes the machine code instructions, interacts with the hardware (memory, I/O devices, etc.), and produces the final results or output of the program.

This flow ensures that Python is platform-independent at the bytecode level, as any system with a compatible PVM can run the same bytecode.

CPython is the reference implementation written in C. CPython functions as both a compiler and an interpreter. It first compiles Python source code into an intermediate format called bytecode, which is then executed by the Python Virtual Machine (PVM), a runtime environment written in C.

Python Code goes through parsing, complication and execution. Bytecode is the intermediate representation.

CPython is a stack based virtual machine. This means that it executes instructions using a **Last-In, First-Out (LIFO) stack data structure** to store and retrieve data, rather than using general-purpose registers.

Inside the CPython VM, each function call has an associated "frame," which contains a specific "evaluation stack" (or "value stack"). This is where most of the work happens.

The Python Virtual Machine (PVM), which is part of the **CPython interpreter**, is written in the **C programming language** and uses the standard **C API** and **C runtime library** to make calls to the operating system. So instead of talking to the OS directly from Python code (which would not be platform-independent), the PVM includes an implementation layer (written in C) that uses the underlying OS's own Application Programming Interface (API) to perform tasks using the Operating System.

So Python's execution model combines interpretation with compilation. The Bytecode is an intermediate representation between the high-level Python source code and machine code.

Bytecode is the intermediate representation that the PVM executes. The bytecode is more efficient to run compared to interpreting the source code directly.

Below is an example how you can see how Python code is compiled to bytecode:


This chapter provides a comprehensive exploration of the security mechanics inherent in Python development. We begin by deconstructing the Python Execution Model, establishing how the underlying runtime influences the safety of your code. Building on this technical foundation, we define a formal Python Threat Model to identify trust boundaries and protect vital assets.

The focus then shifts outward to the Python Attack Landscape, examining the external risks posed by the modern software supply chain and third-party dependencies. By understanding this environment, we categorise specific Python Security Threats.

Python is the most widely used programming language worldwide, valued for its readable syntax and extensive ecosystem. Its accessibility makes it suitable for a broad audience, including occasional programmers, academic researchers and professional developers.

Python plays a central role in modern computing. It powers some of the world’s largest websites and web applications, serving as a key driver of advances in artificial intelligence and machine learning. Its comprehensive libraries and adaptability have established it as a standard tool across scientific research and data-intensive disciplines.

In addition to its academic and research applications, Python is deeply integrated into the operations of millions of companies and supports a vast number of software systems and applications globally. This combination of versatility, scalability, and community support underpins Python’s position as a foundational technology in contemporary computing.

In today’s digital world, cybersecurity remains a critical concern. This applies equally to using or creating Python software: preventing vulnerabilities starts with a solid architecture, but even well-written code—including AI-generated code—is not secure by default.

Validating Python code for potential vulnerabilities is therefore essential, whether you are writing your own programs or relying on code developed by others.

:::{hint}

Security is a process that must be embedded within your development flow at every stage, from design through to production, maintenance, and operations. For those using or developing Python programs, this means that security should, at a minimum, be integrated into the initial design or architecture.

:::

:::{admonition} TLDR - If you short on time

:class: important

The bare minimum to do as programmer is:

* Follow and use the [Python Secure Coding Guidelines](https://nocomplexity.com/documents/codeaudit/securecoding.html).

and:

* Practice [Security by design](https://nocomplexity.com/documents/securitybydesign/sdlc.html).

:::

:::{tip}

If you are a professional Python programmer, make sure you become familiar with basic security threats and the measures used to prevent security risks.

Read and use: [The Open Security Reference Architecture](https://nocomplexity.com/documents/securityarchitecture/introduction.html)

:::

Developing secure programs in Python requires understanding its strengths and limitations in handling security. Below are some critical insights and best practices to help you build secure Python applications.

- **Follow a Security Checklist**: Start with a comprehensive security checklist, such as this [simple security checklist](https://nocomplexity.com/documents/securityarchitecture/prevention/simple-checklists.html), to identify and mitigate potential vulnerabilities.

- **Understand Privilege Separation**:

Python, by design, does not implement internal privilege separation, which increases the attack surface. If an attacker can execute arbitrary Python code, they effectively gain full access to the system.

**Solution**: Implement privilege separation outside Python by running it within a sandboxed environment. This reduces risks by isolating the Python process from critical system resources.

- **Lack of Bytecode Safety**: CPython does not verify the safety of bytecode. If an attacker can execute arbitrary bytecode, they could import and run sensitive code. However, this should be considered a secondary concern since code execution implies significant compromise.

- **Avoid Building Sandboxes in CPython**: Creating a secure sandbox inside CPython is impractical due to the extensive attack surface. Python's rich introspection capabilities (e.g., the `inspect` module) and features that execute code on demand make it challenging to enforce strict isolation.

- A literal string like `'\N{Snowman}'` automatically imports the `unicodedata` module.

- Code designed to log warnings can potentially be abused to execute malicious code.

For robust security, do not rely on Python itself for sandboxing. Instead, encapsulate CPython in a dedicated, externally managed sandbox. This design ensures that the Python environment remains isolated, significantly reducing the risk of exploitation.