语言 Chinese, Simplified

SEO Title

Why existing secure SDLC methodologies are failing

规模，自动化和不断增长的成本越来越多地促使组织采用安全的软件开发生命周期（SDLC）方法。虽然静态代码分析和漏洞扫描等工具在提高应用程序安全性方面取得了成功，但组织已经开始认识到SDLC内安全审查早期集成的价值 - 最显着的是它降低了管理和修复成本的能力与安全相关的错误。

但是，许多用于执行此操作的方法（如OpenSAMM，BSIMM和Microsoft的SDL）采用的方法类似于低效，自上而下的瀑布式方法。这些保护SDLC的方法在业界很多都失败了，需要采用新的方法。

流行的安全SDLC方法

正如许多专家建议的那样，软件组织通常采用自上而下的方法来实施安全的SDLC方法。虽然这种方法的好处是可以确保安全软件开发过程所需的组件，但它并不能保证安全的产品。

以下是目前帮助组织在其SDLC中集成安全性的流行方法的简短列表。

OpenSAMM：软件保障成熟度模型（SAMM）是一个OWASP项目，用于指导SDLC中的安全性集成。所描述的12项活动分为四类：治理，建设，验证和部署。
BSIMM：由Cigital开发的建筑安全成熟度模型（BSIMM）由12个实践组成，分为4个领域：治理，智能，安全软件开发生命周期（S-SDLC）接触点和部署。
SDL：Microsoft安全开发生命周期旨在创建符合法规标准的安全软件，同时降低开发成本。微软开始推广这种方法，强调分别在2001年和2002年遵循CodeRed和Nimda蠕虫的安全编码实践的重要性。

安全SDLC方法已经为软件开发人员做出了许多承诺，特别是SDLC中早期安全集成带来的成本节约，这有助于避免代价高昂的设计缺陷并提高软件项目的长期可行性。

但是，这些方法并非没有缺点。

瀑布SDLC方法在敏捷环境中受阻

流行的方法通常将组织划分为业务单元或业务功能，并且仅在其他活动完成后才依赖于启动某些活动。这种组织结构假设业务活动以特定的线性顺序发生，这是敏捷框架难以协调的主张。

例如，Microsoft SDL定义了一种称为“建立安全和隐私要求”的做法，该做法建议尽早开发安全和隐私目标，以便最大限度地减少调度冲突，但这也会产生创建敏捷环境中通常不存在的严格时间线的效果。

在敏捷框架下，他们强调持续集成和持续部署，很少有软件开发团队创建详细记录长期计划的文档。这使得敏捷团队难以实现这种以瀑布为中心的安全SDLC。

实施成本很高

与实施SDLC相关的成本可能过高。根据OpenSAMM自己的估计，当使用下表第二列中描述的估计小时费用时，实施其12项活动中的每项活动将花费大约90,000美元。

Table
尽管为确保整个组织的开发过程提供90,000美元看起来似乎很划算，但应该提到三个警告。

90,000美元的估算仅包括实施OpenSAMM第一级到期水平的成本，不包括第二级或第三级的成本，这无疑会大大提高最终成本。
90,000美元的估计是保守的。 OpenSAMM每年为第一个成熟度级别所需的代码审查活动分配五到九天。因此，这可能是一个非常小的组织，或者估计是不完整的，可能只考虑设置成本而不是持续的运营费用。我组织并参与了无数的代码审查，我可以证明它们是一项耗时的活动，在大多数情况下很容易超过90,000美元的估算。
最后，方法所推荐的实施活动的价值往往在这个过程中丢失，而这些活动的实施完全是因为它们作为必须满足的清单上的要求而存在才能继续前进。例如，实施漏洞扫描并不能保证甚至可以查看扫描，更不用说采取行动了。如果要从其实施中获得价值，则必须了解活动的背景及其相关指标的相互作用。

自下而上的安全SDLC

也许SDLC方法不应该从上到下，而是从下到上来处理和实施。您可以先确定目标，然后确定并采用最有效地帮助您实现这些目标的活动，而不是实施满足检查表要求的活动。

对于这种方法，有必要首先确定对您的组织成功至关重要的指标。在我看来，有两个重要指标：漏洞总数及其平均补救时间。

漏洞总数：任何方法的唯一目的是帮助组织系统地，始终如一地生成更安全的代码。查找并减少代码中的漏洞数量意味着您已经创建了一个更安全的最终项目。
平均修复时间：由于两个重要原因，修复后期制作中的错误比在预生产中修复它们要成本高得多。首先，存在的错误越长，攻击者就越需要利用它们。其次，随着开发人员转向不同的项目，或者在某些情况下，其他公司，组织解决安全问题的能力会降低，从而增加与修复这些问题相关的成本。

确定关键指标后，首先要实施可以帮助您尽快达到指标目标的活动。所选指标将指导您识别和实施可帮助您实现目标的活动。安全的用户故事，安全代码审查，渗透测试和环境强化只是一些可能有用的活动。