ai-for-science-proteinbert

This code is a local ML inference/debug script with no explicit malicious behavior visible (no network/subprocess/credentials). The main supply-chain risks are (1) runtime sys.path modification that can enable local-module import hijacking, and (2) loading a .pkl model dump via proteinbert.load_pretrained_model, which may involve unsafe deserialization or execution of untrusted objects depending on implementation. These uncertainties dominate the security assessment; a review of proteinbert.load_pretrained_model (and the model dump provenance/integrity) is required to confirm exploitability.

The fragment is an inference/debug script that loads a local ProteinBERT checkpoint, runs a forward pass, and prints activation statistics. It shows no direct network/process/persistence behavior. The main supply-chain risks are indirect: (1) loading/converting a `.pkl` checkpoint via `convert_tf_to_pytorch(PKL_PATH)`, which may involve unsafe deserialization if implemented with pickle-like mechanisms, and (2) `sys.path.insert(...)` altering import precedence and enabling local module shadowing. Debug printing increases information disclosure to logs but is not exfiltration. Inspect `convert_tf_to_pytorch` and related imported modules to confirm safe checkpoint handling and to assess import-shadowing exposure.

No explicit malicious behavior (no networking, subprocesses, credential theft, or clear backdoor logic) is present in this fragment. The primary security risks are supply-chain/integrity mechanisms: loading a local .pkl artifact via convert_tf_to_pytorch() (potential unsafe deserialization/code execution risk depending on implementation) and runtime sys.path manipulation that could enable import-path hijacking. If PKL_PATH and the parent directory contents are not strictly trusted and integrity-checked, this script should be reviewed/contained before use.

No direct malicious behavior (no networking, subprocesses, credential theft, or persistence) is present in this snippet; it appears to be a local NPU inference/benchmark script that computes attention statistics and writes an .npz artifact. The principal supply-chain/security risks are indirect: modifying sys.path (module shadowing/sideload risk) and loading model weights from a user-home .pkl via convert_tf_to_pytorch (potential unsafe deserialization depending on implementation). Treat the model artifact and imported modules as high-trust dependencies and verify loader safety and file provenance.

This fragment is a deployment/orchestration script without visible backdoors, exfiltration, or persistence. However, it contains two notable supply-chain/trust-boundary risks: (1) it executes arbitrary shell code by sourcing ${CANN_PATH}/set_env.sh, where CANN_PATH is user-influencable at runtime; and (2) it installs Python dependencies from a remote index without demonstrating pinning/verification. Additionally, the weight conversion step runs a local conversion script on a .pkl file with no integrity/signature checking in this fragment, which could become a deserialization/code-execution vector depending on convert_weights.py. Overall malware likelihood is low from this fragment alone, but security risk is moderate due to these trust boundaries.

This module is a model-weight conversion utility, but it uses pickle.load on a file path supplied by the caller. If pkl_path contents are not strictly trusted, that single design choice creates a critical arbitrary code execution risk at deserialization time. Aside from that, the remaining logic is standard weight remapping (with potential DoS via oversized payloads) and optional checkpoint writing to output_path.

No overt backdoor/exfiltration logic is evident in the fragment beyond standard tokenization and PyTorch inference. However, load_pretrained_model_pt performs pickle.load on data from a caller-provided path and then immediately overwrites the result via convert_tf_to_pytorch, making the unsafe deserialization both high-impact and potentially unnecessary. If an attacker can influence pkl_path or the pickle contents, this module can enable arbitrary code execution. Treat provided model artifacts as fully trusted and avoid pickle-based loading of untrusted files; prefer safer serialization formats.

This is a model-weight conversion utility with no apparent malicious payload or exfiltration behavior in the computation/mapping logic. The dominant supply-chain risk is unsafe deserialization: pickle.load is applied directly to a user-provided .pkl file, which can enable arbitrary code execution if the input is untrusted. Secondary risks include potential denial-of-service via oversized/malformed weight arrays and a reliability bug regarding the late import of os used by convert().