昨天介紹完前3項判斷標準，今天就來講後5項判斷標準吧！後五項的比較像是政策類的判斷，而非昨天令人頭昏眼花的技術類判斷，所以會輕鬆一點。

編號發給規則 (Inclusion Decisions)

INC1 確認負責的CNA

CNA是有權限可以發出CVE編號的單位，他們可能是一個資訊產品廠商、資安公司、CERT或資安研究單位等，完整CNA列表可以在官網上查到（網址：https://cve.mitre.org/cve/request_id.html#cna_participants ）在每個地區的分布則如下圖所示，很明顯的看出美國有最多的CNA，目前台灣有4個單位已經申請成為CNA，包含TWCERT/CC、群暉科技、QNAP及趨勢科技（趨勢應該算台灣的沒錯吧哈哈）。
由於每個CNA都有自己負責發布CVE編號的產品範圍，像大部分的廠商CNA，他們就只能發CVE編號給自己家的產品，例如群暉科技只能發CVE編號給他們加自己的產品，但如果像是CERT的話範圍就會比較大，像是以TWCERT/CC來，只要是跟他們業務及角色沾的上邊，而且沒有範圍更小的負責CNA的話，他們都可以發CVE編號。

在這個步驟很簡單，就是確定CVE編號是要給哪個CNA發，但有時候也會有權責界定出現爭議的狀況，這時候就是找MITRE協調看是哪個CNA要發，或是直接由MITRE（他們是權限最大最高層CNA）發出。

INC2 漏洞有沒有打算要公開

在這個階段，必須確認漏洞有沒有要被公開，如果沒有要公開的話是不能拿到CVE編號的，也就是說廠商CNA不能自己發一個編號給自己產品，但是不把這個漏洞資訊公開，也就是說只要有發給CVE編號的漏洞就一定要公開。
一個公開的漏洞資訊必須要包含一個直接描述該漏洞的公開網址、產品名稱、產品版本、漏洞種類，其實並不需要給到太細節的資訊，MITRE也不希望將PoC等技術資訊放在CVE的描述內，因為他們只是要幫漏洞作編號，而不是希望有人藉次去測試漏洞。
補充一點，上面提到要有一個直接描述該漏洞的公開網址，這個網址可以是一個需要登入的介面，但是必須要是可以免費申請成為會員就可以看到的資訊，所以如果設計成免費使用者只能看到最低限度的必要資訊，但是PoC等要付費才能閱覽也是沒問題的。

INC3 產品使用者需不需要採取行動

在這個階段中，必須判斷產品的使用者有沒有需要對於產品漏洞作一些處置，如果不需要的話則該漏洞就不符合資格可以取得CVE編號，例如如果Microsoft發布新的Windows漏洞更新，Windows的使用者就必須使用Windows Update將更新檔下載下來並安裝，已完成漏洞修補，這種狀況下就是為符合此階段資格；如果今天是Google網頁被發現一個SQL Injection漏洞，瀏覽Google網頁的使用者並不需要做任何事情來修補網頁上的漏洞，只要Google有把網頁漏洞修好就沒事了，在這種狀況下該漏洞就視為不通過此項標準，所以不能給他CVE編號。

INC4 漏洞是否存在於可以公開取得的合法產品內

如果要取得CVE編號，該產品必須要是可以公開被取得的，例如可以從各種銷售通路上買到，反之，如果只是一個組織內部開發給自己使用的軟體，就算發現漏洞也不能申請CVE編號。
此外，這個軟體必須要是一個合法的軟體，例如就算發現一個病毒有漏洞，也不能幫他申請CVE編號。

INC5 CVE編號列表中是否已存在重複的漏洞

既然CVE編號的目的是要為每個不同的漏洞建立編號，在列表中不能有重複的漏洞出現也是理所當然，因此，在發出CVE編號前必須確認該漏洞沒有發給過CVE編號。
 
以上就是第二部分的判斷標準介紹，真的是很多眉角要注意阿，雖然官方在描述這8個項目時有利用箭頭一項一項往下走，會讓人覺得必須由第一項看始看依序看到第8項，但其實就實務上來講，前3項在判斷上常有爭議，反而後5項會是比較快能夠確認的，所以其實不用特別在意各項判斷的先後順序，反正如果要發CVE給漏洞，一定要全部的條件都符合，所以也可以先從容易判斷的項目開始處理，如此一來，只要在簡單的項目發現不符合條件，就可以省下處理後面麻煩項目的時間。

此外，其實不是每個CNA、研究人員甚至廠商自己本身都有足夠的能力來處理漏洞或進行上述判斷，所以就算一開始把漏洞內容寫錯了也沒關係，CVE也有一些像是合併漏洞、分割漏洞或停用漏洞等機制，讓整個CVE編號列表可以越來越完善！

參考資料：
[1] https://cveproject.github.io/docs/cna/training_slides/index.html