Use this checklist to carry out a risk assessment before adopting any security application developed in Python. It is designed to help identify potential weaknesses, evaluate code quality, and ensure the project meets minimal essential security standards. Applying this checklist consistently will support informed decision-making and reduce the risk of introducing security weaknesses into your environment.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
A security project MUST meet the highest security quality standards. No tool is perfect, and the way a design is converted into a program is always subjective. There is no single “best” way to create and implement a design; there are always multiple options. However, there are fundamentally wrong ways to develop software that cause weaknesses and lead to vulnerabilities. This MUST be avoided in security-critical software. A security program that is relied upon MUST be inherently secure and MUST NOT introduce vulnerabilities.
There are few specific evaluation criteria that can be directly applied to evaluate Python security applications. Transparency, comprehensive documentation, and the practice of proven security-by-design principles MUST be considered a bare minimum.
While security projects vary, the documentation MUST clearly state when a requirement is not applicable. This prevents ambiguity during security reviews and ensures users that even trivial security aspects have been addressed. To evaluate or create Python security applications, the following minimal security requirements MUST be met:
Security Policy
A security project MUST have a security policy, such as a SECURITY.md file, to ensure that potential security issues can be reported securely and effectively.
OpenSSF Best Practices
A security project MUST maintain an OpenSSF Best Practices badge to demonstrate that all fundamental security requirements have been satisfied.
3. Fuzzing
A fuzzer SHOULD be incorporated into the testing workflow where appropriate to identify unexpected behaviours or vulnerabilities.
Architecture and Design
A formal architecture or design document MUST exist, outlining key principles and documenting the design decisions that guided the implementation. It is RECOMMENDED that a “Security by Design” approach is followed to ensure security principles are integrated into every stage of the SDLC cycle.
A common practice is to maintain an ARCHITECTURE.md file within the repository.
This document SHOULD be released under a Creative Commons licence (or equivalent) and MUST be available without limitation to allow for public review and improvement.
Dependency Validation
All dependencies SHOULD be validated against known security vulnerabilities.
Dependency Versioning
The project.toml file MUST use exact version identifiers (e.g., ==1.2.3 rather than >1.2). This is a critical measure to prevent typosquatting and other supply-chain weaknesses. While PEP 508 allows logical operators, for the purpose of this security standard, pinning to a specific version is required. Advantage is also that the Python part of the package is bit-for-bit reproducible.
Reproducible Builds
A package SHOULD be published using Reproducible Builds. It is preferred to use a build tool for PyPI distribution that supports reproducible builds by default.
Principle of Least Privilege
The program SHOULD require minimal privileges to execute. Administrative or high-privilege accounts MUST NOT be used if they could compromise the system. If specific authorizations are required, a separate service account MUST be created to facilitate clear security logging. The system documentation MUST clearly outline all required authorizations.
Defence in Depth
The Defence in Depth principle MUST be practised across design, implementation, and testing. For instance, multiple SAST tools SHOULD be used for code validation to ensure comprehensive coverage.
SAST Scanning
All Python source code MUST be validated using a trusted open-source SAST scanner, such as Python Code Audit. Where weaknesses are mitigated but still trigger a notification, they MUST be marked within the code with a clarifying comment.