怎么保证我们软件安全？

结论：任何团队都无法保证软件绝对安全。可以承诺的是：先按业务风险约定安全基线，把威胁建模、身份权限、数据保护、代码与依赖检查、部署隔离、监测响应和恢复演练纳入全生命周期，并交付可复核证据。一次渗透测试、购买 WAF 或宣称“使用云服务”都不能单独构成安全保证。

安全目标必须来自系统事实。公开内容网站、企业内部审批、支付平台和医疗系统的攻击面、损失和监管要求不同。先列资产、用户、数据、外部接口、管理员、部署区域和最坏后果，再确定攻击者可能怎样滥用。没有威胁模型就堆产品，容易在低风险处花钱、遗漏业务越权和资金逻辑。

安全环节	关键控制	验证证据	常见误区
需求与设计	数据流、威胁模型、安全基线和滥用用例	评审记录、风险与接受人	上线前才扫描
身份与权限	多因素、最小权限、服务端授权、离职回收	越权测试、权限矩阵、账号盘点	前端隐藏按钮等于授权
代码与供应链	评审、静态检查、依赖与密钥扫描、构建来源	扫描结果、SBOM、修复记录	npm audit 无结果等于安全
数据保护	最小采集、加密、密钥隔离、日志脱敏和保留	数据目录、访问日志、轮换演练	所有字段加密即可解决滥用
部署与运行	网络边界、配置基线、监控、限流和补丁	基线对比、告警演练、变更记录	上了云或 WAF 自动安全
响应与恢复	分级响应、隔离、通知、备份与恢复	桌面演练、真实恢复结果、复盘	有备份文件却从未恢复

在落实合规责任、证据与技术控制时，还可以对照 把需求和创意告诉你们，会不会被抄去做给别的客户？怎么保护我的想法？ 和 如果要做一个在海外运营、涉及大量隐私数据的 App，应该怎么保护用户隐私？；这些内容补充了需要放在同一项决策中考虑的上下文。

安全要在代码写下之前进入需求

高风险动作如付款、退款、改价、导出、密钥创建和管理员授权，要明确谁能做、需要什么二次确认、如何撤销和审计。接口对每个对象做服务端授权，不能只验证用户已登录。JWT、OAuth 或 RBAC 只是实现工具，配置错误仍会越权；ORM 也不自动消除所有注入。关键规则应有正向、横向越权、纵向越权、重放和并发测试。

开发环境启用分支评审和受保护构建，密钥不进入仓库，依赖锁定并持续扫描。发现漏洞后按是否可达、数据与业务影响、外部暴露和已有缓解分级，而不是机械承诺所有 CVE 在 48 小时修完。紧急修复也要测试与可回滚。NIST SSDF 将准备组织、保护软件、生产安全软件和响应漏洞贯穿开发过程，适合用作供应商共同语言。

上线后用检测和恢复承认“防不住全部”

日志应足以关联账号、设备、请求、对象和变更，但不记录密码、令牌或不必要的敏感正文。对异常登录、权限提升、批量导出、费用突增、失败重试和日志中断设告警，并验证通知真的到达值班人员。安全事件预案写明谁判断、谁隔离、谁通知客户或监管、证据如何保存、服务怎样恢复。

备份需明确恢复点目标、恢复时间目标、地域、加密、不可变或隔离策略，并在隔离环境真实恢复数据库与文件。只显示“备份成功”不能证明业务可恢复。演练还要包含密钥丢失、供应商区域故障、恶意管理员和勒索破坏，记录实际恢复时间和数据差异。

验收时按明确版本引用 OWASP ASVS 5.0 的适用要求，形成通过、不通过、不适用及证据；再做代码检查、依赖检查、配置复核、权限与业务逻辑测试。独立渗透测试可增加可信度，但必须说明范围、时间、账号和排除项，修复后复测。报告“未发现”只代表在该范围和时间内没有发现，不代表不存在漏洞。

滚水科技会在合同中约定安全责任与不包含范围，并交付威胁模型、安全需求、测试结果、依赖清单、部署和恢复说明。云账号、域名、证书和监控最好由客户主体控制或可移交。质保与持续运维是不同服务：前者处理约定缺陷，后者包含补丁、监控、响应和演练，需明确人员和服务目标。

参考资料：

• NIST Secure Software Development Framework 1.1：用于把安全实践嵌入软件开发生命周期。
• OWASP Application Security Verification Standard 5.0：用于把 Web 应用安全控制转成版本化、可测试要求。
• 滚水科技透明交付标准：用于了解滚水科技公开的测试证据、资产与交接原则。