介绍
In recognition of our commitment to help make the UK a safe place to do business, 我们将发布一个常规的“CSP学院”作品.
In this first series we are going to discuss Software Bills of Material (or SBOMs) in three posts over the next few weeks, 解释它们的功能, 好处, 以及它们所解决的风险. 今天的文章解释了软件供应链的安全问题.
软件供应链中的依赖关系
As part of securing your supply chain, it’s important to think about the software that you use. It may not be as obvious a part of your supply chain as any physical components that you need to deliver your products or services, 但它仍然增加了风险.
One risk is that vulnerabilities or malware are present in (or introduced into) the code that you depend on. 他们可能从一开始就在场, but unknown; they might have been there, known about but not yet fixed; they might have been introduced as the result of a change.
- 漏洞是软件中留下安全漏洞的缺陷. Attackers may be able to exploit this security weakness to gain access to your system.
- Malware is intentionally introduced and aims (among other things) to encrypt or steal your data, 控制你的系统, 或者让它不可用.
例如, you may have heard about the Log4j problem; a significant computer vulnerability was found in a component of Log4j, 叫Log4shell. Log4j is open-source (meaning free to use) code used by millions of computers worldwide—and the vulnerability meant that until they were updated, 所有这些电脑都容易受到攻击.
Another risk is that the creator of the code component may stop updating it. 随着代码的老化，可能会出现新的安全问题，从而增加漏洞.
作为旁注:另一种风险是授权. If you are using open-source software components (and almost all organisations are) there may be a requirement that any resulting software is also open source. Knowing the components that you are using—even if used indirectly—will help you understand whether this is an issue. This will depend on any requirements that the creator put on the code; you should consult a legal expert.
Software supply chain security is intended to ensure that software is not compromised at any stage during development. 在这个简短的系列中，我们将关注:
- 对软件供应链中一些安全问题的描述
- How a software bill of materials (an SBOM) helps you identify what is in a software package
- How a VDR (vulnerability disclosure report) or a VEX (which stands for vulnerability exploitability exchange) can help you identify if there are vulnerabilities in that code that might cause a problem for your business.
等等:首先解释一下我们所说的脆弱性是什么意思
设计和编码软件是困难的. It’s easy to unintentionally introduce flaws in the way that the software is designed, 或者是编码方式上的缺陷. Additional security problems can be created by poor management of information that should be kept secret, 或者在开发过程中受到薄弱的访问控制.
不管是什么原因, a vulnerability is a flaw in the software that could allow an attacker to gain access to the system to steal data, 安装恶意软件, 或者从那个系统转移到更广泛的网络中, 并在其他地方造成进一步的问题.
Developers can use best practices during development and testing to reduce the risk of such issues, 但是应用程序代码可能非常复杂，并且涉及很多, 很多行代码. Windows 11, 例如, is estimated to run on 60-100 million lines of code and Facebook is said to run on 62 million. 而“代码行数”并不是一个计算的好方法, it does give you an idea of the scale of effort involved in creating software.
漏洞, 然后, 是不可避免的,, 作为旁注, 这就是为什么我们建议保持您所有的软件是最新的, as those updates are likely to contain ‘patches’ to mend some of those defects.
问题:意外的依赖关系意味着额外的风险
让我们从一个例子开始.
假设你准备根据一本新的食谱书做一顿饭, 却发现每个配方都指向另一个. 你读得越多, the more complicated it becomes—and the more important it is to get a complete understanding of the components, 特别是如果你是在迎合过敏者. 请看下图:如果有人对营养酵母过敏, not knowing that it is a component of the spice blend and therefore also of the broth but not mentioned in the soup recipe could cause a problem.
软件包也是如此.
软件很少是完全从零开始编写的. A software package typically includes multiple pre-written pieces of code which are called on to do specific tasks when needed. These might be written by your own developers but are more likely to be from open-source libraries: code freely available for anyone to use.
这是, 整体, a good thing: it reduces rework and speeds up delivery by avoiding reinventing the wheel. Developers typically include libraries of pre-written code ‘chunks’ for easy reuse.
然而, 组件网络可以很快变得非常复杂, 网络安全风险随着复杂性的增加而扩大.
See the image above: some components of the resulting code package (C) are internal, 有些是外部的. 有些组件在不同的地方被调用多次. Changing one element can have unexpected effects if not properly documented and can affect all software that calls that component.
依赖关系很重要:知道包包含什么是很重要的, 这样你就可以测试它了, 维护它, 确保安全.
任何地方的代码更改(A -外部), 在图, 或B - internal)可能会影响最终的代码包, C. 如果你知道做了什么改变，那就没问题, 这对C有什么影响, 并且能够减轻变更可能引起的任何问题.
你能做什么??
If you have your own team of developers, you can put controls in place, such as:
- 只使用一组预定义的库
- 记录正在使用的组件
- 在下载时验证源代码
- 确保代码经过测试
- 确保这些库中不必要的组件被最小化
- 确保代码保持最新(这被称为打补丁)
- keeping up to date with news about any security issues or updates for these components.
如果你没有一个内部的开发团队, you are relying on someone else to implement security measures in the development of their software.
The key to the issues outlined in this post is understanding what code components are being used in any given software package. 在下一篇文章中, 我们将讨论soms(软件材料清单), which are intended to provide information about the components in a software package.
