目錄
一、什麼是製品與製品庫？
製品是指由源碼編譯打包生成的二進制文件，不同的開發語言對應着不同格式的二進制文件，這些二進制通常可以直接運行在服務器上。
製品庫用來統一管理不同格式的軟件製品。 除了基本的存儲功能，還提供了版本控制、訪問控制、安全掃描、依賴分析等重要功能，是一種企業處理軟件開發過程中產生的所有包類型的標準化方式。
二、哪裏痛？
概況：
第三方依賴包下載管理混亂，沒有準入管控；
交付包使用FTP或者SVN進行管理，管理粒度相對較粗；
第三方依賴包的安全風險管理形同虛設，或者滯後；
由於受到監管約束，一鍵部署是不可能任務，跨網段的包交付智能依賴於手工拷貝；
團隊內部搭建的製品庫是單點的，缺乏集羣部署；
因爲沒有統一的製品庫，存在重複建設的問題；維護成本高，或者說目前根本就沒有維護；
針對引入進來的第三組件沒有進行組件掃描，極易引入漏洞；
安全風險：
從底層操作系統、到容器、開源腳手架、再到三方組件，我們在系統開發過程中引用着越來越多的開源組件，研發效率確實是提升上去了，但是帶來的安全風險是越來越高。從以下圖可以看出來，我們自己寫的代碼量只佔了0.1%，但對應的第三方依賴卻佔了99.9%。因此，對於製品的管理（包括版本管理、風險管理）就尤其顯得重要。另外，已知30%的Docker鏡像，14%的npm package，59%的maven中央庫都還包含已知漏洞，而且漏洞平均修復週期約爲2年。
組件准入 ：
拿maven舉例子吧，程序員只需在pom文件配一個新依賴就可直接從中央庫上拉取一個不知名的三方包，當然一般有點血性的同學還是會拉取高知名度的三方包；而且最要命的是你根本都不知道整個研發團隊的組件引用情況是怎樣的，因此你的整體風險評估根本無法下手做。根據2018年synk發佈的信息安全狀態報告，我可以從以下兩個維度去告訴你風險在哪裏。
1、從趨勢上來說，maven中央庫新增漏洞在2018年增長了27%，npm則增長了47%（如下圖一）。隨着我們工程的依賴越多，我們引入漏洞的風險機率也是正比增加的；
2、從依賴層次來說，npm、Maven和Ruby中的大多數依賴項都是間接依賴項，間接依賴項中的漏洞佔總體漏洞的 78%（如下圖二），這樣就使得1）通過人工發現的依賴漏洞變得越困難，因爲漏洞藏得越深，2）漏洞發現後的修復工作需要更長時間。而根據過往經驗，在一天或更短的時間內解決高危或關鍵漏洞的基本是很困難。
版本溯源 ：
從下圖可以看出來【製品管理】就是我們整個DevOps流水線的樞紐。首先，它控制着部署包的按配置規則自動分發部署，可以避免人工因一時抽風帶來的版本問題；其次，它是可以設成自動化，讓分發部署變成一種自助式服務；具體可以問問你旁邊的同事，你問問他們更願意用APP、ATM機還是人工櫃檯去轉賬，道理就不言自明。
-
如果版本發佈錯誤怎麼辦？如何追溯？
-
如果版本引入了安全漏洞怎麼辦？推到重來，業務方允許嗎？
-
等着緊急發版測試，手工傳包的同事逛街去了怎麼辦？估計開發要被拉去祭天得了。
只有引入了製品庫，才能真正實踐Once Integration，Run anytime anywhere，才能真正無縫實現所測即所部署。
三、如何管控？
安全左移
目前由於我們的第三方組件掃描都是滯後的，當我們的版本基本上到了SIT或UAT尾聲才交付給信息安全進行組件掃描。如果這個時候掃描出一些第三方組件有嚴重的安全漏洞。那還要不要投產？如果繼續投，我們是求神拜佛保佑漏洞不被發現且利用嗎？如果修復後再脫產，因爲部分可能涉及到底層框架的改動（如Spring、Struts2這類），如果要在臨近投產的這麼短時間內完成改造首先不現實，其次是高風險，同時也有可能會導致項目延期。
那應該要怎麼辦呢？對了，進行安全左移。如果要實現安全左移，我覺得需要從策略、流程、工具、培訓四個維度開展。
1、要把安全策略從被動轉爲主動，把組件掃描前置到開發過程中；傳統的做法是在UAT快結束時才把源碼交付給安全部門進行一系列的漏掃或者滲透測試；這樣可以理解，畢竟可以節省安全部門本來就人手不足的現狀。但是我覺得既然有人手不足的現狀，我們更要想辦法從工具層面給開發人員賦能（如下圖一）;
2、 質量保證一直是軟件開發生命週期的一部分。但是在過去，安全防護從未包括在軟件質量中，至少沒有體現在開發及測試階段。因此，就好像我們設置SIT准入一樣，我們對於源碼的交付也要設置安全准入（如組件掃描中的CVE漏洞不能出現中高危）；
3、上面說到的兩點，如何給開發人員賦能當然也是需要工具的支撐（因爲在先進這麼多技術棧、依賴引用嵌套那麼複雜的情況下如果單靠人就好像大海撈針一樣）。目前瞭解到的是JFrog Xray可以支持類似的功能，它能夠在開發IDE端偵聽POM文件的依賴及依賴傳遞的變化，一旦POM文件發生任何變化，Xray就可以對該工程的所有的依賴進行深度遞歸掃描，將掃描結果呈現在IDE上（如下圖二），這樣就可以讓開發馬上收到關於關於該新引進組件的安全情況反饋（這是不是也是很"DevOps"呢）。
4、安全左移的最後一步，就是確保作爲編碼主體的人員在開發初期便創建安全的代碼。DevOps服務提供商GitLab最近發佈的一項調查進一步強調了這一點，其中發現有 70% 的程序員應該編寫安全的代碼，但只有 25% 認爲所在企業的安全實踐“還不錯”。因此，信息安全開發層面的培訓還是的跟上。
被動轉主動：
依賴遞歸掃描：
建立安全白名單制度
這裏借用JFrog的一些部署方案（如下圖），大致解決方案如下：
1、在外網建立安全漏洞庫，開源的可以從NVD、VnlrDB定時更新，商業可以購買synk的服務；同步建設有白名單制度用於特殊包申請，統一整合到整體的信任規則庫；
2、在DMZ區建設DMZ代理公網鏡像倉庫，根據安全漏洞庫的規則過濾從公網上拉取第三方包。如果第三方包是被掃描到漏洞的，則禁止拉取到內網的製品倉庫。
使用製品庫進行組件版本溯源
傳統制品倉庫無法管理構建過程，因此對構建過程中的依賴也無法統一管理，該部署包具體含有多少個依賴包，依賴包的二級依賴包又有什麼包，完全是兩眼一抹黑。因此，這時候就需要對二進制製品的所有內容有一個清晰的視圖，它需要提供以下功能：
1、正反向依賴：能夠清楚知道應用程序引入的依賴組件清單，同時能夠知道某個依賴組件的使用範圍。
2、依賴可用性：能夠通過人工識別，工具掃描等方式判斷依賴組件的可用性
4、依賴控制：當某個依賴組件不可用時能夠根據組件的嚴重級別實施不同的控制策略，控制階段就是上面提到的『編譯階段』
5、依賴知識庫：沉澱依賴組件知識庫，能夠記錄依賴組件的基本信息，問題記錄，黑名單，白名單。當開發人員在引入組件時就能知道依賴組件是否可用，而不需要到後面的階段在被攔截。
6、依賴度量：度量依賴組件使用情況，能夠通過統計圖表的展現形式統計組件的最多使用，以及分佈，問題版本統計，問題版本產生的問題統計，以及特定時間範圍內的趨勢。
據前期的使用調研（當然可能也不全面），Nexus沒有針對編譯包的整個依賴管理及正反向解析功能，而Artifactory 將構建任務、構建歷史及依賴信息有條理地管理起來，方便對正反向依賴進行追蹤，能夠清晰瞭解安全威脅傳遞的路徑、影響範圍(項目、團隊、產品)等信息，能夠爲開發人員提供可視化的能力。（以下爲Artifactory的依賴分析的一個依賴路徑概念圖）
四、有哪些工具？
製品庫比較出名的有Nexus和Artifactory，當然現在大廠目前推出的DevOps平臺也集成了類似的功能（如阿里雲效、CODING、京東的JCI）；
關於Nexus OSS Repository
具體的安裝使用請參考我以前的一篇文章：https://blog.csdn.net/justyman/article/details/89279395
關於Arifactory
目前是有免費開源版，後面在另外一篇文章介紹具體的用法。