2. Python安全自动化环境构建

安全自动化脚本往往要同时处理网络请求、加密解密、二进制解析、第三方 API 调用等任务，依赖数量多、版本敏感度高。如果直接使用系统 Python，很容易出现“昨天还能跑的扫描脚本，今天因为某个库升级就报错”的情况。因此，环境构建不是可有可无的准备工作，而是安全自动化工程的第一道稳定性保障。

虚拟环境：把每个项目隔离在独立沙箱里

虚拟环境的核心作用是隔离解释器与第三方包。系统 Python 的 site-packages 是全局共享的，而虚拟环境会为项目创建独立的目录，其中包含指向基础解释器的副本以及专属的包安装路径。这样，A 项目用 requests==2.28.0，B 项目用 requests==2.31.0，两者互不干扰。

推荐使用 Python 内置的 venv，无需额外安装工具：

# 在项目根目录创建虚拟环境
python -m venv .venv

# Linux / macOS 激活
source .venv/bin/activate

# Windows PowerShell 激活
.venv\Scripts\Activate.ps1

# 确认当前解释器路径
python -c "import sys; print(sys.executable)"

激活后，命令行提示符前通常会出现 (.venv) 标记。此时执行 pip install，包只会装进 .venv 目录。判断是否激活成功，最可靠的方式是查看 sys.executable 是否指向项目内的 .venv，而不是依赖提示符外观。

依赖管理：从“能装”到“可复现”

安全脚本常依赖 requests、cryptography、scapy、python-nmap 等库，其中 cryptography 还包含编译型扩展，对版本和系统库敏感。仅写 requests 而不锁版本，等于把复现性交给运气。

基础做法是维护 requirements.txt，并区分直接依赖与锁定版本：

# requirements.in —— 只写直接依赖，便于人工维护
requests>=2.31,<3.0
cryptography>=42.0
python-nmap==0.7.1

# 生成锁定文件（需先安装 pip-tools）
pip install pip-tools
pip-compile requirements.in -o requirements.txt

# 在目标环境精确安装
pip install -r requirements.txt

pip-compile 会把所有间接依赖也固定到具体版本，并写入哈希校验，使不同机器上的安装结果一致。若项目规模更大，可迁移到 pyproject.toml + poetry 或 uv，但核心思想不变：直接依赖人工声明，完整依赖树自动锁定。

安装完成后，用一条命令验证关键库是否可用，比逐个 import 更高效：

python -c "import requests, cryptography, nmap; print('deps ok')"

IDE 配置：让解释器、检查器与格式化器对齐

以 VS Code 为例，环境构建需要完成三件事：选择正确的解释器、启用静态检查、统一格式化。在项目根目录创建 .vscode/settings.json：

{
  "python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python",
  "python.analysis.typeCheckingMode": "basic",
  "editor.formatOnSave": true,
  "python.formatting.provider": "none",
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff"
  }
}

其中 defaultInterpreterPath 必须指向虚拟环境内的解释器，否则 IDE 的补全和调试会使用全局包，出现“命令行能跑、IDE 报找不到模块”的典型问题。静态检查推荐 ruff，它同时覆盖 lint 与格式化，启动快，适合安全脚本这种频繁修改的场景。

调试工具：从 print 到可断点、可观测

安全脚本经常需要观察请求头、响应体、加密中间值。与其到处插入 print，不如使用标准调试器。Python 3.7+ 内置 breakpoint()，在需要暂停的位置调用即可进入 pdb：

import requests

def fetch(url):
    headers = {"User-Agent": "sec-automation/1.0"}
    breakpoint()          # 在此暂停，检查 url 与 headers
    resp = requests.get(url, headers=headers, timeout=5)
    return resp

if __name__ == "__main__":
    r = fetch("https://example.com")
    print(r.status_code)

进入 pdb 后，常用命令包括 n（下一行）、s（步入函数）、p 变量名（打印值）、c（继续）。在 VS Code 中，还可以配置 launch.json 实现图形化断点、变量监视和条件断点，适合跟踪循环中的异常响应。

对于需要长期运行或批量执行的安全任务，日志比断点更合适。用 logging 替代 print，可以按级别过滤、输出到文件，并保留时间戳：

import logging

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(name)s %(message)s",
    filename="scan.log",
)
log = logging.getLogger("scanner")
log.info("start scan target=%s", "192.168.1.10")

安全脚本项目结构

一个可维护的安全自动化项目，应把“入口、核心逻辑、配置、工具、测试”分开，避免所有代码堆在一个 scan.py 里。下面是一个可直接套用的结构示例：

sec-automation/
├── .venv/                  # 虚拟环境（不提交）
├── .vscode/
│   └── settings.json
├── src/
│   └── secauto/
│       ├── __init__.py
│       ├── cli.py          # 命令行入口
│       ├── config.py       # 读取配置与环境变量
│       ├── http_client.py  # 统一请求封装（超时、重试、UA）
│       ├── scanners/       # 各扫描模块
│       │   ├── __init__.py
│       │   └── port_scan.py
│       └── utils/
│           └── logging.py
├── tests/
│   └── test_http_client.py
├── requirements.in
├── requirements.txt
└── README.md

这种结构的关键收益是：http_client.py 集中管理超时、重试和请求头，所有扫描模块复用同一套网络行为；config.py 把目标地址、并发数、超时时间从代码中抽离，便于在不同授权环境中切换；tests/ 用 pytest 对纯函数和请求封装做单元测试，避免每次改动都靠手工跑真实目标验证。

把上述结构落地后，日常开发流程就变成：激活 .venv → 修改 requirements.in 并 pip-compile → 在 scanners/ 中新增模块 → 用 pytest 验证 http_client 行为 → 通过 cli.py 运行真实任务。环境、依赖、IDE、调试四者对齐后，安全脚本才具备可复现、可协作、可长期维护的基础。