我在一个相当规避风险的企业发展环境中工作，管理层经常害怕改变。我已经为我们的开发团队制作了 Jenkins 解决方案的原型，并强调了一些成功案例，其中试点实施有所帮助，但现在是时候让更广泛的受众以更持久的方式批准它了，并且有人提出了一些安全问题。
到目前为止，主要关注点在于该工具是开源的，并且插件是开源的并且由社区贡献者制作，因此管理层担心有人可能会插入我们不会注意到的恶意代码当我们更新时。我的观点是，如果有很多其他地方可以让 Jenkins 工作，我们可能也可以，但这对我们的安全测试团队来说不一定是一个非常有说服力的论据。
我的问题是，谁能告诉我他们是如何保护自己的 Jenkins 实现的，或者如何使用特定的 Jenkins 功能（沙盒等）来防止恶意代码在我们的系统上执行？
【问题讨论】：
标签： security jenkins open-source
在您的软件或基础架构中使用第 3 方组件始终存在风险。需要注意的一件非常重要的事情是，开源并不比闭源安全。虽然可能任何人都可能为开源项目贡献代码，但在大多数情况下，在实际进入项目之前都会进行审查。当然，漏洞可能会漏掉，但这与拥有大量开发人员的软件公司有何不同？漏洞也可能从那里溜走，根据我们许多人的经验，它经常会溜走。 :) 在封闭源代码的情况下，您甚至没有多元化社区的力量来发现此类安全漏洞，您可以依靠的最好的方法是 3rd 方渗透测试或代码扫描，这两者都会遗漏很多问题。
对于像 Jenkins 这样完善的项目，您可以非常确定其安全性受到了很多的审查，可能比您目前拥有的任何闭源商业工具都要严格。
与任何第 3 方组件一样，您应该尽职尽责。定期查看NVD 等在线漏洞数据库以查找安全问题。在更新出现时安装更新以降低风险。您也应该为闭源组件执行这些操作。
至于如何保护 Jenkins 安装，我认为这里的答案不是正确的格式，但有一整套页面 on their website 专门讨论该主题。
说了这么多，看看 Jenkins 过去的漏洞，有很多。由您（和您的安全部门）来评估您希望如何部署 Jenkins，以及这些过去的漏洞是否严重到足以让您认为考虑到您想要部署它的方式整个工具不适合您的环境.同样，这与使用闭源工具的过程相同。
【讨论】：