对于软件开发来说，应用程序的安全性是最为重要的。随着企业 DevOps 的实践及相关工具的出现，企业软件的开发周期越来越短，对数据安全性的要求性也越来越高，在这种情况下，如何才能维持很好的应用程序安全性呢？应用程序的安全性又该由谁来负责呢？
为了搞清楚上述问题，WhiteSource 对 600 多名软件开发人员进行了调查，调查内容包括企业内应用程序安全职责的划分，测试安全性的时机以及在面对安全性挑战时采取的措施等等。
应用程序安全，谁来背锅？在我们以前的认知里，如果应用程序发生安全问题，那自然是要负责安全的专业人员背锅，因为开发人员负责设计和构建产品，而安全专家则是专为安全而生，负责审核、标记、补救安全问题。但是随着技术的不断发展，之前划分明确的安全界限正在变得越来越模糊，在 WhiteSource 最新的调查中，71% 的受访者表示几乎参与软件开发的所有人员都应该为安全负责，例如 DevOps 团队、安全团队、开发团队，甚至是开发者自己。
为什么开发人员也要为应用程序安全负责呢？因为如果是在软件开发的早期就修复安全漏洞，那么就可以显著降低所需的成本和工作量，不仅提高了灵活性，还能一次性生成安全性更高的应用程序。
当这么多人都参与到应用程序的安全工作中，该如何分配工作呢？比较好的一种方式是，开发人员负责监控和处理日常的安全工作，而安全人员从更高的维度把控安全问题，例如建立更好的安全流程。
（蓝色代表 DevOps、橘色代表 Developers、黄色代表 Team leaders in software development teams、紫色代表 Security teams）
不同规模的企业应该制定不同的安全规则，如果是比较小的企业或组织可以更灵活地定义安全流程。不过，所有类型的企业都应该慢慢把安全的责任慢慢向开发团队转移。
如何才能避免应用程序发生安全问题？如何才能避免应用程序发生安全问题？首先，要在应用程序设计之初就把安全性考虑在内。在 WhiteSource 的调查中，只有 55% 的企业或团队会在软件开发时把安全性放在首要位置，14% 的受访者只有在发生问题时才会考虑安全性，更有 3% 的受访者因为担心会拖慢开发进度，完全不考虑安全性。
之前，软件开发大多采用瀑布开发模式，只有在软件发布之前才会进行安全审核，但是现在采用 DevOps，我们可以在更早期的时候就测试安全漏洞，避免在软件发布时才会出现问题。
到底在什么时候开发人员进行安全测试是最合适的呢？在 WhiteSource 的调查中，36% 的受访者是在软件构建之前开始进行安全测试，30% 的受访者是在软件构建时进行安全测试，还有 34% 的受访者是在后期建设时进行安全建设。
在软件构建之前就实施安全测试工作，这就代表着企业已经在有意识的转移安全工作，他们希望在问题修复时能够更容易、更快地找到问题所在。
另外，在调查中，WhiteSource 还发现对开源组件依赖性比较大的公司与在应用程序构建之前实施安全测试工作的公司之间具有强关联性。
为了更好更快地检测和修复应用程序的安全问题，企业往往会在此方面投入很多。在 WhiteSource 的调查中，只有 20% 的受访者表示公司完全不提供任何安全培训，剩余的受访者公司都会或多或少地为他们提供安全培训。
除此之外，开发人员还需要掌握一系列应用程序安全测试（AST）技术。调查中，68％受访者表示已掌握、使用以下至少一种技术：SAST、DAST、SCA、IAST 和 RASP。如果集成了自动化应用程序安全测试工具，那么当发生安全警报时，相关人员就可以立即收到报警，第一时间处理相关问题。
由于开源软件的流行，很多企业 IT 架构中都会使用开源软件，这是开源组件的安全性就成为了我们关注的问题。根据调查，34% 的开发人员会通过自动化软件组合分析工具来实时检测具有已知漏洞的开源组件。不过，这些 SCA 工具大多是开源工具，针对不同应用程序的安全性和提供给 DevOps 参与者的功能都很有限，目前这些工具已基本融入了开发人员现有的工作流。
当应用程序中检测到了易受攻击的开源组件该怎么办呢？调查中，排在前三位的解决方法分别是向安全团队、DevOps 或是上级报告该情况（25%）、查找该开源软件易受攻击的部分（23%）、根据项目组长提出的办法进行补救（20%）。
原报告地址：
https://www.whitesourcesoftware.com/developers-security-report/
活动推荐
随着互联网数据量的变大，运维业务的多样化和复杂化，以及对运维服务质量要求的提高（比如低成本，低延迟，高防范），很多传统的运维技术和解决方案已经不能满足当前运维所需。另一方面，机器学习（ML）和 人工智能（AI）技术的飞速发展，推生了智能运维 AIOps （Artificial Intelligence for IT Operations），这是运维未来的必然趋势。
