软件安全是任何产品的关键部分，但在时间和在国内特有的内卷压力下，它可能成为许多项目的次要考虑因素。仅仅提供可工作的软件是不够的；我们的交付也必须值得信赖，并针对已知漏洞提供保护。对于许多应用程序，成千上万甚至数百万个人信息 (PI) 记录的安全性——甚至整个公司网络——都取决于我们应用程序的安全性。

由于风险如此之大，我们必须在保护我们的产品免受漏洞攻击并赢得客户和用户的信任时进行尽职调查。

主要分享低代码、微服务、容器化、SAAS?、系统架构方面的的?内容??，希望?大家?点赞?，评论，关注?。

一般来说，漏洞可能来自我们的应用程序代码和依赖项。我们必须仔细考虑我们引入产品的依赖关系，并确保它们不会损害我们的应用程序。

保护软件依赖包安全性的 5 步清单

下面的清单详细说明了我们可以采取的五个简单但必不可少的步骤，以确保我们的软件是安全的，并且我们正在向我们的客户和用户提供最值得信赖的软件。

1. 积极主动

作为专业人士，我们有责任保护我们的产品。当我们发布产品时，我们会在产品上贴上我们的名字和批准印章。我们容易犯错，但是当我们向有漏洞的客户发布我们的产品并且不努力修复它们时，这对我们公司和我们自己都是不利的。

即使漏洞来自我们产品中包含的依赖项，我们仍然有责任修补我们的应用程序并消除漏洞。我们已决定使用这些依赖项，因此我们必须承担充分审查和升级这些依赖项的责任，尤其是在出现已知漏洞时。归根结底，如果我们的产品危及用户或客户的安全，责任在我们，我们必须在我们的职权范围内尽一切努力保护我们的用户和客户。

2.了解每一个依赖

我们在应用程序中包含的任何代码——甚至是我们的依赖项引入的传递依赖项——都可能危及我们的应用程序。因此，我们有责任枚举应用程序的依赖项。此枚举有时称为软件物料清单 (BOM)，类似于制造业等更传统行业中的 BOM。

我们可以使用包管理器的命令行界面在我们的应用程序中找到所有依赖项（包括传递依赖项）的列表。例如：

• 行家 -mvn dependency:tree
• 摇篮 -gradle -q dependencies
• NPM——npm list --all

我们必须使我们的 BOM 保持最新，并与我们产品中包含的依赖项保持同步。确保这种一致性的最简单方法之一是生成我们的 BOM 作为我们自动构建管道中的一个步骤。每次我们构建应用程序时，我们的构建系统都会生成一个新的 BOM。当我们添加、更改或删除依赖项时，为每个构建生成的 BOM 将相应更新。

3.跟踪最新的漏洞

一旦我们知道我们的产品依赖什么，我们就必须跟踪这些依赖项的安全状态。及时了解安全公告和常见漏洞披露 (CVE) 系统可能会让人望而生畏，但我们可以使用一些资源来帮助我们。

以下是一些最常见的数据库，其中包含现有软件漏洞的最新列表：

• GitHub 咨询数据库
• 美国国家漏洞数据库
• MITRE CVE 数据库

4.自动化流程

即使对于最微不足道的项目，密切关注我们的依赖项并使用安全公告交叉引用它们也可能会让人不知所措。我们应该尽可能地自动化这些安全步骤，并且我们的构建管道应该在每次构建我们的产品时运行它们。只要有可能，我们还应该利用我们已经可用的工具。

例如，如果我们在GitHub上托管我们的应用程序，我们可以使用Dependabot，如果我们在GitLab上托管我们的应用程序，我们可以使用依赖扫描。

5.审计依赖

我们产品中的每个依赖项都会带来一系列漏洞。即使是最普遍的依赖项，如 log4j，也可能受到损害（请参阅Log4Shell）。因此，我们应该始终对我们的依赖项采用极简主义的方法。如果一个依赖没有被使用，我们应该立即移除它，如果一个依赖带来的安全风险超过了它的回报，我们必须找到一个替代方案。查找未使用的依赖项并为此类依赖项生成警告通常可以自动执行（例如，mvn dependency:analyze对于 Maven），并且应该作为构建管道中的一个步骤添加。

结论

我们对我们交付的产品的安全负责，即使漏洞来自我们依赖包中的依赖项。我们的客户和用户对我们产品的信任取决于我们在发现和修补代码和依赖包中的漏洞方面的努力。保持专业的心态、了解我们的风险、跟踪最新的漏洞、自动化我们的流程以及审核我们的产品，对于确保我们的产品符合最高安全标准并保护我们用户的数据和系统大有帮助。

主要分享低代码、微服务、容器化、SAAS?、系统架构方面的的?内容??，希望?大家?点赞?，评论，关注?。

Tags：mvn dependency