📚 课程目录第2章开发环境安全

开发环境安全：IDE 配置、依赖管理、代码仓库访问控制与审计

做 SDK 开发，第一道防线就在你手边的编辑器里。我见过不少团队，代码写得挺溜，环境却跟筛子似的——插件乱装、密钥明文保存、依赖随便拉。结果呢？要么被供应链投毒，要么仓库被黑。说白了，开发环境不安全，后续加固全是白费力气。

  核心观点： 安全不是运维的事，开发者自己就是第一责任人。IDE、依赖、仓库、审计，这四件事搞定，你的开发环境才算真正“锁上门”。

2.1 IDE 配置安全

你想想看，IDE 天天跟你的代码、依赖、凭证打交道。插件市场随便装个扩展，可能就带后门。我在一个项目里就遇到同事装了款「主题美化」插件，结果它偷偷读 ssh 配置。那之后我养成一个习惯：IDE 只装官方认证的插件，且每季度清理一次。

2.1.1 禁用不必要的插件

保留语言支持、版本控制、代码分析等必要插件。
从官方市场安装，避免第三方不明来源。
定期审查列表，移除长期未用的插件。

2.1.2 启用安全编码扩展

我个人习惯装这些：

ESLint / Pylint — 静态检查代码中的常见漏洞。
SonarLint — 实时检测安全热点（比如硬编码密钥）。
GitLens — 做提交审计时很好用。

小技巧： 在 VS Code 里用 settings.json 锁住安全相关配置，不让工作区覆盖。比如禁止自动保存时暴露敏感信息。

2.1.3 环境隔离

我很早就踩过这个坑：同一个 IDE 窗口打开了项目和私人文件，结果不小心把私人提交到了公司仓库。现在我的做法是：

用独立的工作区，不同项目用不同 IDE 实例。
配置 .gitignore 全局忽略敏感文件。
启用 IDE 的「专用模式」（如 VSCode 的 Remote SSH）在远程开发机上操作。

2.2 依赖管理

SDK 依赖第三方库很正常，但 不锁版本 等于把大门敞开。我见过一个依赖被恶意篡改后，几周内没人发现，因为 package.json 写的是 ^1.2.3。

2.2.1 使用锁文件

无论 npm、pip、Maven 还是 Gradle，都该生成并提交锁文件。锁文件能确保所有人拿到完全相同的依赖树。你想象下，有人用的 lodash 版本不同，行为就可能不一致。

# npm
npm install --package-lock-only
# pip
pip freeze > requirements.txt  # 或者用 pipenv, poetry 自动生成

2.2.2 漏洞扫描

我把扫描集成到 CI 里，每次合并前自动检查：

工具	语言/生态	扫描方式
npm audit	Node.js	官方数据库
pip-audit	Python	PyPI 漏洞库
Trivy	多语言	文件系统扫描
OWASP Dependency-Check	Java/.NET	CVE 匹配

举个例子，用 Trivy 扫描项目依赖的 Docker 镜像：

trivy image --severity HIGH,CRITICAL my-sdk:latest

特别注意： 有些依赖来自私有仓库（如公司内部的 npm 源）。如果直接走公网，可能存在中间人攻击。务必为私有仓库配置 SSL 和访问凭证。

2.2.3 私有仓库管理

我建议用 GitHub Package 或 Artifactory 搭建私有源，并在 .npmrc / pip.conf 里指定：

# .npmrc
registry=https://registry.npmjs.org/
@mycompany:registry=https://npm.pkg.github.com/
//npm.pkg.github.com/:_authToken=${GH_PACKAGES_}

2.3 代码仓库访问控制

你想想，仓库权限给错了，后果很直接。有一次我把一个实习生直接加成了 Owner，他误删了一个分支，还好有 reflog 救了回来。从那之后，我严格执行最小权限。

2.3.1 最小权限原则

只读（Read）：适用于 QA、外部审计。
写（Write）：能推送，但不能改分支保护设置。
管理员（Admin）：只给团队 Lead 和 SRE。

2.3.2 SSH 密钥管理

别用 HTTPS 加密码的方式，太容易泄露。SSH 密钥要：

使用 ed25519 算法，比 RSA 更快更安全。
配置 ssh-agent 管理，避免重复输入。
每个机器生成独立密钥，公司设备和个人设备分离。

ssh-keygen -t ed25519 -C "your_email@company.com"
# 然后添加到 GitHub/GitLab 的 Deploy Keys

2.3.3 分支保护规则

核心分支（main、release）必须锁住：

要求 Pull Request 审查（至少 1 人通过）。
禁止直接推送。
要求状态检查通过（CI、依赖扫描等）。
要求提交签名验证（详见下一节）。

2.4 审计与日志

光有控制还不够，你得能追溯。谁在什么时候改了什么东西，出了问题才能快速定位。这个环节我吃过亏，有一次依赖被篡改，查了好久才找到是某个离职员工遗留的还在用。

2.4.1 提交签名验证

用 GPG 或 SSH 签名提交，确保提交人真实。设置很简单：

# 生成 GPG 密钥
gpg --full-generate-key
# 告诉 Git 使用该密钥
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true
# 将公钥上传到 GitHub

以后每次 git commit 会签名，仓库页面上会显示「Verified」徽章。没签名的提交可能来自伪造者。

2.4.2 审计日志配置

GitHub/GitLab 都有审计日志功能，建议开启并转发到 SIEM 系统：

事件类型	示例	重要性
仓库创建/删除	某人新建了 secret-sdk 仓库	高
分支保护变更	关闭了 main 的审核要求	紧急
Deploy Key 添加	新增了外部机器的 SSH 公钥	高
成员角色变更	某成员从 Reader 升为 Admin	中等

我个人习惯： 每周检查一次审计日志，重点关注角色变更和密钥操作。很多入侵都是从失窃的开发者令牌开始的。

好了，IDE 配置、依赖管理、仓库权限和审计追踪，这四个方面都搭好了，你的开发环境才算真正上了锁。别嫌麻烦，安全是习惯问题。我自己每接一个新项目，都会花半天时间捋一遍这些配置——省得以后花两天去救火。你按这几步来，不会错的。