如果在 Java Maven 项目中使用了某个 jar，有没有办法在 Jenkins 中构建失败？
例如，我知道 org.example:badartifact:1.0.1 存在安全漏洞。我把这件事告诉了所有人，他们修复了他们的项目……但也许一些第三方工件将其作为传递性带入了他们，而没有人意识到这一点。
或者也许有人下线忘记了这个老错误......
所以我希望最好在 Jenkins 中进行最后一次检查，这样我们就不会最终得到包含该特殊工件的项目。
你如何处理这样的情况，你使用什么工具？ （将库列入白名单？将库列入黑名单？等）
欢迎提出任何建议。
【问题讨论】：
标签： java maven security jenkins building
可能的 Maven 解决方案
您可以拥有一个公司超级 POM（公司/部门/团队中所有 Maven 项目的parent POM），并在该超级 POM 中配置Maven Enforcer Plugin，其bannedDependencies rule 禁止任何库、版本甚至范围。我个人使用这个选项，即使是微不足道的错误（即 junit 不在测试范围内会使构建失败）。
此解决方案是集中式解决方案，因此更易于维护，但要求所有项目具有相同的父 POM，并且开发人员可以随时更改父 pom，因此跳过此治理。另一方面，集中式父 POM 对于依赖项管理、通用配置文件、报告等非常有用。
注意：您不能通过默认配置文件在 Jenkins 服务器的 Maven 设置中配置它，例如，为了使其应用于所有正在运行的 Maven 构建，因为Maven limits自定义设置提供的配置文件中的构建（这是一种设计选择，以限制外部影响，因此更容易进行故障排除）。我过去曾尝试过，但碰壁了。
外部文件中的配置文件
在外部文件（即 settings.xml 或 profiles.xml）中指定的配置文件在最严格的意义上是不可移植的。任何似乎很有可能改变构建结果的东西都被限制在 POM 中的内联配置文件中。诸如存储库列表之类的东西可能只是已批准工件的专有存储库，并且不会改变构建的结果。因此，您将只能修改 and 部分，以及一个额外的部分
可能的 Jenkins 解决方案
如果您想直接在 Jenkins 中集中治理，因此独立于 Maven 构建，我过去已经应用了这些解决方案（并且它们非常有效）：
mvn dependency:tree，因此作为构建输出的一部分，依赖项列表（甚至是可传递的）。匹配您被禁止的依赖项的文本查找器规则将匹配它并导致构建失败。【讨论】：
这是完成这项工作的一种解决方案:)
使用Maven License plugin，您可以扫描 Maven 项目的第 3 方依赖项并生成 THIRD_PARTY.txt 报告（在 target/generated-sources/license 文件夹中）。
Maven 命令行：
mvn license:aggregate-add-third-party
接下来，您可以使用TextFinder plugin 在 THIRD_PARTY.txt 文件（例如：org.example:badartifact:1.0.1）中搜索“不安全”依赖项，并在需要时更改构建状态。
另一种解决方案是使用 3rd 方工具来执行此操作。
我正在对此进行一些调查：http://www.whitesourcesoftware.com/
此工具可以提供存在漏洞问题的第 3 方依赖项列表。
【讨论】：