Sample audit report: see how a Hackerbane report is structured. Open the report →

Python

Python security review

Python is a language used for bots, backends, and scripts that call contracts or run machine-learning models. Hackerbane audits the Python that holds keys, loads files, or decides when to send a transaction.

What we review

We review the scripts and services that call contracts or hold keys, not every notebook in the repo. Typical issues are pickle files that run code on load, keys left in source, and a decision that goes on-chain with no check.

  1. Pickle and checkpoint files that execute code when they are opened.

  2. Training or eval data treated as trusted because it came from an internal path.

  3. Bots that sign or send on any model score, with no limit.

  4. Scripts and notebooks that still have a production key in the source.

  5. A score or a script that changes a live parameter or sends a transaction with no check in between.

Advanced Threat Detection

We built our own advanced threat detection stack that is more performant and cheaper than our competitors. We use a state-of-the-art AI harness coupled with world-class senior security engineers with proven experience finding vulnerabilities in well-tested software.

How we review this language

A Python review follows the same five-stage engagement as every Hackerbane audit. We start from the files the job loads and the keys it can reach.

Two senior engineers read the code in parallel. We follow a loaded file or a model score through to the point where it can send a transaction or change a parameter.

  1. Scope and threat model

    We lock the repo, the commit, and what the service can reach: the artifacts it loads, the data it trusts, the keys it holds, and the chain it can call, before the review starts.

  2. Architecture and design review

    We map the pipeline from data and checkpoints to a score and then to a signed action, and mark every point where a research shortcut became the production path.

  3. Hybrid code and infrastructure review

    Two senior engineers read the Python in parallel, with the type checker and tests running, and inspect how artifacts are loaded and where secrets actually live.

  4. Exploitability and root-cause analysis

    High and Critical findings ship with a runnable proof against the service and the root cause, so the unsafe loader or key path is closed for good.

  5. Reporting and remediation

    A prioritized report, a live walkthrough, and verification of every in-scope fix within the remediation window.

Tools and practices

We work in the repository you already use. pytest stays in place. We add loader tests and proofs, then hand those back with the report.

What you get

  • Prioritized findings your engineers can ship against, each with root cause and a recommended fix.

  • Runnable proofs of concept for High and Critical issues.

  • A report you can share with partners, investors, and counterparties.

  • Remediation verification and a final report that reflects the fixed state of the system.

  • The loader and data tests used during the review.

How to prepare

What we need before the engagement starts.
#Before review starts
01The project installs and tests run cleanly from a fresh checkout.
02The codebase is stable, with no major refactors planned mid-audit.
03How the process is hosted and what it can call or sign are documented.
04Where models, data, and secrets come from is written down.
05Scope is defined: which pipeline or script, which commit, and which deployment.

Questions

Do you review the model itself?
We review what the code does with a model and its files. How the file is loaded, how the score is used, and what action it triggers are the audit.
Is a research repo too messy to review?
Often the research path is also the production path. We scope the hosted job, the files it loads, and the keys it can reach, not every notebook.
Can you review the chain code the keeper calls?
Yes. When the Python signs or sends a transaction we can review both, so the script and the contract it calls are covered together.

Next step

Request an audit

Share the repo, what the Python process can call or sign, and your timeline. We will propose an audit plan and estimate.