📚 课程目录第4章静态密码的隐患

4、静态密码的隐患：硬编码密码的危害与检测方法

你们有没有遇到过这种情况？代码库刚拉下来，随便翻翻就看到类似 password=“123456” 的语句。我反正是经常遇到。硬编码密码，说白了就是把密钥、数据库口令、API 这类敏感信息，直接写在源代码里。你觉得方便，可这简直是给攻击者留了后门。

我个人习惯，只要Review代码第一件事就是搜“password”、“secret”、“key”这些关键词。有一次，我接手一个遗留系统，发现配置文件里赫然写着生产数据库的密码，明文！那个项目居然跑了好几年没出事，只能说运气好。运气不会永远站在你这边。

  核心观点：硬编码密码是CI/CD安全中最常见、最危险的“低级错误”。它就像把家门钥匙贴在门框上。

硬编码密码到底有多危险？

你想想看，密码一旦进了代码仓库，就等于公开了。Git 历史里删都删不干净。我见过一个团队把密钥提交后，以为删掉文件就没事了，结果黑客直接翻历史记录找到了。嗯，最后他们连夜轮换了所有凭据，那场面……

具体危害我给你列一下：

危害类型	具体表现
权限滥用	别人拿到密码后，可以登录数据库、调用API、提权操作
横向扩散	一个密码被攻破，连带着整个内网其他服务都暴露
审计缺失	无法定位谁用了密码，出了问题追责困难
变更困难	密码要换一轮，必须改代码、重新部署，工作量巨大
泄露溯源	密码被扒出去，你不知道泄漏渠道，修复成本高

硬编码密码还有一个隐性成本——合规问题。很多安全标准（比如PCI-DSS、ISO 27001）直接禁止明文密码存储。审计时被查到，直接红牌。

注意：即使只写在测试代码里也不行。测试环境一旦被攻破，攻击者能凭借密码反向推断生产环境凭据。别问我为什么知道……

怎么检测硬编码密码？

检测方法其实不复杂，我按推荐程度排了个序：

肉眼扫描 + 正则搜索 – 最简单，但容易遗漏。适合小项目。
专用静态分析工具 – 比如 Bandit（Python）、SpotBugs（Java）、Trivy、TruffleHog。这些工具能智能识别密码模式。
CI/CD管道集成检测 – 在 git push 时自动扫描，阻止密码进入仓库。
Git历史扫描 – 使用 GitLeaks、GitGuardian 等扫描所有历史提交。

我曾经在 CI 管道里加了一个简单的 grep 脚本，结果每天拦截十几个假警报。后来换成 TruffleHog，准确率高了不少。但还得人工确认。

小技巧：正则搜索可以组合多个模式，比如 password\s*[:=]\s*["']、secret\s*[:=]\s*["']、api[_]?key。不要只搜“password”。

一个典型的检测流程

下面这张图展示了从提交代码到发现硬编码密码的典型流程，你能看到每个环节的职责：

这个流程里最容易被忽略的是“定期历史扫描”。很多人以为代码里现在没有密码就行，却忘了 Git 历史里还躺着旧版本。我建议每周跑一次历史扫描任务，发现问题立刻回滚并通知团队。

实战：用工具检测硬编码密码

这里我举个 Python 项目的例子。假设你的代码里有个恶意提交——

# app_config.py
DB_PASSWORD = "SuperSecret2024!"   # 危险！
 = "sk-proj-xxxxxxxxxxxxxxxx"

用 Bandit 检测很简单：

pip install bandit
bandit -r . -f html -o report.html

运行后你会看到类似报告：

>> Issue: [B105:hardcoded_password] Possible hardcoded password: 'SuperSecret2024!'
   Severity: Medium   Confidence: Medium
   Location: app_config.py:1
   More Info: https://bandit.readthedocs.io/en/latest/plugins/b105_hardcoded_password.html

Bandit 会把硬编码密码标记为 Medium 严重程度。你可以把这条规则设成 Error 级别，让 CI 直接失败。

实坑记录： 我曾经遇到一个项目，测试代码里写了密码“test123”，结果 CI 一直报警。我建议直接禁止 password 出现在任何 .py 文件中，除非使用 # nosec 注释豁免。但 # nosec 必须经过代码审查才能用。

工具对比表

我挑了几款常用的工具，给个对比：

工具	语言支持	扫描模式	误报率	集成难度
Bandit	Python	AST + 模式匹配	中等	低
TruffleHog	全语言	正则 + 熵值检测	低	中
GitLeaks	全语言	正则 + 自定义规则	低	低
GitGuardian	全语言	ML + 规则+ API扫描	极低	中（商业）
Semgrep	多语言	模式匹配 + 数据流	低	中

我个人偏好 TruffleHog，它不仅能匹配关键词，还会用熵值算法发现看起来像密码的高随机字符串。比如 sk-proj-xxxxxxxxxxxxxxxx 这种，Bandit 扫不到，TruffleHog 能。

怎么从源头杜绝？

检测只是事后补救。真正该做的，是从流程上杜绝硬编码密码。我建议在团队内推行这几点：

秘钥管理服务：用 Vault、AWS Secrets Manager、Kubernetes Secrets 存储秘密。
环境变量注入：CI/CD 里通过环境变量传递密码，不写进代码。
Git钩子：在 pre-commit 阶段运行扫描脚本，阻止密码提交。
代码审查清单：每个PR必须检查是否含有硬编码秘密。

我记得有一次团队开发一个新功能，三天后我发现 CI 日志里竟然打印了数据库密码——原来有人为了调试方便，在日志里加了 print(f"DB_PASSWORD: {db_pass}")。我们立刻加了关键信息脱敏规则，并在 pre-commit 钩子里拦截 print 语句输出密码变量。

  一句话总结：静态密码的隐患，靠人眼盯不住，靠工具才能抓牢。把检测嵌入 CI/CD 管道，让机器替你把关。

说完硬编码密码的危害和检测，下一件事就是怎么把秘密安全地存起来、动态注入应用。但那是后话了——我们先把眼前的密码清理干净再说。