28.4.3 Code review process

2025.10.06.
AI Security Blog

A structured code review process is the primary defense mechanism for a healthy open-source project. It is not merely a bug hunt; it is a collaborative security audit, a quality assurance gate, and a knowledge-sharing forum. For AI systems, where vulnerabilities can be subtle and impactful, this process is non-negotiable. It transforms individual contributions into a resilient, community-vetted asset.

The Review Workflow: From Pull Request to Merge

A predictable and transparent workflow ensures that every contribution receives the same level of scrutiny. It removes ambiguity for both contributors and maintainers and establishes a clear path for code to enter the main branch. The process should be automated where possible to free up human reviewers for the critical thinking that machines cannot perform.

Kapcsolati űrlap - EN

Do you have a question about AI Security? Reach out to us here:

1. Contributor Submits PR 2. Automated Checks (CI/CD) 3. Manual Review (2+ Reviewers) 4. Approved & Merged Feedback & Iteration
  1. Submission: The contributor opens a Pull Request (PR). The PR description must adhere to the project’s template, clearly stating the purpose of the change and linking to a relevant issue.
  2. Automation Gateway: Continuous Integration (CI) pipelines trigger automatically. This is a first-pass filter. The PR is blocked from manual review if any of these checks fail:
    • Linting & Formatting: Enforces code style consistency.
    • Unit & Integration Tests: Verifies that existing functionality is not broken.
    • Static Analysis (SAST): Scans for common security anti-patterns.
    • Dependency Audit: Checks for known vulnerabilities in dependencies.
  3. Human Review: Once automated checks pass, the PR enters the manual review queue. A minimum of two reviewers is ideal—one to validate the logic and functionality, and another to focus specifically on security and architectural implications.
  4. Iteration: Reviewers provide constructive feedback via comments. The contributor addresses the feedback by pushing new commits to the PR branch. This cycle continues until all concerns are resolved.
  5. Approval & Merge: After receiving the required number of approvals, a project maintainer performs the final merge into the main branch.

The Reviewer’s Security Checklist

Reviewers should approach every PR with a security mindset. While not exhaustive, this checklist provides a solid framework for evaluating the security posture of a contribution, especially in an AI context.

Category Key Checkpoints Rationale
Input & Data Validation
  • Are all external inputs (files, API requests, user data) sanitized?
  • Is there robust validation on data types, ranges, and formats?
  • Is the preprocessing logic resilient to unexpected or malicious data?
The primary vector for many AI attacks, including adversarial examples and data poisoning, is through manipulated inputs.
Model Handling
  • Is the code using insecure deserialization libraries like `pickle`?
  • Are model files loaded from trusted, verified sources?
  • Does the change introduce potential for model theft or unauthorized access?
Model files can contain arbitrary code execution payloads if handled improperly. Promoting safer formats like `safetensors` is crucial.
Dependency Management
  • Does the PR add new third-party dependencies?
  • Have these dependencies been vetted for security and maintenance health?
  • Are versions pinned to prevent unexpected updates?
The supply chain is a significant risk. A malicious or vulnerable dependency compromises the entire project.
Error Handling & Logging
  • Are exceptions handled gracefully, without leaking sensitive information?
  • Is logging sufficient for forensics but free of private data (PII, keys)?
  • Can an attacker trigger verbose error messages to fingerprint the system?
Improper error handling can reveal internal system state, providing attackers with valuable reconnaissance information.
Resource Management
  • Could a crafted input lead to excessive CPU, GPU, or memory consumption?
  • Are there timeouts and resource limits on computationally expensive operations?
AI models can be resource-intensive. Without proper controls, they are susceptible to Denial of Service (DoS) attacks.

Case Study: The Danger of Insecure Deserialization

A common pattern in older ML projects is saving and loading models using Python’s `pickle` module. While convenient, it is notoriously insecure. A reviewer must immediately flag this pattern. A malicious actor could provide a specially crafted model file that executes arbitrary code upon being loaded.


# a malicious_model.pkl could be crafted to execute code
# This is a HIGH SEVERITY vulnerability.

import pickle
import os

# Attacker's payload within the pickled object
class MaliciousPayload:
    def __reduce__(self):
        # This command will run on the server loading the model
        return (os.system, ('rm -rf /',))

# When a victim server runs the following line:
# with open('malicious_model.pkl', 'rb') as f:
#     model = pickle.load(f) # Arbitrary code execution happens here!

# The review comment should be:
# "Please replace pickle.load with a safer alternative like safetensors.
# Pickle can lead to remote code execution and is not safe for untrusted data."
            

Your role as a reviewer is to identify such risks and guide the contributor toward safer practices. This not only secures the project but also educates the community.