开发者密码审计清单：系统化检查你的凭据卫生
78% 的开发者跨账户复用密码。密码审计不是企业安全表演，是系统化的凭据卫生——在变成泄露之前抓出真问题。平均开发者有 87 个工作与个人账户，手动复查耗时数小时，自动化工具又缺上下文。这份清单给开发者一个结构化流程，不带安全顾问式废话。
为什么 2026 年更要审计
- 泄露数据库已积累超过 150 亿条凭据对；攻击者把凭据填充（credential stuffing）自动化后，"以后再说"策略失效。
- 近期供应链攻击专门瞄准开发者账户：你的 GitHub、npm、AWS 凭据不只是个人风险，是打进生产系统的攻击向量。
- 现代威胁模型假设部分密码已被攻破。问题变成：哪些？多久能发现并轮换？
完整审计清单
Phase 1：盘点与分级——高优先先审：源码托管（GitHub/GitLab/Bitbucket）、云厂商（AWS/GCP/Azure）、包注册表（npm/PyPI/Docker Hub）、CI/CD（Jenkins/CircleCI/GitHub Actions）、生产数据库与管理后台、主邮箱、密码管理器主密码。中优先：域名注册商、支付/银行、社交媒体管理账号。
Phase 2：重复检测——导出密码列表（哈希或加密）、跑重复检测脚本、查近似变体（password1/password2）、识别共享基础模式。
Phase 3：访问模式复查——2FA 状态（高优先账户全开、优先 TOTP 而非短信、源码托管与云用硬件 key、备份码安全存档）；会话与恢复（审查活动会话、更新恢复邮箱、验证备用手机号、实际测试账户恢复流程）。
自动化工具链
# 泄露检测：多邮箱查泄露数据库
curl -H "hibp-api-key: YOUR_KEY" \
"https://haveibeenpwned.com/api/v3/breachedaccount/email@domain.com"
# 密码熵计算
def calculate_entropy(password):
charset_size = 0
if any(c.islower() for c in password): charset_size += 26
if any(c.isupper() for c in password): charset_size += 26
if any(c.isdigit() for c in password): charset_size += 10
if any(not c.isalnum() for c in password): charset_size += 32
return len(password) * math.log2(charset_size)
# GitHub token 审计
gh auth status
gh api user/tokens --jq '.[] | {name: .note, scopes: .scopes, created: .created_at}'
实施节奏
- 第 1 周：审计高优先账户、主邮箱查泄露、补齐 2FA、给任何已泄露凭据换新密码；
- 第 2 周：按优先级审计剩余账户、设置自动化泄露监控、文档化恢复流程、测试备用认证；
- 持续：每月查泄露库、每季度轮换高风险账户密码、每年按最新威胁模型做全量审计、安全通知立即处理。
常见审计发现
43% 开发者用超过两年的旧密码；生产环境密码强、开发环境弱（攻击者拿开发系统当跳板）；换工作后忘更新恢复邮箱（旧公司邮箱成为攻击向量）；GitHub 账户平均 12 个 personal access token，多数不过期不轮换。
密码审计不光彩但基础。花在清单上的 30 分钟，可能省掉几个月的应急响应。对团队再进一步：用正规 secret 管理替代共享表格、自动化云厂商 key 轮换、文档化泄露响应流程。
来源：Password Audit Checklist: How Developers Should Review Security - DEV Community