為什要推CMMC?
美國整體每年平均因網路安全所造成的損失達六千億美金。目前國防部的供應鏈，從極音速武器到皮革工廠，大約有三十萬家合約承包商，而其中約有二十九萬家基本上沒有任何的網路安全措施。除了之前沒有法規要求，美國政府近幾年決定大加整頓國防供應鏈，而網路安全被視為首要議題。在此之前，國防部請廠商遵循 DFARS 252.204-7012 以及 NIST 800-171 裡所敘明的規範，其中包括廠商須自行評估認證一百一十項資訊安全項目。然而問題其一在於這是由廠商自我認證，其二是國防部並未特別看重此標準。
於是美國國防部在 2020 年1月底公布新規範 「網路安全成熟度認證Cybersecurity Maturity Model Certification」(簡稱 CMMC)，要求所有與國防部承約或次承約的廠商遵守。國防部預計在 2020 年6月後，開始在些許建議徵求書 (RFP) 和資訊徵求書 (RFI) 中納入 CMMC，並計畫在 2026 年之前讓CMMC 成為所有國防部採購案的必要需求。
2021 年 11 月 4 日，美國國防部再又推出了 CMMC 2.0，與原始模型進行了一些重大更改；並依據業界意見，縮減5驗證層級到3個。簡化評估程序是為了讓實務上變得更可行，並且能夠適應不同規模的供應商。CMMC 2.0 基於最初的 CMMC 1.0 框架構建，可以動態增強 DIB 網路安全以應對不斷變化的網路安全威脅。 CMMC 框架旨在保護國防部共享的敏感非機密資訊並確保問責制度，同時最大限度地減少供應商對遵守國防部所要求的安全規範而產生的實務障礙。
CMMC 2.0 將以依賴完善的 NIST 網路安全標準的三個等級取代五個網路安全合規等級：
- 第 1 級：基礎，基於基本網路安全實務。
- 等 2 級：進階級，以符合 NIST SP 800-171 的實務為基礎。
- 等 3 級：專家級，基於 NIST SP 800-172 增強的 1 級和 2 級所有實踐，它補充了 NIST SP 800-171，以減輕進階網路威脅的攻擊。
根據CMMC的計劃，DIB承包商將被要求實施某些網路安全保護標準，並根據需要進行自我評估或獲得第三方認證，作為國防部合約授予的條件。
Information Protection 與 CMMC 的關係
CMMC 對主承包商提出了更嚴格的責任，以確保整個供應鏈符合適當的安全要求。主承包商必須在授予合約之前驗證分包商合規性的適當水準，以加強整個供應鏈的安全性。
供應鏈廠商均有機會涉及機密資訊（Classified Information）、FCI (Federal Contract Information)與 CUI(Controlled Unclassified Information) 等受保護的資訊，廠商在取得合約前即應合規，並具備相關證明文件，在美國 The Christian Doctrine 與 False Claims Act 的大傘覆蓋下，未合規而宣稱合規或造假，可能面臨重罰，False Claims Act 更是規定讓吹哨者可以獲得罰金的30%為獎勵。CMMC 2.0 已經正式公告，目前正處於法制化（Rulemaking）階段，將於法制化完成後施行，屆時未取得相應 CMMC 層級評鑑完成/通過的廠家將失去取得合約的機會，將來適用於 CMMC 的供應鏈廠商目前已經受到法遵要求，CMMC 如同一個確認（Validation）機制，透過外部（如：第三方機構，或政府組織主導）評鑑來確保合規的真實性，現在的法遵要求與將來 CMMC 的要求，同時適用於國防基礎產業(DIB) 中的廠商。CMMC 是 DoD 基於過去數十年來的經驗過所付出的代價（包含喪失智慧財產權與技術領先優勢），痛定思痛將過往以自評（Self Assessment）或自我具結（Self Attestation）為主的法遵機制，轉向為第三方獨立機構評鑑，以消弭供應鏈資安防護的實務落差。
CMMC 以NIST SP800-171，SP800-172 內容為基礎，而該標準來自於SP-800-53。主要在強調對CUI文件識別與控管。我們會發現其內容所取的Access Control 都來自於800-53的控制。這些國防合約商或供應商為了要服規法遵，勢必要導入文件控管、存取控制、外洩防護的系統，以自證能夠符合國防供應鏈要求。在供應鏈安全的要求之下，這些系統勢必要符合軟體供應鏈安全規範。
2021 年 5 月 12 日白宮發布的《關於改善國家網路安全的行政命令 (EO)》，認知到整個供應鏈中的軟體安全風險不斷增加。聯邦部門和機構透過從其供應鏈（包括開源軟體元件）獲取、部署、使用和管理的軟體和服務，而面臨網路安全風險。由於產品架構和開發生命週期的原因，已購買的軟體可能包含已知和未知的漏洞。於是NIST 發展了軟體供應鏈安全指引。
大多數的軟體都不是從無到有開始開發的，它們通常是含有開源軟體的軟體元件的組合。然而，這些軟體元件容易受到漏洞的影響，且開發人員對來自第三方的原始程式碼掌握度，會隨著時間的推移對軟體元件變更的控制能力較差。
軟體供應鏈任何元件的風險都會連帶影響對依賴該元件的每個軟體，可能提供了駭客植入惡意軟體、後門或其他惡意程式碼的機會，以致危害任何依賴該元件及其相關的供應鏈。
軟體系統供應商的安全責任
依照 Enduring Security Framework (ESF) Software Supply Chain Working Panel，一個跨部會的工作小組對軟體開發者建議實務，Securing the Software Supply Chain: Recommended Practices for Developers指引，軟體開發供應商，應採取關鍵的供應鏈安全實務和方法來降低供應鏈安全風險。
開發者的責任，例如：
- 評估使用的程式碼的安全性和可信度
- 確保開發人員持續開發符合安全規範的專屬程式碼
- 安全地建置和部署程式碼
- 強化應用程式使用的資料傳輸方法
- 持續測試和監控使用中的應用程式是否有威脅
- 為消費者提供 SBOM
除了上述原則，客戶（採購單位）可以使用這個指引作為描述、評估和衡量與軟體生命週期相關的安全實踐的基礎。此外，此處列出的建議做法可以應用於軟體供應鏈的採購、部署和維運階段。軟體供應商有責任對客戶和軟體開發人員之間的溝通。供應商的責任包括通過軟體發佈和更新、通知和漏洞緩解，來確保軟體的完整性和安全性。