我們需要的不是一次性的標簽或設置，而是需要將安全放到軟件生命周期的每個階段。

由于軟件供應鏈上的人、代碼和基礎設施一直在改變，交互也越來多，組織(公司)必須將安全納入供應鏈的核心部分。

考慮一個實際存在的產品：如電話，僅僅考慮到最終產品的安全性是不夠的。除了決定使用什么樣的防盜包裝，你可能也想知道材料的來源，以及他們是如何組裝，包裝，運輸。因為，重要的是我們還要確保手機不被改造或運輸途中被盜。

軟件供應鏈幾乎跟實際產品的供應鏈是相同的。你必須能夠識別和信任原材料(代碼、依賴、打包)，把它們組裝在一起后，將它們從海上、陸上或空中(網絡)運輸到一個存儲地(存儲庫)，以便將項目(應用)出售(部署)給終端用戶。

確保軟件供應鏈也十分相似。你需要：

在這篇文章中，我們將詮釋Docker的安全特性如何為軟件供應鏈提供持續(xù)的安全。

身份

整個流水線構建在身份驗證和訪問控制之上 。從根本上說，你需要知道誰可以訪問什么資產，可以使用哪些操作。

Docker 架構中的身份認證理念很清晰，它隱藏在軟件供應鏈策略中：加密密鑰允許發(fā)布者對鏡像進行簽名，以保證其來源的真實性。

一致的構建：好的輸入= 好的輸出

確定一致的構建允許你創(chuàng)建一個可重復的過程，并控制你的應用程序依賴和組件，以便使它更容易測試出缺陷和漏洞。當你對你的組件有一個清晰認識的時候，它變得更容易識別異常的組件。

要獲得一致的構建，你必須確保你添加了優(yōu)質的組件：

使用簽名”密封”構建結果

應用程序簽名是從構建進行有效“密封”的一步。通過鏡像簽名，可以確保任何在接收端(docker pull)的簽名驗證與鏡像發(fā)布者建立一個安全鏈。

這種關系保證了鏡像在傳輸過程中不被改變、添加、或刪除。此外，簽名表明發(fā)布者“贊同”你拉取的該鏡像是沒問題的 。

在構建機器和運行環(huán)境上啟用 Docker Content Trust后，一個策略就會生效：只有簽名鏡像才可以被拉取并運行在那些 Docker 主機上。

在組織中，簽名的鏡像向其他人傳遞一個信號：發(fā)布者(構建者)聲明鏡像是沒問題的。

安全掃描和風控

CI系統和開發(fā)者都需要確認一件事情：構建工具與依賴一起工作，操作你的應用程序時，無論在成功還是失敗，都有預期的行為。

但他們審查過依賴的漏洞嗎?審查過子依賴或捆綁系統庫的依賴嗎?他們知道依賴的許可證嗎?這種審查很難通過常規(guī)的方式來完成，因為提供錯誤修正和功能上是一個巨大的開銷。

Docker 安全掃描有助于鏡像的自動化掃描。因為這是發(fā)生在鏡像被推送到registry之前，在容器被部署進生產環(huán)境之前的最后一次檢查。

該功能目前在Docker Cloud 中可用，并且很快延伸到Docker Datacenter。安全掃描創(chuàng)建了一個清單，清單中包括鏡像每一層的打包信息和版本信息。

這份材料清單被用于連續(xù)監(jiān)測各種 CVE 數據庫。確保該掃描不止一次地發(fā)生，并在爆出新漏洞時，及時通知使用鏡像的系統管理員或應用程序開發(fā)者。

多重簽名-- 把簽名綁在一起

安全保證最強大的一點來自Docker Content Trust 簽名，它允許多個簽名者參與容器的簽名過程。要了解這一點，想象一個簡單的 CI 過程，通過以下步驟移動容器鏡像：

這里有四個階段，每個階段完成后，都可以添加一個簽名，從而CI/CD 過程的每一個階段都有驗證。

現在構建被部署到生產集群之前，它可以加密驗證，CI / CD過程各階段已經簽訂了一個鏡像。

結論

在軟件生命周期的每個環(huán)節(jié)，Docker 平臺都允許企業(yè)將安全納入其中。從與用戶建立信任，到基礎設施和代碼，docker模型給了開發(fā)者以及 IT團隊足夠的自由和控制力。

從構建安全的基礎鏡像，到掃描每一個鏡像驗證簽名，每個特性都允許IT人員將信任植入到應用中。

當應用沿著正常的生命周期不斷前行，安全信息也能夠動態(tài)維護和更新，并在部署到生產環(huán)境之前通過風控檢查。