容器可追溯到1979年的chroot命令，但Docker的出現讓該技術的流行度和可用性有了指數級增長。任何技術一旦流傳開來，必然也就成了攻擊的目標。
容器旨在提供非完整虛擬機之外的隔離環境，但因為往往不像IT環境中其他資產一樣受到監視，容器也就成為了攻擊者眼中的肥肉。
公司企業有必要對容器進行漏洞評估，就像對環境中其他任何資產所做的那樣。有那么幾個漏洞掃描器可以掃描運行中的容器并報告漏洞，旦那只是整個評估的一部分。
容器并非全時段運行，只有完成特定任務時調用一下，然后就是暫停掛起或關機，直到下一次需要的時候再運行。如果掃描的時候容器沒在運行，傳統掃描器就可能會錯過漏洞。
我們可以做個類比以更好地理解這種情況。大多數公司都用筆記本電腦，也會對筆記本電腦進行漏洞掃描。如果掃描的時候筆記本電腦正好接入網絡，那么其中存在的漏洞就會被掃到并上報，但如果電腦正好關機或休眠了，漏洞掃描就無法評估這臺電腦的情況(假設沒有局域網喚醒功能)。
容器的情況與之類似：必須正在運行，才可以被漏洞管理產品評估。
不過，如今，情況改變了。
Tripwire漏洞與暴露研究團隊(VERT)發布了ASPL-736，增加了非運行Docker容器掃描功能(暫停、停止、創建、退出等等狀態均可)。該功能作為運行容器掃描的補充，對生產中的容器狀態有了全面的視圖。
有人可能會覺得，“好酷!不過，如果在進入生產前就全都掃描過了，為什么我還需要掃描非運行容器呢?”
可以再用筆記本電腦的類比來回答這個問題。公司或許會對所有筆記本電腦采用通用鏡像，里面是已知完好的操作系統和經批準的App。在發給員工的時候，確實是在一個良好的狀態。然后，員工可以通過安裝軟件，甚或暴露在惡意軟件之下，讓該電腦狀態發生改變。因為在漏洞掃描的時候，該電腦未必接入網絡，因而這些威脅很可能就被漏掉了。
不建議對生產容器進行修改/修復。相反，你應該修復父鏡像，測試之，并用已更新的鏡像替換掉生產容器。對筆記本電腦或許不會這么做，但我們仍可應用相同的類比，因為正如企業會有很多同樣的筆記本電腦，擁有很多同樣的容器或容器間共享的組件并不奇怪。
影響筆記本電腦的漏洞有補丁可用時，會執行漏洞掃描以確保所有系統都被更新。那么有大量容器需要打上OpenSSL補丁時呢?
基礎鏡像會被更新，更新過的容器再被重新部署進生產中。如果漏洞管理解決方案只能掃描運行中的容器，便無法確保所有容器都被更新。這就留下了盲點，容器可能在缺乏真實漏洞狀態可見性的情況下被喚醒或啟動。
非運行容器掃描功能，賦予了安全管理員超級X光透視能力，可以看清容器狀態，清除這些盲點。
京公網安備 11010502049343號