针对软件错误和漏洞的静态分析测试（ SAST ）应该成为应用程序安全性和软件质量程序的一部分。 您需要做的就是运行一个工具，它将在开发的早期发现价格便宜且易于修复的错误。 听起来很简单。
但是，这不仅需要购买工具并运行扫描，还需要将代码上传到测试服务并让他们为您运行扫描。 您需要开发人员及其经理的直接参与和支持。 因为静态分析找不到错误。 它在代码中找到可能是错误的东西，并且您需要开发人员确定什么是真正的问题，什么不是。
我和弗兰克·金（Frank Kim） 参与的今年SANS研究所对Appsec程序和实践的调查发现，静态分析的使用排在组织认为对他们的appsec程序有用的工具和实践列表的底部。
这是因为您需要开发人员作出真正的承诺才能使静态分析测试成功，并且要确保这一承诺并不容易 。
您是在要求开发人员承担额外的工作和额外的费用，并更改他们的工作方式。 开发人员必须从交付时间表中抽出时间来理解和使用这些工具，并且他们需要了解这将需要多少时间。 他们必须确信工具所发现的问题值得花时间研究和修复。 他们可能需要帮助或培训，以了解发现的含义以及如何正确修复它们。 他们将需要时间来解决问题，并需要更多的时间来测试并确保它们不会意外损坏任何东西。 他们将需要帮助，将静态分析集成到他们未来如何构建和测试软件的方式中。
谁拥有并运行这些工具？
首先要确定的是组织中的谁拥有静态分析测试：设置和运行工具，查看并确认结果以及解决问题。
Cigital的Gary McGraw解释说， 拥有和运行静态分析工具有两种基本模型 。
在某些组织中，Infosec拥有并运行这些工具，然后与开发人员合作以解决问题（或将结果扔给开发人员，告诉他们他们有很多问题需要立即解决）。 这就是McGraw所谓的“集中式代码审查工厂” 。 安全团队可以实施一致的策略，并确保定期扫描所有代码，并采取后续措施以确保问题得到解决。
这节省了开发人员的时间和麻烦，无需他们了解该工具以及设置和运行扫描程序，Infosec团队可以通过在检查结果通过之前对其进行审查和鉴定（使之排除假阳性和其他东西，使开发人员更容易）。看起来不重要）。 但是，开发人员无法控制何时运行扫描，也不一定总是在需要时获得结果。 反馈周期可能太慢，特别是对于快速发展的敏捷团队和Devops团队而言，他们依赖TDD和Continuous Integration的即时反馈，并可能在扫描结果甚至还没有返回之前就推出代码。
一种更具可扩展性的方法是使开发人员直接负责运行和使用工具。 Infosec可以帮助您进行设置和培训，但是由开发人员来确定他们将如何使用这些工具以及将要修复的内容和时间。 在这样的“自助服务”模型中，重点是将静态分析适合于开发流程，以免妨碍开发人员的思考和解决问题。 这可能意味着将自动扫描添加到“持续集成”和“持续交付”工具链中，或者将静态分析直接集成到开发人员的IDE中，以帮助他们在编码时立即发现问题（如果此工具随附）。
那些已经依赖自动化开发人员测试和其他质量实践的有纪律的开发和Devops团队 ，应该不会感到困难-只要从一开始就正确地设置工具，以便他们从发现的工具中看到价值。
让开发人员使用静态分析
我们已经或在其他组织中已经采用了几种简单的采用静态分析测试的模式，这些模式可以单独或组合使用，具体取决于您已经编写了多少软件，多少了。您必须使用这些工具的时间，以及您的组织规模
插入，调出，分类
从一个试验开始，在一个重要的错误真正重要的应用程序上，开发人员正在努力开发。 试点可由安全团队（如果他们有技能），顾问或什至是供应商在开发的帮助下完成。 或者，您可以将其作为一个聪明的高级开发人员的特殊项目，他们能够理解代码，说服他们这很重要并且您需要他们的帮助，在他们需要时对其进行一些培训以及在供应商的帮助下进行操作突如其来-一两个星期应该足以开始。
这个小型项目的重点应该是确保正确安装和设置了该工具（将其集成到内部版本中，确保其覆盖正确的代码），了解其如何提供反馈，并确保已获得正确的工具，然后使其适合开发人员使用。 不接受默认情况下该工具的运行方式。 运行扫描，查看运行需要多长时间，查看结果，并集中精力将误报和其他噪音降低到最低程度。 尽管供应商继续提高静态分析工具的速度和准确性，但大多数静态分析工具还是会谨慎行事，指出尽可能多的潜在问题， 以最大程度地减少误报 （错过一个真正的错误） 的机会 。 这意味着要经过很多噪音，浪费大量时间。
如果您在项目早期就开始使用SAST，这可能还不错。 但是， 如果您使用的是现有代码库，则可能会严重拖累人们的时间：根据语言，体系结构，编码风格（或缺乏），代码库的大小及其使用年限，您可能最终会运行静态分析扫描时会显示成百上千的警告。 加里·麦格劳（Gary McGraw）称之为“死亡的红色画面” –一长串的问题，开发人员昨天不知道自己的代码中有这些问题，现在他们被告知必须今天处理。
并非每个静态分析结果都需要固定，甚至不需要详细检查。 重要的是要弄清楚什么是真实的，什么是重要的，什么不是什么，并将发现列表缩减为易于管理的问题列表，这些问题值得开发人员研究甚至解决。 每个应用程序都需要进行同样的审查，并且设置和调整的方法可能不同。
减少误报和不重要的噪音的一种好方法是查看检查结果最多的检查器–如果您收到成百上千的同类警告，则不太可能是一个严重的问题（希望如此）比起不正确的检查器，它会抛出过多的误报或不重要的像棉绒般的挑剔的抱怨，这些抱怨现在可以放心地忽略掉。 这是昂贵的，并且花费大量时间和金钱来回顾所有这些发现–对它们进行抽样，看看是否有任何意义，让开发人员运用他们的判断力并决定是否将其过滤掉。 请关闭所有不重要或无用的规则，因为您可能需要稍后再检查。 您正在这里做出重要的权衡决策–工具供应商无法或不会为您做出的权衡。 通过关闭规则或检查程序，您可能会在系统中留下一些错误或安全漏洞。 但是，如果您没有将清单归结为实际和重要的问题，则可能会冒完全失去开发团队合作的风险。
将大部分精力放在该工具认为严重问题上。 每个工具（无论如何，我都已经看到过）对发现的结果都有一个加权或评级系统，一种识别高风险问题的方法，以及对发现的有效结果的置信度。 显然，高风险，高自信的发现是您应该花费大部分时间进行检查的地方，而这些问题可能需要首先解决。 您可能无法立即理解它们，为什么该工具会告诉您某些问题或如何正确修复。 但是你知道从哪里开始。
采摘樱桃
您可以运行的另一种峰值是采摘低垂的果实。 要求精明的开发人员或开发人员小组审查结果并开始寻找（并修复）真正的错误。 对开发人员有意义的错误，已经使用或可以轻松理解的代码错误，知道如何修复且值得修复的错误。 如果您在设置工具和预先调整方面做得很好，这应该很容易。
寻找不同的错误，而不仅仅是一种错误。 看看工具有多清楚地解释了什么是错误的以及如何纠正它。 选择少数几个并修复它们，确保可以安全地修复问题，然后进行测试以确保修复正确并且没有意外损坏任何东西。 然后寻找更多错误，并在开发人员习惯使用该工具后，进行更多调整和自定义。
花足够的时间让开发人员对工具值得使用建立信心，并了解继续使用该工具的成本。 通过让他们决定要修复哪些错误，您不仅可以预先提供一些实际价值并修复一些错误，而且还可以帮助确保开发支持：“看，这件事确实有效！” 您将了解使用成本。 如果您最好的一些开发人员花了这么长时间来理解和修复一些明显的错误，那么期望其余的团队花费更长的时间来理解和修复其余的问题。 您可以使用这些数据来建立端到端成本的估算，并在以后进行权衡决策时，确定哪些问题值得解决或不值得解决。
灭虫
静态分析入门的另一种方法是决定消除应用程序或整个产品组合中的一种错误。 选择“每月的错误”，例如SQL注入–一个高风险，高回报的问题。 花一些时间来确保每个人都了解问题，为什么需要修复，如何进行测试。 然后隔离与该问题相关的发现，找出修复和测试并部署修复所需的工作，然后“完成”。
这有助于使人们集中精力并建立势头。 开发工作和测试工作更简单，风险也更低，因为每个人都在从事同一种问题，并且每个人都可以学习如何正确地解决它。 它提供了一个机会，可以教育每个人如何处理重要的错误或安全漏洞，修补它们，并希望将来不再发生。
向前修正
除非已经在生产中遇到严重的可靠性或安全性问题或需要满足某些合规性要求，否则在已经运行的代码中检查并修复静态分析结果可能不值得。 而且，与任何更改一样，您会冒着引入新问题的风险，同时尝试修复旧问题，使事情变得更糟而不是更好。 对于代码质量发现尤其如此。 Findbugs的父亲Bill Pugh 在Google进行了一些研究，结果发现
“工作系统中的许多静态警告实际上并未表现为程序故障。”
说服开发人员只专注于检查和修复新代码或他们正在更改的代码中的静态分析发现，而将其余发现留在后面至少可以开始，这可能会便宜得多且容易得多。
让团队在开发团队中实施零容错程序或其他协议，以一经发现便立即审查和清理来自静态扫描的许多新发现，并将其作为“完成的定义”的一部分。 在Intuit，他们称之为“没有新缺陷” 。
无论工具发现什么问题，都应该易于理解且易于修复（因为开发人员现在正在开发代码，他们应该足够了解以对其进行修复）并且易于测试（这是无论如何都需要进行测试的代码）。 如果您经常运行扫描，则一次只应处理少量问题或警告。 这意味着修复错误不会花费很多，也不会花费很多时间–如果反馈循环足够短，并且该工具的指南很清楚地指出了问题所在和原因，那么开发人员应该能够查看并修复发现的每个问题，而不仅仅是最严重的问题。 在开发人员几次遇到相同的问题之后，他们将学会避免它们并停止犯同样的错误，从而改善了编写代码的方式。
为此，您需要能够区分现有（陈旧）的发现和最新签入中引入的新（新）问题。 大多数工具都有做到这一点的方法，而某些工具（例如Grammatech的CodeSonar）经过专门优化，可以进行增量分析。
在这里，快速反馈和自助服务方法会特别有效。 与其等待其他人进行扫描并传递结果或进行即席扫描，不如将结果尽快返回给从事代码工作的人员。 如果开发人员无法在IDE中获得直接反馈（您要在一夜之间运行扫描，或者按其他不那么频繁的计划运行扫描），则可以使用不同的方法来处理结果。 您可以将静态分析结果直接输入到错误跟踪器中。 或者进入团队的在线代码审阅过程和工具（ 就像在Google一样 ），以便开发人员和审阅者可以同时查看代码，审阅注释和静态分析警告。 或者，您可以让某人（安全专家或开发人员）每天对结果进行监管，确定其优先级，或者自己修复代码，或者向正在使用该代码段的人传递错误或严重警告（取决于您的代码所有权模型） ）。 每天早晨只需几分钟-通常根本没有时间，因为在夜间扫描中可能什么也没捡到。
向前修正可以使您更快地开始，而且您不需要为一个单独的项目辩护，甚至不需要花一个大笔钱就可以开始工作-它只是开发人员编写和测试代码的另一部分，是另一个运行单元测试的反馈循环。 但这意味着您留下了一些-可能很多-未完成的业务。
回来打扫房子
无论您采取哪种前处理方式–忽略其中的内容，而只是解决问题，或者只采摘，或者消除一种类型的错误–您都会积压待查的发现积压的结果，其中可能包括应该修复的实际错误，尤其是安全性旧代码中的漏洞。 对“ 蜜月效应 ”的研究表明，未修复旧代码中的漏洞可能会带来严重的安全风险，因为这使攻击者有更多时间查找和利用它们。
但是，这样做的好处是，等到以后再检查并修复遗留的错误，直到团队有机会使用该工具并更好地理解它，直到他们对安全地理解和修复问题的能力充满信心，这才是有利的。 您需要决定如何处理这些旧发现。 您可以标记它们并将其保留在工具的数据库中。 或者，您可以将它们导出或将它们（至少是严重的问题）重新输入到缺陷跟踪系统中。
然后安排另一个高峰：让一个高级开发人员或几个开发人员来审查其余发现，消除误报，并修复或制定计划以解决所遗留的问题。 现在，既然团队知道工具的工作原理，发现的含义，发现的结果不是错误，容易修复的错误，不值得修复的错误，这应该会更容易，更便宜，更安全。他们应该注意哪些错误（可能通过使工具满意而引入回归错误的可能性很大）。 这也是重新审视您做出的任何早期调优决策的时候，看看是否值得重新启用一些检查程序或规则。
长期行动和思考
不要对待静态分析测试（如笔测试或其他安全性检查或质量检查）。 进行静态分析可能要从软件安全团队（如果您的组织足够大，可以拥有一支并且具备必要的技能）或一些顾问开始，但是您的目标不仅仅是将一长串工具发现传递给开发主管或项目经理。
您想修复这些错误-至少是真实的。 但更重要的是，您要使静态分析测试成为开发人员在更改或修改代码时或在开始新项目时如何进行思考和进行工作的组成部分。 您希望开发人员从使用工具中学习，从工具提供的反馈和指导中学习，从一开始就编写更好，更安全，更安全的代码。
Pravir Chandra，Brian Chess和John Steven（三位对此问题非常了解的人）在“ 使工具投入使用：如何成功进行源代码分析 ”中列出了成功采用静态分析测试的五个关键：
- 从小处着手–从试点开始，学习，取得成功，然后从那里开始。
- 竭尽全力-与其尝试解决所有可能的问题，不如选择一些最容易出错的事情，并首先加以解决。 只需少量投资，您将获得巨大的影响。
- 任命一名拥护者–寻找对系统了解，受人尊敬和关心的开发人员，使用该工具出售它们，让他们站在您的一边，并由他们负责。
- 衡量结果–监视结果，查看已修复的错误，修复的速度，出现的错误以及需要帮助的地方。
- 自己制作–定制工具，编写自己的特定于应用程序的规则。 大多数组织都没有做到这一点，但是至少需要花些时间尽早调整工具，以使其更有效，更易于开发人员使用，并尽快滤除大量噪声。
意识到所有这些都需要时间和耐心。 务实。 变通。 逐步工作。 长期计划和工作。 帮助人们学习和改变。 使它成为开发人员想要使用的东西，因为他们知道它将帮助他们做得更好。 然后，您已经完成了工作。
翻译自: https://www.javacodegeeks.com/2014/03/implementing-static-analysis-isnt-that-easy.html
