最近成名 通過 一篇博客文章 識別漏洞的測試工具的結果 沒有補丁並確定安全問題 在隔離的Docker容器映像中。
測試顯示4台掃描儀中有6台 已知的Docker映像 有嚴重漏洞 在某些情況下（例如，使用Snyk）具有root特權，可以攻擊掃描程序本身並在系統上運行其代碼。
為了進攻 攻擊者只需要開始檢查他的Dockerfile 或manifest.json，其中包含特殊格式的元數據， 或將podfile和gradlew文件放入圖像中。
我們設法為WhiteSource，Snyk，Fossa和anchelle系統準備利用原型。
埃爾帕克特 聖克萊爾 最初出於安全考慮而編寫， 顯示出最佳的安全性。
Trivy軟件包中未發現任何問題 結果是，得出的結論是Docker容器掃描儀應在隔離的環境中運行或僅用於驗證其自身的映像，並且在將此類工具連接到自動連續集成系統時也要小心。
這些掃描儀執行複雜且容易出錯的事情。 他們正在與碼頭工人打交道，提取圖層/文件，與程序包管理器進行交互或分析不同的格式。 在試圖適應開發人員的所有用例的同時，捍衛它們非常困難。 讓我們看看不同的工具如何嘗試並設法做到這一點：
負責任的披露分數反映了我的個人看法：我認為對於軟件供應商來說，接受報告給他們的安全問題，誠實和透明地對待漏洞，確保使用產品的人員很重要。會被適當告知，以做出有關更新的決定。 其中包括最重要的信息，即更新具有與安全性相關的更改，打開CVE來跟踪和傳達有關問題的信息，並有可能通知您的客戶。 我認為，如果產品涉及CVE，並提供有關軟件漏洞的信息，這是特別合理的假設。 而且，我對快速反應，合理的更正時間以及與報告攻擊者的公開交流感到放心。
在FOSSA，Snyk和WhiteSource，該漏洞與 打電話 到外部包裝經理 確定相關性，並通過在gradlew和Podfile文件中指定touch和system命令來組織代碼的執行。
En Snyk和WhiteSource還發現了一個與啟動系統命令相關的漏洞 解析Dockerfile的組織（例如，通過Dockefile在Snyk中，您可以替換由掃描儀引起的實用程序ls（/ bin / ls），而在WhiteSurce中，您可以通過“ echo”形式的參數替換代碼;點按/tmp/hacked_whitesource_pip;=1.0'«）。
在Anchore中，漏洞是由使用skopeo實用程序引起的 使用docker鏡像該操作減少為在manifest.json文件中添加形式為'»os»：«$（touch hacked_anchore）»的參數，在調用skopeo時沒有適當轉義的情況下將替換這些參數（僅刪除字符«;＆< >”，但構造為“ $（）”）。
同一位作者對漏洞檢測的有效性進行了研究 沒有打補丁 通過安全掃描儀 碼頭集裝箱的數量和誤報的水平。
除了作者 認為其中一些工具 直接使用包管理器解決依賴關係。 這使他們特別難以防禦。 一些依賴性管理器具有允許包含Shell代碼的配置文件。
即使以某種方式處理了這些簡單的方法，致電這些軟件包經理也將不可避免地意味著花錢。 坦率地說，這不利於保護應用程序。
73個包含漏洞的圖像的測試結果 以及對確定圖像中典型應用程序（nginx，tomcat，haproxy，gunicorn，redis，ruby，node）的有效性的評估， 可以諮詢 在出版物中 在下面的鏈接中。