由于许多组织最初关注的是扫描和分析应用程序代码和基础设施以获取安全洞察力的机制，结果通常是一种反模式，其中一组复杂的重叠和松散集成的工具跨越开发和生产实际上阻碍了工程团队从解决开发过程中的安全问题。而且由于传统的安全工具是为静态环境构建的，考虑到云原生应用程序开发的动态和快速发展的性质，它们的效率通常不是太高。
尽管云原生架构使组织能够构建和运行可扩展的动态应用程序，但它并非没有挑战。根据云安全联盟 (CSA) 的说法，70% 的安全专业人员和工程团队都在努力“左移”，其中许多人无法识别反模式的形成，也无法理解云原生的开发、成本、治理、文化理念等。
认识到范式转变
正如在 CNCF 年度报告的细分中所讨论的，55% 的受访者每周或更频繁地发布代码，18% 每天多次发布代码。微服务的持续采用和实施越来越多地挑战组织——以及遗留应用程序安全工具—— 在整个开发过程中跟踪软件漏洞。实施 DevSecOps的工程团队实践和自动化安全工具将更早发现安全风险，节省开发人员时间，加快发布周期，并交付更安全和合规的代码。
此外，安全事件（例如数据泄露、零日漏洞和隐私侵犯）对业务的影响只会继续增长，这使得组织绝对有必要确保安全性成为数字化转型和云原生应用程序开发的关键部分。无论您是 Solar Winds、Zoom 还是受数据泄露影响的众多其他公司中的任何一家，风险都很高，后果从失去客户到破产不等。在美国，平均数据泄露给企业造成 905 万美元的损失， Log4j 零日漏洞正在影响数亿个应用程序和设备， 数据隐私法规导致罚款 8.88 亿美元（美元）. 组织（从字面上）不能再忽视云原生开发引入的不断发展的威胁动态。
使开发人员具有安全意识
开发人员知道如何构建应用程序...... 但他们需要正确的工具、洞察力、流程和 文化 来安全地构建它们。不幸的是，确保工程团队承担安全开发的额外责任是实施 DevSecOps 最具挑战性和最关键的部分之一。根据 SANS 2022 DevSecOps 调查：创建一种文化以显着改善组织的安全态势，管理层支持是促成 DevSecOps 安全计划成功的首要因素。组织需要一种结构化的方法，让领导者参与进来、动员安全拥护者，并确保“安全”成为“完成的定义”不可或缺的一部分。
此外，通过确保工程、安全和运营之间的一致性，鼓励开发人员“提高技能”，并专注于学习和实施有助于提高 Web 应用程序安全性的技术，更重要的是，使团队能够更早地转移安全性进入设计和编码阶段。例如， OWASP 云原生应用安全 Top 10 提供有关云原生应用程序最突出的安全风险、所涉及的挑战以及如何克服这些风险的信息。OWASP Top 10 鼓励将安全性集成到 CI/CD 管道、参数化查询、验证所有输入、实施错误处理、改进日志记录策略、利用安全框架的优势、保护静态数据和加密、减少敏感数据暴露等准则，实施安全访问控制等
全面、优先和可行的见解
由于许多原因——速度和灵活性，最显着的是——软件开发的发展已经远远超出了单个开发人员从头开始编写代码的贡献。虽然从现有库中组装应用程序并使用自定义代码将它们连接在一起的做法很常见，但这并非完全没有风险。
- 全球 95% 以上的 IT 组织在任务关键型 IT 工作负载中使用开源软件 (OSS)。
- 2021 年，软件供应链攻击增长了 300% 以上。
- 每年在开源和第三方代码中发现超过 20,000 个常见漏洞和暴露 (CVE)。
正如开发人员安全平台的 5 大评估标准中所讨论的 ，
- Cloud Native Instrumentation：提供深入了解应用程序运行时的工具，是非侵入式的，并且在云原生应用程序中可以很好地扩展
- 优先和全面的安全洞察：提供应用程序感知的上下文信息，例如跨越应用程序代码、依赖项、容器映像和 Web 界面的使用信息和堆栈跟踪
- 开发人员教育：为开发人员提供及时的、上下文相关的和可操作的安全见解
- CI/CD 集成和开发人员体验：将安全性和合规性测试无缝集成并自动化到 CI/CD 管道中了解安全对合规性的影响：通过满足合规性目标确保客户数据的安全和隐私
越来越多地使用开源软件——结合成熟的 DevOps 管道提供的敏捷性和灵活性——继续突出开发速度超过安全性的领域。出于这个原因，工程团队应该评估可以观察正在运行的应用程序的工具，以便为开发人员提供上下文相关的应用程序感知信息。这可能包括使用信息、堆栈跟踪以及涵盖应用程序代码、依赖项、容器镜像和 Web 界面的全面见解。跨应用程序组件的漏洞和不安全代码的识别和关联可以支持工程团队通过帮助开发人员发现、确定优先级和补救最关键的安全风险来防止警报疲劳。
自动化安全测试
当大多数工程团队考虑采用 DevSecOps 时，跨开发和运营无缝集成和自动化安全性的能力是一项必备功能。然而，许多传统的应用程序安全工具专注于通过耗时的“门”或检查点提供反馈，给开发人员带来了开销和摩擦。（顺便说一句，这是反模式的一个很好的例子！）摆脱这种模式实际上代表了安全团队的重大转变，安全团队习惯于强迫开发人员遵守他们的流程和工具。
然而，通过强调直接集成到现有 CI/CD 工作流和工具链中的技术和支持系统，目标应该是在开发和测试期间“自动”观察正在运行的应用程序的行为，以提供安全洞察力，而不需要工程团队浪费宝贵的资源开发时间上下文切换。事实上，回到之前的挑战，确保每个功能测试都成为安全测试有助于将 DevOps 的“你构建它，你运行它”的理念扩展到发现、解决安全漏洞。
引用
- https://www.deepfactor.io/learn-how-to-evaluate-developer-security-platforms/
- https://www.cncf.io/wp-content/uploads/2020/12/CNCF_Survey_Report_2020.pdf
- https://www.sans.org/cyber-security-courses/cloud-security-devsecops-automation/
- https://www.ibm.com/reports/data-breach
- https://www.deepfactor.io/log4j-vulnerability-the-latest-information-your-software-developers-need-to-know-about-log4shell/
- https://www.deepfactor.io/log4j-vulnerability-the-latest-information-your-software-developers-need-to-know-about-log4shell/
