很多人以为装个杀毒软件就等于安全了，其实真正的防护得从软件“构建”阶段就开始。就像盖房子，地基打不好，再厚的墙也扛不住冲击。安全软件不是写完代码再加个扫描功能就完事，得在开发过程中就把安全逻辑嵌进去。
设计阶段就要考虑攻击场景
很多团队一开始只想着功能怎么实现，等产品快上线了才让安全人员介入，这时候发现问题往往要推倒重来。正确的做法是在需求评审时就列出可能的风险点。比如用户登录模块，不能只写‘支持密码登录’，还得加上‘防止暴力破解’‘密码加密存储’这类安全要求。
代码编写遵守最小权限原则
写代码时，别图省事直接用管理员权限运行服务。常见的错误是把整个进程跑在 SYSTEM 或 root 权限下，一旦被攻破，攻击者就能为所欲为。应该按功能拆分权限，比如日志写入用低权账户，配置修改才提权操作。
// 错误示范：所有操作都以高权限执行
runAsAdmin(function() {
logToFile('user login');
updateConfig();
});
// 正确做法：仅关键操作提权
logToFile('user login'); // 普通权限即可
runAsAdmin(() => updateConfig()); // 单独提权依赖库要定期审计
现在项目基本都靠第三方库堆出来的，但很多人从来不看用了啥。一个被爆出漏洞的 JSON 解析库，可能让你整个软件变成后门入口。建议每个项目维护一份依赖清单，并接入自动化工具监控 CVE 更新。每周花十分钟检查有没有高危组件，比事后应急强得多。
构建过程本身也要防篡改
编译打包的环境同样重要。曾经有公司 CI/CD 流水线被植入恶意脚本，在每次构建时偷偷插入挖矿代码。解决方案是锁定构建节点权限，所有变更走审批流程，同时对最终产物做哈希签名验证。
# 构建脚本示例：增加完整性校验
#!/bin/bash
npm install --only=prod
npm run build
sha256sum dist/app.js > dist/app.js.sha256
# 上传前手动核对或自动比对日志和监控不能等到出事才补
有些软件运行几个月都没日志，直到被通报说存在异常连接才知道遭了。构建时就得规划好日志级别，关键操作如权限变更、配置导出必须记录完整上下文。最好能对接 SIEM 系统，发现多次失败登录自动告警。
安全不是某个环节的任务，而是贯穿构建全过程的习惯。从第一行代码开始就想清楚‘如果这地方被利用会怎样’，才能做出真正扛得住攻击的软件。