一个星期以来，互联网上一直充斥着彭博社的一篇报道，称一次大规模的黑客攻击可能会影响到从亚马逊到苹果的大约30家知名机构，以及美国政府机构。必须事先提到，报告中提到的所有公司都强烈否认所报告的事实，因此，在这一点上，我们处于一个灰色地带，介于这些实体的否认和彭博社的证实之间。然而，不管是真是假，这个故事还是有价值的，它提出了一些关键的安全问题，关于CI/CD过程和整个行业的持续安全。"大黑客"那么彭博社的报道怎么说？三年前，亚马逊正在进行尽职调查，以收购一家专门从事视频流和压缩的公司Elemental Technologies，LLC。作为这一过程的一部分，亚马逊决定聘请一家安全公司来仔细研究Elementals的技术。作为调查的一部分，这家安全公司决定仔细检查一下Elemental使用的服务器；这些服务器包括一个由美国公司Super Micro Computer，Inc.在中国制造的主板，该公司是全球最大的服务器主板供应商之一。在他们的分析中，他们决定将主板设计文档与Elemental Technologies的实际硬件进行比较，发现了一个微小的差别："一个比一粒大米大不了多少的微型芯片，并不是主板最初设计的一部分。"亚马逊向美国当局提出了他们的发现，随后的调查显示，一些黑客组织已经能够在超级微型计算机的供应链中制造一个漏洞，并修改了程序，以便添加一个微芯片，以后可以远程触发，从而允许它在几乎不可见的情况下入侵上千台机器。"…一个微型芯片，比一粒大米大不了多少，这并不是董事会最初设计的一部分。"——彭博商业周刊，大黑客：中国如何利用一个微小的芯片再次渗透到美国公司，目前还没有任何证据证明，所有利益相关者都积极否认彭博社的报道。但是这个故事很有趣，因为即使那个特定的事件没有发生，所报告的用例也不像某种科幻电影，它是非常可信的。如此似是而非，以至于该领域大多数网络安全专家的第一反应都不是"这怎么可能？！"但更确切地说，"为什么黑客会费心去入侵制造过程，而同样的事情也可以通过对芯片组设计本身进行黑客攻击，从而使任何东西都无法被"物理"检查……"对许多人来说，硬件供应链的完整性，这给我们敲响了警钟：硬件供应链的完整性对安全至关重要。如果专业黑客可以通过一个米粒大小的硬件插针奇迹般地绕过防火墙并登录到您的系统，那么为什么还要安装防火墙和复杂的入侵检测软件呢？大多数IT专业人士在这种斗争中感到无能为力。谁有资源、时间和专业知识来进行这种深入的审查？这不仅仅是关于你的主板供应链和设计文件，我们还讨论了所有元素进入你的数据中心（以及其他地方！你公司的电话呢？笔记本电脑？）。事实是，越来越严重的是，只有拥有巨大临界质量的玩家才有办法进行如此深入的安全审查？他们是谁？好吧，在大多数情况下，公共云运营商（IaaS）！云和安全今天，几乎只有云供应商才有足够的能力来证明这些投资是合理的（同时也因为他们明白不这样做有什么利害关系）。然而，我正在会见的许多组织仍然将安全性这一特定论据作为不使用云的理由。在这样的事件中，这是思想难以置信。经常，当我与一家持相同观点的公司会面时，我问他们有多少全职员工（FTE）专门从事网络安全研究。答案通常在低个位数。接下来，我问有多少人专门关注芯片设计的安全缺陷？这个问题的答案总是0。再加上一双眉毛。然后我讨论了Google的projectzero如何能够识别出CPU架构内部的许多关键安全缺陷，甚至可以评估高度复杂的"推测性执行"CPU的行为发动机。As我们进入IT产业化的新阶段，只有大规模的基础设施参与者才有足够的能力在提供限制此类风险所需的审查级别方面发挥重要作用。云是你最好的选择保安。什么关于你的软件供应链？环境虽然围绕"大黑客"的讨论集中在硬件供应链的完整性上，但同样的问题也可以被问到同一个硬币的另一面：软件供应链的完整性。它的完整性对于确保你不暴露在隐藏的后门和其他威胁中是同样重要的。许多组织都花了很大的努力来确保他们的供应商履行他们的义务。从操作系统到应用程序性能管理（APM）和监视工具，任何紧密集成在软件堆栈中的软件，如果其完整性受到损害，都有可能造成很大的损害。基本上，你必须相信你的供应商会做正确的事情（为此，大型组织通常会对供应商的工程流程进行尽职调查，并强制使用强有力的法律语言，以避免任何误解）。必须确保你的供应商向你提供你期望的信息，但是你自己的呢？一、 你的组织生产的软件？您的软件也存在风险在持续信息/连续交付（CI/CD）尚未跟上的地方，软件中引入黑客攻击的风险很难确定，因此要防止：几乎任何接触软件、源代码或二进制文件的人都有可能引入漏洞，或者是故意的，或者在更可能的情况下，尽管他们自己，作为一个媒介。从开发到质量保证、发布工程、生产等，任何一步都可以被第三方利用来感染你的软件。让我们明确一点，在这样一个表面暴露的情况下，不作为CI/CD的一部分实现连续安全性是灾难。组织转移到CI/CD的情况则截然不同。依赖于从软件到生产的全自动化过程的应用程序，为此类攻击提供的表面要少得多。实际上，在一个完全自动化的场景中，源代码直接从存储库中提取出来，并通过一系列不可篡改的步骤将其投入生产。任何更改都必须发生在源代码中（因此将可见并进行版本控制），或者发生在管道定义中（类似地，管道定义存储为源代码）。至于生产环境，许多组织现在都依赖于基础设施作为代码（或GitOps，Jenkins X如何运行的核心），然后受益于以下优点：完全可视性、可跟踪性和版本控制影响是巨大的。不再需要深入检查软件的每个版本以确保它没有被篡改，现在可以将重点放在CI/CD过程本身：如果您的过程通过了检查，那么该过程的任何执行都将满足您的需求。如果你决定改进你的流程，那么——而且只有这样——你才需要重新检查你的流程——更具体地说，改变的部分——可能会有非常小的范围。类似对于公共云的误解，如果操作得当，持续交付*会提高*您保护软件交付的能力，同时提高速度，减少手动检查每个释放的需要篡改。你的CI/CD过程是您的基础设施，CloudBees如何帮助您？现在很多公司都在使用詹金斯。通常，许多开发团队开始使用Jenkins作为一种方法来自动化其生命周期的早期步骤，并避免"但它在我的计算机上工作"的戏剧。但是，一步一步地，他们对Jenkins的使用开始进一步扩展，最终捕获整个应用程序生命周期。在那次软性过渡期间，许多组织并没有真正认识到詹金斯开始扮演一个完全不同的角色。从一个"由开发人员，为开发人员"使用的非关键工具中，Jenkins成为一个产生组织中每一个部分的总体编排引擎：如果你的工具坏了，你就不能再发布软件了！在大多数组织中，Jenkins已经成为一个业务关键型环境，应该像任何产品一样从同样的审查级别中受益系统。但是这不仅仅是Jenkins变得至关重要的程度……你需要确保你的CI/CD系统和环境（作为CI/CD过程一部分的任何工具，源代码和二进制回购等）是安全的。如果不是，它可以作为一个惊人的向量，透明地感染你通过这个实例产生的所有比特。让我们非常清楚：Jenkins（或任何CI/CD系统）是一个绝对重要的基础设施，具有高可用性和安全性-很聪明。但是，我仍然会遇到许多没有在这方面实施任何适当做法的组织。首先，并不总是清楚他们从哪里得到二进制文件。然后，他们安装了它并扩展了Jenkins的使用，而没有仔细规划规模和采用。这往往会导致不稳定的"詹金斯坦"环境，他们很少尝试消毒。最终，由于害怕"破坏有效的东西"，他们不会升级Jenkins实例。这是安全的最佳配方戏剧。云蜂帮助您获得认证