我们是否已足够成熟，可以迎接《开源软件安全动员计划》？

在当前的经济环境和威胁形势下，我确实不羡慕普通的首席信息安全官（CISO）。他们肩负着交付安全、合规、创新和商业价值的重任，同时还要面对预算缩减和审查加强带来的严峻挑战。更紧迫的问题在于，每个组织（及其各自的开发团队）的安全成熟度各不相同，并非所有组织都有能力在网络防御方面做到最好。

过去几年网络安全事件的不断升级，使得安全领导者很难领先一步。仅从一些数据驱动的洞察中，就能看出我们日益严峻的困境犹如火药桶：仅在 2023 年，就有超过 330 亿条记录被网络犯罪分子窃取，比 2018 年增加了 175%。预计到 2025 年，网络犯罪的成本将达到 10.5 万亿美元，而数据泄露的平均成本已飙升至 424 万美元（尽管我们只需看看 Equifax 或 Solar Winds 等事件，就会发现情况可能糟糕得多）。

作为一个行业，我们等待英雄出现并拯救我们免受网络安全威胁已经太久了，这些威胁似乎比我们十年前想象的还要强大。我们一直在等待更多的网络安全专业人员加入，将我们的安全计划提升到更高的标准，但这却是一个我们无法弥补的缺口。我们一直在等待那种承诺能通过自动化消除日益增长的风险的“银弹”工具，但它并不存在，而且极不可能存在。我们一直在等待我们的“卢克·天行者”来帮助我们对抗黑暗面。

事实证明，援助（和希望）正在路上，那就是《开源软件安全动员计划》。然而，我们都需要审视并诚实地评估：我们的组织是否已足够成熟，我们的开发团队是否具备了相应的安全意识和技能，以实施这些最新且最强大的防御策略，尤其是当这些策略需要开发团队的支持和执行时。

什么是《开源软件安全动员计划》？

这项十点计划由开源软件基金会（OpenSSF）和 Linux 基金会牵头，联合白宫官员、顶级首席信息安全官以及来自 37 家私营科技公司的其他高级领导人共同制定。随着在行动和资金方面的共同支持，开源软件的安全标准有望得到显著加强。

特别值得关注的是，他们专注于开发者层面的基础教育和认证，以及旨在简化内部软件物料清单（SBOM）活动的措施。这些措施在实施时往往难以产生持久的影响，这部分归因于组织安全计划在成长过程中的阵痛，以及开发人员群体普遍缺乏安全成熟度——这并非他们的过错。他们身处一个高压环境，在面对日益不合理的截止日期时，代码交付的速度和数量才是重中之重。在不增加可用时间的情况下，增加安全要求和 SBOM 维护等任务，无异于在开始之前就注定了失败，遗憾的是，这种情况比我们预想的更为普遍。

那么，让我们深入了解一下其内部机制。

开发者安全认证：我们准备好了吗？

如果我们确定一件事，那就是具备安全技能的开发者仍然是稀缺资源。造成这种情况的原因有很多，主要是因为直到最近，开发者在组织内部的软件安全策略中还未被纳入考量。再加上开发者缺乏优先考虑安全的动力（他们的培训不足或根本没有，这会耗费更多时间，且不属于他们的关键绩效指标（KPI），他们的首要任务是做好本职工作：构建功能），导致开发团队在代码层面处理安全问题时准备不足，也无法在现代化、以 DevSecOps 为中心的软件开发生命周期（SDLC）中发挥应有的作用。

如果我们审视《开源软件安全动员计划》，其十点计划的第一个方向就是解决开发者安全技能问题，即“为所有人提供基础安全软件开发教育和认证”，这对建立开发团队的安全成熟度至关重要。他们强调了我们讨论已久的问题，包括安全编码在大多数高等教育软件工程课程中缺失的事实。看到这一点得到能够改变行业现状的个人和部门的支持，令人倍感鼓舞。考虑到全球 99% 的软件至少包含一些开源代码，这一开发领域正是专注于开发者安全培训的绝佳起点。

该计划引用了备受推崇的资源，如OpenSSF 安全软件基础课程，以及来自OWASP 基金会长期且广泛的资源。这些信息中心非常宝贵。为提升开发者技能而提出的推广方案，涉及汇集公共和私营部门的广泛合作伙伴网络，并与教育机构合作，将开源安全开发作为课程的核心内容。

至于如何赢得全球软件工程师的心，其中许多人一直被灌输“安全不是他们的工作或优先事项”的观念，该计划详细制定了一项奖励和认可策略，旨在针对维护开源库的开发者以及需要看到安全认证价值的在职工程师。

我们从经验中得知，开发者对激励措施反应良好，而且在学习环境中，展示进度和技能的分级徽章系统，其效果与 Steam 或 Xbox 等平台上的成就系统一样有效。

然而，令人担忧的是，我们并未解决核心问题之一，即如何在组织的安全计划中交付学习模块。在我的职业生涯中，我与开发者密切合作，深知他们对工具和培训持怀疑态度，更不用说任何可能干扰他们首要工作的事情了。开发者赋能需要他们持续参与课程材料的学习，而要取得成功，这些内容必须在他们日常工作的背景下具有实际意义。

如果我们参考像软件保障成熟度模型（SAMM）这样成熟的模型，“教育与指导”是治理层的核心组成部分，其中重点关注开发者教育。该模型整体非常庞大，在达到更高成熟度水平的过程中有循序渐进的步骤。然而，初始阶段仅建议为开发者提供 1-2 天的正式培训，这几乎无法触及安全意识的皮毛。即便如此，企业战略集团（ESG）的一份最新报告显示，只有不到一半的组织要求开发者每年参加一次以上的正式安全培训。我们与 Evans Data 联合开展的研究显示，只有 29% 的开发者认为应优先考虑编写无漏洞代码的实践。教育的交付方式与接收方式之间，以及它在提升安全成熟度方面的实际效用之间，存在明显的脱节，尤其是当开发者看不到其价值时。

软件物料清单：该计划能否打破采用障碍？

该计划旨在解决的另一个领域是软件物料清单（SBOM）创建和维护过程中常见的混乱状况。“SBOM 无处不在——改进 SBOM 工具与培训以推动普及”这一工作流，正致力于探索如何让开发人员及其所在组织更轻松地创建、更新和使用 SBOM，从而实现更好的安全成果。

目前，SBOM 在大多数垂直行业中尚未得到广泛应用，这使得其在降低安全风险方面的潜力难以发挥。该计划制定了一项出色的策略，旨在确立 SBOM 编制的关键标准，并提供符合开发人员工作习惯的便捷创建工具。仅凭这些，就能极大地减轻开发人员的负担，让他们无需在应对快节奏软件交付的同时，还要为繁琐的软件开发生命周期（SDLC）任务分心。

然而，我担心的是，在普通组织中，安全责任对开发人员来说往往是一个模糊地带。谁该为安全负责？归根结底是安全团队，但如果我们希望获得开发人员的协助，就必须让他们参与进来。任务和期望需要明确界定，同时必须给予他们时间来承担这些额外的成功衡量指标。

从开源软件（OSS）到整个软件世界

《开源软件安全动员计划》雄心勃勃、大胆果敢，正是推动开发人员承担安全责任所必需的举措。虽然这需要一群强大的参与者组成“义军同盟”共同努力，但这证明了我们正朝着正确的方向前进，并摒弃了网络安全技能缺口会自动填补的幻想。

这是我们的新希望，需要我们所有人共同努力，将这一架构从开源软件领域推广开来。然而，安全专业人员必须审视自身，分析他们负责保护的代码开发团队。他们必须诚实地评估当前的各项能力及存在的差距，并致力于构建一个严密、主动且包容的成熟体系，为开发人员传授真正的安全技能。除非他们得到切实有效的赋能，否则我们在应对代码级漏洞的方法上可能仍会显得不够成熟。

‍

>> 通过我们的实操互动 XSS 挑战来测试您团队的安全成熟度！