软件脆弱性的三种定义流派及其共同局限

脆弱性本质上描述的是一种应对波动性、随机性变化或压力时的表现：如果表现是”扛不住”就是脆弱（vulnerable），如果”完全不受影响”就是强壮（strong），如果”反而因此获益、适应性更强”就是反脆弱（antifragile）——软件脆弱性是这个通用概念在软件系统上的具体投射。学界对”什么是软件脆弱性”至今没有统一定义，主要存在三种流派。基于访问控制的定义（Krsul等）：把系统状态描述成主体-对象-访问控制矩阵三元组，访问控制矩阵规定了安全策略，凡是能引起系统执行违反该策略的操作，就是在利用脆弱性；这个定义的问题在于它要求系统存在一个清晰详尽的访问控制矩阵，但UNIX、Windows NT这类真实操作系统并不存在这样精确的矩阵，定义在真实系统上难以落地。基于状态空间的定义（Bishop等）：把操作系统看作一系列描述实体配置的状态（授权/非授权/易受攻击/不易受攻击），系统运行就是状态间的迁移，迁移分授权和非授权两类，若从初始状态经过一系列授权迁移就能到达某个非授权状态，这个状态就叫脆弱状态；这个定义比三元组定义更精细，但同样难以应用到真实系统上——即使能穷举所有安全/非安全状态，状态划分本身不是一个静态封闭的过程，还必须考虑运行环境和用户实际动作，穷举不可能真正完成。描述性定义（Krsul等的另一种表述）：软件脆弱性就是软件规范、开发或配置中的错误实例，其执行结果会违反安全策略——这个定义放弃了前两种定义追求形式化精确的野心，转而直接从”错误在哪个环节产生”入手，也是本书后续讨论采用的立场：软件脆弱性是导致破坏系统安全策略的系统安全规范、系统设计、实现和内部控制等方面的弱点，具体覆盖软件基础模型、架构设计、模块设计、接口设计、界面设计、数据库设计、架构模式与设计模式、以及实现这八个层面的脆弱性。三种流派的共同教训是：越追求形式化精确的定义（三元组、状态空间），越难在真实系统上落地；反而是放弃精确边界、聚焦”错误来源在哪”的描述性定义，才具备可操作性。