本文目录一览：

• 1、安全开发你必须使用的28个DevSecOps工具
• 2、最受欢迎的软件安全性测试工具有哪些？
• 3、开源软件安全性如何

安全开发你必须使用的28个DevSecOps工具

将安全融入开发过程，更早捕获并修复应用漏洞，你需要这五类共28款DevSecOps工具。

DevSecOps 是将安全集成到整个应用开发周期的过程，是从内到外强化应用，使其能够抵御各种潜在威胁的理想方式。因为很多公司企业不断开发应用以满足客户和商业合作伙伴的需求，DevSecOps的吸引力也与日俱增。

敏捷开发方法与DevOps操作帮助公司企业达成持续开发的目标。云原生应用架构也成为了DevSecOps运动的有力贡献者，推动采用公共云提供商、容器技术和容器平台为应用提供计算能力。DevSecOps将安全过程与工具集成进工作流并加以自动化，摆脱了传统方法按时间点进行的潜在干扰，是个无缝且持续的过程。

咨询公司 Data Bridge Market Research 称，鉴于网络安全威胁数量与危害性的持续上升，全球DevSecOps市场预计将从2018年的14.7亿美元增长至2026年的136.3亿美元。

市场繁荣之下，DevSecOps工具必将呈现百花齐放百家争鸣的局面。下面就按核心门类为您呈上多款优秀DevSecOps工具。

开发应用的时候很容易忽略掉安全漏洞。下面的工具为开发人员提供了潜在安全异常及缺陷的警报功能，可供开发人员及时调查并修复这些漏洞，不至于走得太远回不了头。有些工具专用于警报功能，比如开源的Alerta 。其他工具则兼具测试等别的功能，比如 Contrast Assess。

1. Alerta

()

该开源工具可将多个来源的信息整合去重，提供快速可视化功能。Alerta与Prometheus、Riemann、Nagios、Cloudwatch及其他监视/管理服务集成，开发人员可通过API按需定制Alerta。

2. Contrast Assess

()

作为一款互动应用安全测试(IAST)工具，Contrast Assess 与用户应用集成，在后台持续监视代码，并在发现安全漏洞时发出警报。据称即便是非安全开发人员也可使用 Contrast Assess 自行识别并修复漏洞。

3. Contrast Protect

()

该运行时应用自保护(RASP)工具采用了 Contrast Assess 同款嵌入式代理。Contrast Protect 在生产环境中查找漏洞利用程序和未知威胁，并将结果提交给安全信息及事件管理(SIEM)控制台、防火墙或其他安全工具。

4. ElastAlert

()

ElastAlert提供近实时接收警报的框架，可接收来自Elasticsearch数据的安全异常、流量激增及其他模式。ElastAlert查询Elasticsearch并根据一系列规则比较这些数据。一旦出现匹配，ElastAlert便发出警报并随附建议动作。

大多数DevSecOps工具都提供一定程度的自动化。此类工具自动扫描、发现并修复安全缺陷，只是自动化程度各有不同，从条件式事件驱动的自动化到运用深度学习技术的自动化都有。

1. CodeAI

()

旨在通过深度学习技术自动查找并修复源代码中的安全漏洞，号称可为开发人员提供可供参考的解决方案列表，而不仅仅是安全问题列表。其供应商QbitLogic宣称，已为CodeAI馈送了数百万个现实世界漏洞修复样本供训练。

2. Parasoft tool suite

()

Parasoft提供包括应用开发安全测试在内的多种自动化工具：

1）Parasoft C/C++test

()

用于开发过程早期缺陷识别；

2）Parasoft Insure++

()

可以查找不规范编程及内存访问错误；

3）Parasoft Jtest

()

用于Java软件开发测试；

4) Parasoft dotTEST

()

以深度静态分析和高级覆盖作为 Visual Studio 工具的补充。

3. Red Hat Ansible Automation

()

该工具包含三个模块——Ansible Tower、Ansible Engine 和 Red Hat Ansible Network Automation，可作为无代理IT自动化技术单独或联合使用。尽管不是专门的安全工具，Ansible Automation 却可供用户定义规则以确定自身软件开发项目中哪些部分是安全的。

4. StackStorm

()

该开源工具号称“可进行条件式运营”，其事件驱动的自动化能在检测到安全漏洞时提供脚本化的修复与响应，并附有持续部署、ChatOps优化等功能。

5. Veracode

()

该公司提供DevSecOps环境中广泛使用的一系列自动化安全工具，包括在代码编写时即时自动扫描的Greenlight；在沙箱中扫描代码漏洞的 Developer Sandbox；识别漏洞组件的 Software Composition Analysis (SCA)；以及识别应用缺陷的 Static Analysis。

专用DevSecOps仪表板工具可使用户在同一图形界面中查看并共享从开发伊始到运营过程中的安全信息。有些DevSecOps应用，比如ThreatModeler和Parasoft已自带仪表板。

1. Grafana

()

该开源分析平台允许用户创建自定义仪表板，聚合所有相关数据以可视化及查询安全数据。如果不想自行构建，还可以在其网站上选用社区构建的仪表板。

2. Kibana

()

如果你使用Elasticsearch，该开源工具可在统一图形界面中集成成千上万的日志条目，包括运营数据、时间序列分析、应用监视等等。

威胁建模DevSecOps工具用以在复杂的攻击界面中识别、预测并定义威胁，以便用户可以做出主动安全决策。有些工具可根据用户提供的系统及应用信息自动构建威胁模型，并提供可视化界面以帮助安全及非安全人员 探索 威胁及其潜在影响。

1. IriusRisk

()

出自 Continuum Security 的解决方案，既可云部署，也可现场部署，能以基于问卷的界面自动化风险及需求分析，并设计出威胁模型和技术性安全要求。IriusRisk还可帮助用户管理代码构建及安全测试阶段。

2. ThreatModeler

()

该自动化威胁建模系统有两个版本：AppSec版和云版。在提供了用户应用或系统的功能性信息后，ThreatModeler会基于更新的威胁情报自动就整个攻击界面进行数据分析和潜在威胁识别。

3. OWASP Threat Dragon

()

一款基于Web的开源工具，提供系统图解和用于自动化威胁建模与缓解的规则引擎。Threat Dragon 承诺可与其他软件开发生命周期(SDLC)工具无缝集成，且界面易于使用。

在开发过程中测试应用以找出潜在漏洞是DevSecOps的关键部分，能够事先发现安全漏洞，避免漏洞被黑客利用。尽管其他工具往往包含了测试功能，比如Parasoft出品的那些，下列工具仍然在应用安全测试上表现强劲。

1. BDD-Security

()

该出自 Continuum Security 的开源框架可使安全人员在敏捷开发过程中测试行为驱动开发(BDD)语言编写的功能及非功能性安全场景。此BDD框架旨在使安全功能独立于应用特定的导航逻辑，让同样的安全要求能够更容易地应用到多个应用程序上。

2. Checkmarx CxSAST

()

可对25种编程及脚本语言进行未编译/未构建源代码扫描的静态应用安全测试(SAST)工具，能在SDLC早期发现成百上千种安全漏洞。CxSAST兼容所有集成开发环境(IDE)，是Checkmarx软件暴露平台的一部分——该平台可在DevOps所有阶段植入安全。Checkmarx的交互式应用安全测试(IAST)工具可检测运行中应用的安全漏洞。

3. Chef InSpec

()

整个开发过程中的每一阶段都可以运用该开源工具自动化安全测试以确保针对传统服务器及容器和云API的合规、安全及其他政策要求。

4. Fortify

()

Micro Focus 出品，提供端到端应用安全，可供进行覆盖整个软件开发生命周期的现场及按需测试。Fortify on Demand 是 Micro Focus 的应用安全即服务产品，提供静态、动态和移动应用安全测试，以及生产环境中Web应用的持续监视。

5. Gauntlt

()

流行测试框架，旨在推动易操作的安全测试及安全、开发和运营团队间的沟通。GauntIt便于产生攻击测试用例，且能方便地钩入现有工具及进程。

6. Synopsys suite

()

Synopsys提供多个应用安全测试工具，包括：

1）SAST工具Coverity

()

自动化测试且融入持续集成/持续交付(CI/CD)管道；

2）SCA工具 Black Duck

()

采用容器及应用中的开源和第三方代码检测并管理安全；

3）SeekerIAST

()

识别可暴露敏感数据的运行时安全漏洞；

以及一系列用于应用安全测试的托管服务。

以下DevSecOps工具同样含有上述工具提供的功能，但或多或少略有不同。

1. Aqua Security

()

在整个CI/CD管道和运行时环境中管理端到端安全，可用于所有平台和云环境的容器及云原生应用。

2. Dome9 Arc

()

被 Check Point 收购，提供自动化测试及安全实施，使开发人员能够将安全及合规融入公共云应用的构建、部署及运营。

3. GitLab

()

该工具可将DevSecOps架构融入CI/CD过程，在提交时测试每一块代码，使开发人员能够在编程期间缓解安全漏洞，并提供涵盖所有漏洞的仪表板。

4. Red Hat OpenShift

()

为基于容器的应用提供内置安全，比如基于角色的访问控制、以安全增强的Linux(SELinux)实现隔离，以及贯穿整个容器构建过程的核查。

5. RedLock

()(前身为Evident.io)

Palo Alto Networks 出品，适用于部署阶段，帮助开发人员快速发现并缓解资源配置、网络架构及用户活动中的安全威胁，尤其是在亚马逊S3存储桶和弹性块存储(EBS)卷上。

6. SD Elements

()

出品自 Security Compass 的自动化平台，旨在收集客户软件信息，发现威胁及对策，突出相关安全控制措施以帮助公司企业实现其安全和合规目标。

7. WhiteHat Sentinel 应用安全平台

()

该解决方案提供贯穿整个SDLC的应用安全，适用于需将安全集成进工具中的敏捷开发团队，以及需持续测试以保证生产环境应用安全的安全团队。

8. WhiteSource

()

用于解决开源漏洞，可集成进用户的生成过程，无论用户采用什么编程语言、生成工具或开发环境。WhiteSource使用经常更新的开源代码数据库持续检查开源组件的安全及授权。

最受欢迎的软件安全性测试工具有哪些？

之前在做 国内软件测试现状调查 之时，因为安全性测试工具太多，结果显示其分布比较广，填写“其它”占的比重很高（66%），为此专门做了一个调查 ，虽然收集的有效反馈不多（不到100），但基本反映了测试工具的使用现状。

1. 从总体看，（静态的）代码分析工具和（动态的）渗透测试工具应用还是比较普遍 ，超过60%，而且渗透测试工具（73.68%）略显优势，高出10%。模糊测试工具，可能大家感觉陌生，低至16%，但它在安全性、可靠性测试中还是能发挥作用的。从理论上看，代码分析工具应该能达到95%以上，因为它易用，且安全性已经是许多公司的红线，得到足够重视。 希望以后各个公司能够加强代码分析工具和模糊测试工具的应用。

2. Java代码安全性分析工具前三名是 ： IBM AppScan Source Edition（42.11%）、Fotify Static Code Analyzer（36.84%）、Findbugs（26.32%） ，而JTest、PMD等没进入前三名，虽然和第3名差距不大，只有5%左右。也有公司使用Checkmarx，不在此调查中。Coverity也支持Java，可能Java的开源工具较多，人们很少用它。

3. C/C++代码安全性分析工具前三名是 ： C++Test（38.89%）、IBM AppScan Source Edition（38.89%）、Fotify Static Code Analyzer（27.78%）、Visual Studio（27.78%） 。Coverity、CppCheck、LDRA Testbed 没能进入前三名，可能LDRA Testbed比较贵，关键的嵌入式软件采用比较多，而Coverity Cloud针对Github等上面的代码有免费服务（），大家可以尝试应用。

4. JavaScript代码安全性分析工具应用最多的是 Google's Closure Compiler，其次是JSHint，也有的公司用Coverity来进行JS的代码分析。

5. Python代码安全性分析工具应用最多的是Pychecker ，其次是PyCharm，而Pylint使用比较少，也有几个公司用Coverity来进行Python的代码分析。

6. Web应用安全性测试的商用工具中，IBM AppScan异军突起 ，高达70%的市场，其它商用工具无法与它抗衡，第2名SoapUI和它差距在50%以上，HP webInspect 不到10%。

7. Web应用安全性测试的开源工具中，Firebug明显领先 ，将近50%，比第2名OWASP ZAP高12%，第三名是Firefox Web Developer Tools，超过了20%。

8. Android App的安全性测试工具中，Android Tamer领先 ，将近30%，比第2、3名AndroBugs、Mobisec、Santoku高15%左右。也有用其它不在调查项中的工具，总体看，Android App安全性测试工具分布比较散。

9. 网络状态监控与分析工具中，Wireshark遥遥领先，超过70%。 其次就是Tcpdump、Burp Suite，占30%左右。网络状态监控与分析工具挺多的，但从这次调查看，越来越集中到几个工具中，特别是Wireshark功能强，覆盖的协议比较多，深受欢迎。

10. SQL注入测试工具排在前三位的：SQLInjector、SQL Power Injector、OWASP SQLiX， 三者比较接近，差距在6%左右。其它两项工具Pangolin、SQLSqueal也占了10%，而Antonio Parata、Blind SQL Injections、Bsqlbf-v2、Multiple DBMS Sql Injection、Sqlninja几乎没什么人用。

安全性测试工具很多，还包括黑客常用的一些工具，如暴力破解口令工具、端口扫描工具、防火墙渗透工具、渗透测试平台等。从某种意义看，它们超出软件范畴，更多属于网络空间安全、密码学等范畴，在此就不展开了。概括起来最受欢迎的软件安全性测试工具有：

开源软件安全性如何

本文仔细地研究了开源软件的开发与软件安全的联系。关于微软Windows与基于Linux的操作系统哪个更安全的讨论席卷了互联网。讨论涉及许多人的既得利益和偏袒的利益。由于了解不够以及逻辑错误引发的误解导致了讨论的混乱，使得讨论趋于白热化。出于广告宣传策略的需求希望能使赞助方获得更多的关注，派性论文使用整理过的统计数据泡制过于明显的权威及客观，实际上等于用偏见和可疑的事实来支持讨论。 这场缺乏确切结论的大讨论看似永无休止的部分原因就在于对安全的评估过多的集中于一个附带现象上：他们只研究安全性能的表面现象，而没有深入的分析安全特性的原因。部分原因也在于，对于大部分拥有产权的软件厂商来说，开源软件的开发是神秘的全新的。因此，这些非开源软件厂家无法了解开源世界对于安全问题在背后所做的努力。 还有一部分原因是许多卷入讨论的人们是只对软件安全有很肤浅的了解的最终用户。即使IT专家有时也不能了解软件安全在软件结构和开发过程中所做的努力，因为IT专家就算对 网络和系统安全配置拥有很深的了解，其技术中也往往比包括对开源软件开发和软件结构的实际了解。 如果想要填补公众知识库中关于软件安全带来的影响的空白，可能要写上厚厚的几大本材料。但是从这广泛的题目中选择有限的几个题目进行粗略的介绍还是可能的，这就是本文 的目的所在。 最后，Linux与Windows的安全大讨论成为了一场实例的竞赛。这些包含了更多更基础的关于安全所带来的种种利益与损害的例子分别服务于开源与闭源开发模式。这不仅仅是一个 技术问题，同时还是一个社会事件，如果更仔细的研究这场讨论，则更象一个经济学家和游戏理论家的事件。到现在为止，在大部分讨论中两种开发方式中最容易遭到误解的是开 源研发方式。现在我们来看开源软件的开发如何考虑软件安全问题。 不公开即安全 有些直指开源软件安全的争论完全基于错误的推论。许多流传广泛是听起来也颇有道理反对开源软件的的莫过于被我们称为“不公开即安全”的谬论。一个最常见的说法是：“当 它和微软程序一样流行时，你才会看到它有多安全”，另外一个则是“任何老练的安全黑客都能看到源代码，因此就不够安全”。 “不公开即安全”的谬论限制了对于基于Linux的操作系统和Mozilla Firefox 浏览器的相对安全性的讨论。实际情况是“不安全即公开”并不能真正保提供功能性的安全。它只能 提供表面上看起来的安全，实际上，开源开发社区所仰仗的安全原则正好与次相反。这种原则也可称为“公开即安全”，它包括两个软件安全的基本原则：透明的安全以及普及带 来的安全。 透明的安全 开源软件开发的安全性经常因为任何人都能得到源代码而遭到质疑。这个理论认为打算进行安全进攻的人通过对源代码的研究能够找到代码中能够构成攻击弱点的缺陷，从而使得 针对这些弱点的进攻更容易完成。这个理论有一定的根据，但是并不是人们所想象的那种方式。 事实上用眼睛分析源代码查找缺陷、进行分类并进一步创建缺陷是一项艰苦卓绝的工作。如果真的如同他们所说的那样由于源代码的公开性，开源软件更容易遭受攻击，那么微软 公司以外的人就不可能发现任何IE的缺陷。事实上，对于任何不平凡的应用来说，即使这样艰苦的工作也要比通过反工程技术查找缺陷来得容易。这些技术需要试探某个运行中的 应用，输入畸形的信息或者故意错误的使用，然后检查应用的可扩展性以及输出，来确定程序的运行是如何以及在何时背离了应用运行的初衷。 可能终有一天我们能够将源代码输入另外一个程序来判断哪个部分有缺陷，而不必再使用反工程技术来查找缺陷，不过即使那一天到来，使用二进制可执行设备代码文件可以同样 轻松的完成任务，根本用不着源代码本身。毕竟，进行那种分析所需的并不是类似编程员给变量或方法命名所需的信息，而是分析的目标软件所采用的算法的构造方法。毕竟，设 备代码本身与输入编译器的源代码在功能上是统一的。唯一的不同是它对特定的编程人员的可靠性有所不同。 从统计学上来看，这一事实不能支撑开源软件天生具有更多缺陷的说法。例如，代码分析企业Coverity的一份报告显示，他们只在Linux的内核的570万行语句中发现了985个bug。 可以比较的是，卡耐基梅隆大学的CyLab实验室所进行的的一个研究显示，具代表性的商业性闭源程序每一千行语句平均带有20-30个bug。按照这个比率计算，570万行语句中可能 带有的bug数量就会超过11.4万，是Linux内核bug数量的114倍。 软件透明度在开源软件开发过程中的重要作用经常被称为同行评审。之所有有这个过程，是因为源代码的公开状态，以及编程人员不可能与单一的控制实体，如CEO的目标完全保持 一致的事实所促成的，开发源代码的人员需要互相管理彼此的行动。因此很少出现，却非常激烈的关于不坏好意的程序员可能在程序中预留“后门”的论调在同行评审的过程下不 攻自破。严格而谨慎的遵守质量标准的代码才会得到开源软件项目代码库的接纳。事实上，如果程序在公开审查中被发现带有木马病毒，就会被指出。而源代码不公开的具有产权 的软件也可以，有时的确具有特意加入的rootkit功能，只有发生意外时才有可能被发现，例如2005年下半年著名的Sonyrootkit事件。普及带来的安全 微软公司的Windows桌面操作系统和IE的普及性常被用来解释缺陷发生率以及破坏发生率。这里我要告诉你们一些真相。对于源代码封闭，具有产权的操作系统或者网络浏览器来说 ，更高的普及率无疑可能招惹恶意代码编写者和其他不速之客的注意。但是如果采用全新的以普及性为关键的开发方式，情况就会有所改观。 开源软件采纳特定软件片段的门槛很低。由于开源软件完全不受价格的影响，在我们不断发展的网络状的世界里，一个新的操作系统安装文件的成本可能不会超过一张空白CDR，只 需花费几分钟进行下载。安装方式不同，甚至购买CD的钱也可以省去。 开源软件很容易被广泛接受的特性使得它更容易吸引新的开发者加入某个开源软件项目。随着用户数量的增加，编程人员对项目的兴趣也会增加。来自开源软件的开发者汇成了用 户群，另外开源软件很好的利用了编程人员的业务时间，他们没有时间全力投入某个严肃的开发团队，但是可以利用业务时间搜索和修改各个缺陷和bug。 结果，这些查找最受欢迎的开源软件缺陷和bug的人数远远大于闭源软件有限的开发队伍。这一数字随着用户数量的增加而相应增加。查找新的缺陷以进行利用的人数被查找新的缺 陷以进行修正的人数所超越。即使找到缺陷的人自己不写代码进行修复，他们也会告诉会进行修复的人。 这一事态的结果显而易见，有据可查的微软对缺陷所做的最快反应，是今年早些时候的WMF库的补丁，按照微软安全响应中心总监Debby Fry Wilson的说法，用了大约9-10天。同时 ， Mozilla基金会每次按期生产、测试和发布Mozilla Firefox网络浏览器的补丁的间隔不超过一星期，对于Linux内核的修补时间甚至不用天，而是用小时计算。 这主要归功于补丁测试广泛的群众基础：Debby Fry Wilson在讨论WMF补丁的快速发布时说，测试而非补丁的开发占用了很长一段时间。我们在闭源软件没有广泛测试能力的情况下 期望它能够跟上形势，以及在测试出现问题是经常收到来自测试者本身的传真是不合理的。开源开发社区拥有数千名测试者，而闭源软件只有几十位。 产权软件缺乏吸引力 产权软件厂商，如微软公司，也开始着手调查在工作过程中加入一些社会力量的可能性，希望这样可以增强他们的软件的安全性。他们发现碰了一些障碍，而且目前来看是无法克 服的。即使采用最大方的类似方法，如使公众能够看到源代码，或者为公众提供新版本和新补丁进行公开测试也无法达到开源软件所享受到的透明度。 原因很简单：用户群没有对软件本身进行相同的投入，软件是“别人的软件”，他们无法获得将来能从厂家获得回报的承诺。在软件开发和改进过程中投入的时间和精力完全归厂 家所有，因此极大的打击了积极性。 可见与隐藏的较量 开源开发社区所仰仗的软件安全哲学与闭源产权软件开发模式所使用的截然不同。隐藏源代码能够配合产权软件厂商将缺陷保守一定时间，以使编程人员有足够的时间开发补丁， 这样通过创立安全的形象保持了市场份额，可是这样经常导致在某个时间段中某个缺陷横行，而用户对他们所处危险状况一无所知。开源软件开发因透明而获得好处，而不是粉饰 可能发生的安全损失，直到有了补丁以后才为用户提供保护自己的武器。这些好处是产权软件无法完全获得的。