自2009年被首次提出以来,DevOps所涵盖的内容已经发生过多次迭代,尽管不少企业坚称自己以DevOps为中心,但却几乎没多少人能真正准确理解其含义。没有正确实践作为前提,DevOps给团队及企业做带来的价值也将无从谈起。
在全面普及之后,DevOps能够加快部署速度、降低故障率并增强恢复能力。而这一切都将帮助团队乃至企业打造出周期更短、适应性更强、质量更好的产品。但这也给我们提出了新的问题——如何把安全考量融入进去?
DevOps与DevSecOps有什么区别?
敏捷框架、一次构建/随处运行的开发方法、一切即代码、自动化、沟通与协作,是DevOps的五大核心组件。而DevSecOps的重点,在于以符合安全要求的方式扩展DevOps核心组件。通过拆分,我们能够审视在哪里适合插入安全要素,从而实现软件的安全性。
敏捷框架——敏捷方法是当今软件开发生命周期(SDLC)的主要内容。与瀑布式开发方法相反,敏捷开发更强调短周期加小变化的组合,确保企业能够针对客户反馈做出快速反应。敏捷框架在加快开发周期方面确实表现不错,但却又常常受制于运营与安全要求。开发人员希望将运营与安全工作交给支持性工具负责,自己则专注于提升开发人员的行动速度。
总而言之,敏捷框架在提升运营效率方面,取得了不错的效果;但其中的重点只有开发本身,一切运营与安全元素都成为事后才考虑的元素。
一次构建、随处运行——容器技术让SDLC更上一层楼。作为一项真正具有颠覆性的技术,容器使得开发人员能够独立于运营资源之外进行编码、构建、运行以及测试。如今,由于开发人员不必分神设置运营环境,他们可以将更多精力集中在测试、安全与扩展方面。利用容器技术,一切都可由Dockerfile所容纳并实现随处运行。在提交最终镜像之前,开发人员根本不需要接触运营工作;但在整个过程中,运营仍然始终存在、在不知不觉中为开发者提供支持。
虽然存在这种开发与运营之间的隔绝,容器本身仍然是一项重大成就,而容器的起效又离不开编排工具的引导,例如Kubernetes。Kubernetes使企业得以高效管理、扩展、观察并接入容器。它将Dockerfile的需求抽象为可以管理及扩展的明确对象。这种声明式抽象要求开发人员与运营人员开展沟通,进而有效运用Kubernetes。随着时间推移,双方的交流将逐渐升级、最终将安全问题纳入进来。
自动化——通过在不影响开发速度的情况下,向开发人员提供直接反馈,自动化成为实现DevSecOps的关键所在。单元测试、代码分析与镜像扫描已经成为可轻松被添加至持续集成(CI)管道的常见工具,即时向开发人员通报必要修改。在开发团队的协作下,这些变更可以快速被集成至现有管道当中。运营与安全团队应该明白,他们越早提供自动化反馈机制,开发人员就能越早适应这种新的协作模式。
借助新的工具与最佳实践,安全团队可以为开发人员提供稳定且安全的基础镜像,由此不断提升代码质量。安全团队还可以在管道中引入自动检查机制,监控一切包含权限提升行为的YAML文件、未匹配网络策略的命名空间或者存在漏洞及风险的容器镜像。
一切即代码——Kubernetes及其他编程语言的声明性质,极大提高了基础设施与应用程序的可重用性与可理解性。YAML文件将帮助各团队准确理解容器如何才能发挥预期作用。时钟时间、卷挂载以及secret注入等一切行为都可通过这个文件及注释进行观察。这种方法还让代码成功呈现为文档的形式,以供随时进行版本控制并实现迭代变更。
但即使有了最新、最好的工具,如果无法正确记录和编目具体问题,一切努力仍然可能是徒劳的。没有清晰的文档,将很难跨团队分享经验教训。而在尝试新的管道配置时,各团队掌握的经验教训很可能对其他团队有着决定性的指导作用。因此,请使用代码与版本控制系统充分展示变更内容,并允许各方据此开展讨论。否则随着单一团队的快速推进,知识共享体系将土崩瓦解,各团队间再难开展充分交流。
沟通与协作——如果团队和个人间不进行充分沟通,那么一切代码、应用程序与安全变更都将毫无意义。而IT部门中最常忽视的一大沟通要点,在于对意图的明确解释。
DevOps与DevSecOps之所以难以发挥其全部潜力,一大核心原因就是相关行动的意图往往未被各方正确理解。安全团队并不是要阻碍开发工作,他们只是在完成自己的本职工作并保证应用程序安全。而开发团队虽然也关心安全性,但他们面前的头号难题永远是如何在限期之内让新功能顺利上线。
企业必须努力弥合各团队之间的差距,专注于吸取教训,鼓励合理的尝试失败,并设定出切合实际的后续目标。从文化角度来看,这种变化通常由高层自上而下推动。在重视这种方法的企业当中,开发、运营及安全团队会乐于讨论哪些意图较合理、哪些不合理,并愿意站在对方的立场上考虑问题。
DevSecOps将向何处去?
总而言之,DevSecOps向我们提出了以下几项重点要求:
• 要求在快速迭代的软件开发生命周期中建立嵌入式自动安全检查机制
• 可重用的各开发环境间具有同类型的安全控制机制
• 版本控制CI管道
• 以组织或团队职能范围为边界进行管道变更,借此改善事件后的安全调查流程
• 完善的说明文档,最好以声明式方法实现安全即代码
• 鼓励创新,并接纳由此带来的失败文化
DevSecOps代表的是一种文化变革,其背后代表的思维方式转变不限于任何特定工具。当然,大家也应尽可能采用支持协作解决问题的工具,包括保证其具有良好的可移植性、可观察性并提供简单易懂的说明文档。最重要的,还有获得团队的支配以建立起可跨团队共享的上下文素材。
结合种种成功案例与理论层面的巨大潜能,相信DevSecOps这波不断发展的浪潮终将成为我们手中的有力武器。
好文章,需要你的鼓励
这项研究针对现代文档检索系统中的关键缺陷:独立处理文档片段导致丢失上下文信息。研究团队开发了ConTEB基准测试来评估模型利用文档级上下文的能力,并提出了InSeNT方法,结合后期分块和创新的对比学习策略。实验表明,上下文感知嵌入显著提升检索性能,尤其在处理非自包含文本片段时,同时保持计算效率,对分块策略更具鲁棒性,并且在语料库规模扩大时表现更佳。这一研究为更智能的文档检索系统铺平了道路。
这项由布朗大学和Cohere实验室研究者联合进行的研究全面分析了大型语言模型(LLM)安全研究中的语言不平等现象。通过系统回顾近300篇2020-2024年间的安全相关论文,研究发现LLM安全研究严重偏向英语,即使中文这样的高资源语言也仅获得英语十分之一的研究关注,且这一差距正在扩大。研究还揭示非英语语言很少作为独立研究对象,且英语安全研究常忽略语言覆盖文档化。为解决这一问题,研究者提出了三个未来方向:开发文化敏感的评估基准、创建多语言安全训练数据,以及深入理解跨语言安全泛化挑战。
这项研究提出了ChARM,一种创新的角色扮演AI奖励建模框架,通过行为自适应边界和自我进化策略大幅提升AI角色的真实性和一致性。研究团队创建了包含1,108个角色的RoleplayPref数据集,实验表明ChARM比传统模型提高了13%的偏好排名准确率,应用于DPO技术后在多项基准测试中达到了领先水平。这一突破将为娱乐、教育和心理健康支持等领域带来更加自然、个性化的AI互动体验。
这篇研究重新审视了循环神经网络中的双线性状态转换机制,挑战了传统观点。高通AI研究团队证明,隐藏单元不仅是被动记忆存储,更是网络计算的积极参与者。研究建立了一个从实数对角线到完全双线性的模型层级,对应不同复杂度的状态跟踪任务。实验表明,双线性RNN能有效学习各种状态跟踪任务,甚至只需极少量训练数据。研究还发现,纯乘法交互比加法交互更有利于状态跟踪,为循环网络设计提供了新视角。