介绍
表彰我们致力于帮助英国成为一个安全的经商之地, 我们将发布一个常规的“CSP学院”作品.
在第一个系列中，我们将在接下来几周的三篇文章中讨论软件材料清单(soms), 解释它们的功能, 好处, 以及它们所解决的风险. 今天的文章解释了软件供应链的安全问题.
软件供应链中的依赖关系
作为确保供应链安全的一部分，重要的是要考虑您使用的软件. 它可能不像交付产品或服务所需的任何物理组件那样明显是供应链的一部分, 但它仍然增加了风险.
一个风险是漏洞或恶意软件存在于(或引入)您所依赖的代码中. 他们可能从一开始就在场, but unknown; they might have been there, known about but not yet fixed; they might have been introduced as the result of a change.
- 漏洞是软件中留下安全漏洞的缺陷. 攻击者可能会利用这个安全漏洞来访问您的系统.
- 恶意软件是有意引入的，目的是加密或窃取您的数据, 控制你的系统, 或者让它不可用.
例如, you may have heard about the Log4j problem; a significant computer vulnerability was found in a component of Log4j, 叫Log4shell. Log4j是全世界数百万台计算机使用的开源(意味着免费使用)代码，而这个漏洞意味着，直到它们被更新, 所有这些电脑都容易受到攻击.
另一个风险是代码组件的创建者可能会停止更新它. 随着代码的老化，可能会出现新的安全问题，从而增加漏洞.
作为旁注:另一种风险是授权. 如果您使用的是开源软件组件(几乎所有组织都是)，那么可能会要求任何生成的软件也是开源的. 了解您正在使用的组件(即使是间接使用的组件)将帮助您了解这是否是一个问题. This will depend on any requirements that the creator put on the code; you should consult a legal expert.
软件供应链安全旨在确保软件在开发过程中的任何阶段都不会受到损害. 在这个简短的系列中，我们将关注:
- 对软件供应链中一些安全问题的描述
- 软件物料清单(SBOM)如何帮助您识别软件包中的内容
- VDR(漏洞披露报告)或VEX(漏洞可利用性交换)如何帮助您确定代码中是否存在可能导致业务问题的漏洞.
等等:首先解释一下我们所说的脆弱性是什么意思
设计和编码软件是困难的. 在软件的设计方式中，很容易无意中引入缺陷, 或者是编码方式上的缺陷. 由于对应该保密的信息管理不善，可能会产生额外的安全问题, 或者在开发过程中受到薄弱的访问控制.
不管是什么原因, 漏洞是软件中的一个缺陷，它可能允许攻击者进入系统窃取数据, 安装恶意软件, 或者从那个系统转移到更广泛的网络中, 并在其他地方造成进一步的问题.
开发人员可以在开发和测试期间使用最佳实践来减少此类问题的风险, 但是应用程序代码可能非常复杂，并且涉及很多, 很多行代码. Windows 11, 例如, 据估计，Facebook需要运行6200万行代码，而Facebook需要运行6000万至1亿行代码. 而“代码行数”并不是一个计算的好方法, 它确实让你对创建软件所涉及的工作量有了一个概念.
漏洞, 然后, 是不可避免的,, 作为旁注, 这就是为什么我们建议保持您所有的软件是最新的, 因为这些更新可能包含修补其中一些缺陷的“补丁”.
问题:意外的依赖关系意味着额外的风险
让我们从一个例子开始.
假设你准备根据一本新的食谱书做一顿饭, 却发现每个配方都指向另一个. 你读得越多, 它变得越复杂，对组件的全面理解就越重要, 特别是如果你是在迎合过敏者. 请看下图:如果有人对营养酵母过敏, 不知道它是香料混合物的一种成分，因此也是肉汤的一种成分，但在汤的配方中没有提到，可能会导致问题.
软件包也是如此.
软件很少是完全从零开始编写的. 一个软件包通常包括多个预先编写的代码片段，在需要时调用它们来完成特定的任务. 这些代码可能是由您自己的开发人员编写的，但更有可能来自开源库:任何人都可以免费使用的代码.
这是, 整体, 这是一件好事:它减少了返工，并通过避免重新发明轮子来加快交付. 开发人员通常包含预先编写的代码“块”库，以便于重用.
然而, 组件网络可以很快变得非常复杂, 网络安全风险随着复杂性的增加而扩大.
见上图:结果代码包(C)的一些组件是内部的, 有些是外部的. 有些组件在不同的地方被调用多次. 如果没有正确地记录，更改一个元素可能会产生意想不到的效果，并可能影响调用该组件的所有软件.
依赖关系很重要:知道包包含什么是很重要的, 这样你就可以测试它了, 维护它, 确保安全.
任何地方的代码更改(A -外部), 在图, 或B - internal)可能会影响最终的代码包, C. 如果你知道做了什么改变，那就没问题, 这对C有什么影响, 并且能够减轻变更可能引起的任何问题.
你能做什么??
如果你有自己的开发团队，你可以适当地控制，例如:
- 只使用一组预定义的库
- 记录正在使用的组件
- 在下载时验证源代码
- 确保代码经过测试
- 确保这些库中不必要的组件被最小化
- 确保代码保持最新(这被称为打补丁)
- 及时了解有关这些组件的任何安全问题或更新的最新消息.
如果你没有一个内部的开发团队, 您正在依赖其他人在其软件开发中实现安全措施.
本文概述的问题的关键是理解在任何给定的软件包中使用了哪些代码组件. 在下一篇文章中, 我们将讨论soms(软件材料清单), 哪些旨在提供软件包中组件的信息.
