無需容器執行就能對其進行漏洞掃瞄的技術

本文講的是無需容器執行就能對其進行漏洞掃瞄的技術，容器可追溯到2023年的chroot命令，但docker的出現讓該技術的流行度和可用性有了指數級增長。任何技術一旦流傳開來，必然也就成了攻擊的目標。

容器旨在提供非完整虛擬機器之外的隔離環境，但因為往往不像it環境中其他資產一樣受到監視，容器也就成為了攻擊者眼中的肥肉。

公司企業有必要對容器進行漏洞評估，就像對環境中其他任何資產所做的那樣。有那麼幾個漏洞掃瞄器可以掃瞄執行中的容器並報告漏洞，旦那只是整個評估的一部分。

容器並非全時段執行，只有完成特定任務時呼叫一下，然後就是暫停掛起或關機，直到下一次需要的時候再執行。如果掃瞄的時候容器沒在執行，傳統掃瞄器就可能會錯過漏洞。

我們可以做個模擬以更好地理解這種情況。大多數公司都用膝上型電腦，也會對膝上型電腦進行漏洞掃瞄。如果掃瞄的時候膝上型電腦正好接入網路，那麼其中存在的漏洞就會被掃到並上報，但如果電腦正好關機或休眠了，漏洞掃瞄就無法評估這台電腦的情況（假設沒有區域網喚醒功能）。

容器的情況與之類似：必須正在執行，才可以被漏洞管理產品評估。

不過，如今，情況改變了。

tripwire漏洞與暴露研究團隊(vert)發布了aspl-736，增加了非執行docker容器掃瞄功能（暫停、停止、建立、退出等等狀態均可）。該功能作為執行容器掃瞄的補充，對生產中的容器狀態有了全面的檢視。

有人可能會覺得，「好酷！不過，如果在進入生產前就全都掃瞄過了，為什麼我還需要掃瞄非執行容器呢？」

不建議對生產容器進行修改/修復。相反，你應該修復父映象，測試之，並用已更新的映象替換掉生產容器。對膝上型電腦或許不會這麼做，但我們仍可應用相同的模擬，因為正如企業會有很多同樣的膝上型電腦，擁有很多同樣的容器或容器間共享的元件並不奇怪。

影響膝上型電腦的漏洞有補丁可用時，會執行漏洞掃瞄以確保所有系統都被更新。那麼有大量容器需要打上openssl補丁時呢？

基礎映象會被更新，更新過的容器再被重新部署進生產中。如果漏洞管理解決方案只能掃瞄執行中的容器，便無法確保所有容器都被更新。這就留下了盲點，容器可能在缺乏真實漏洞狀態可見性的情況下被喚醒或啟動。

非執行容器掃瞄功能，賦予了安全管理員超級x光透視能力，可以看清容器狀態，清除這些盲點。