網路彈性法案合規及 Application Security 

大多數著手應對《網路彈性法案》(CRA) 的組織都把精力放在了錯誤的地方。他們致力於加強安全管道、擴大掃描範圍並詳細記錄風險評估。所有這些工作都發生在產品發布之前。而該法案規定，法律責任應在產品發布之後承擔，此時產品已經分發並在製造商無法控制的環境中運作。 

CRA對此有明確規定。包含數位元素的產品不僅在上市時，而且在其整個營運生命週期內都必須滿足基本的網路安全要求，包括如何處理漏洞以及如何偵測和報告安全事件。這導致了與大多數團隊預期不同的故障模式。合規性並非取決於開發過程中是否識別出漏洞，而是取決於產品能否抵禦漏洞、限制其影響，以及在漏洞被利用時能否提供證據。

CRA 適用於任何組織，無論其位於何處，只要其開發、進口或分銷「具有數位元素的產品」（硬體或軟體）到歐盟。

時間軸：網路韌性何時投入運作 

《網路韌性法案》已開始實施。該法案於2024年12月10日生效，並制定了明確的實施路徑，逐步加重對含數位元素產品製造商的負擔。首個重要的實施里程碑將於2026年9月11日到來，屆時第14條規定的報告義務將生效。該法案的全部適用範圍將於2027年12月11日生效，屆時主要條款將正式實施。 

這個過程引入了合規體驗的結構性轉變。組織將經歷一個過渡期，曾經標誌著成熟的能力將轉變為與既定回應視窗掛鉤的強制性要求。在 2026 年里程碑之前，團隊可以將漏洞利用可見性和漏洞處理視為需要改進的領域。此後，這些能力必須在嚴格的時間限制內運作，並有證據支持其檢測、分類和回應能力。 

到 2027 年，該標準將涵蓋整個生命週期。安全開發實務、測試覆蓋率和風險評估必須與產品在實際環境中的運作直接相關。這項要求不僅限於設計意圖，還延伸到產品在組織控制範圍之外的環境中運作時能否經受住嚴格審查，以及相關流程能否在審查​​下產生可驗證的證據。 

許多準備工作正是在這裡開始偏離軌道。團隊專注於文件編寫、發布前驗證和控制覆蓋範圍，因為這些要素更容易編目和審計。然而，時間緊迫，壓力也隨之轉移到其他方面。它要求證明產品能夠抵禦漏洞、偵測主動濫用行為，並在發布後仍具有可防禦性。合規性不再僅僅取決於準備工作，而是取決於運行時行為和可觀察的證據。 

攻擊者直接與二進位檔案交互，而不是與你的控制介面交互。 

附件一第一部分要求產品限制攻擊面、防止未經授權的篡改、保護完整性並降低事件的影響。這些要求假定攻擊者與已部署的軟體之間存在直接互動。 

行動應用程式被下載並解壓縮。其類別和方法被重構。 API 端點和身份驗證邏輯被提取。在同一會話中，一個運行時偵測框架被附加到應用程式上，用於攔截和修改其執行過程。透過重寫函數傳回值，繞過了驗證檢查。由於請求在結構上仍然有效，因此不會觸發任何伺服器端異常。這就是 CRA 所針對的基準執行環境。 

Digital.ai Application Security 它會修改已編譯的應用程序，使得逆向工程無法再產生可用的邏輯表示。控制流會被改變，標識符會被移除，執行路徑也會變成非線性。這並非完全不可能進行分析，但會顯著增加所需的工作量，使其超出大多數攻擊的實際閾值。該方法假設應用程式已經建置完成，並專注於研究攻擊者完全控制應用程式時其行為。  

使用標準的手機銀行應用程序，這些步驟可以在幾分鐘內重現。業務邏輯直接從編譯後的應用程式重建。透過靜態分析，客戶端控制變得可見。然後使用運行時插樁在執行期間覆蓋驗證邏輯。 

在典型的實作中，應用程式透過伺服器頒發並儲存在本機裝置上的令牌來維護使用者會話。從架構角度來看，這種模型看似可控且安全，應用程式與後端服務之間的通訊經過身份驗證。從用戶角度來看，應用程式繼續按預期運行。發送到後端的請求在結構上仍然有效、經過身份驗證，並且符合預期行為。從基礎設施角度來看，未偵測到任何異常。攻擊完全發生在應用程式邊界內，執行過程被修改，敏感資料被洩露，但並未破壞預期的請求模式。 

漏洞利用發生在應用程式內部 

銀行應用程式可以遵循安全的開發實踐、強制執行身份驗證並依賴伺服器端驗證，但部署後仍然會暴露在外。行動銀行應用程式透過伺服器頒發並儲存在裝置本機的令牌來維護使用者會話。該應用程式與後端端點通信，以進行登入、餘額查詢和交易。從架構角度來看，這種模型似乎可控且安全。 

攻擊者並非直接攻擊基礎設施，而是提取應用程式二進位檔案並重構其邏輯。利用標準的逆向工程工具，攻擊者可以識別 API 端點、驗證流程以及會話令牌的儲存位置。隨後，攻擊者將注入程式碼的應用程式重新打包，並透過一個模仿合法服務的釣魚網站進行分發。當使用者安裝並執行這個修改後的版本時，從使用者的角度來看，應用程式的行為與預期一致。但同時，它會捕獲會話令牌並將其發送給攻擊者。 

利用該令牌，攻擊者可以直接向後端發出合法請求。由於結構和身份驗證看起來合法，伺服器會處理這些請求而不會觸發異常。從基礎設施監控的角度來看，一切正常。但從應用程式的角度來看，其執行方式已被更改，敏感資料已被洩露。這就是《網路彈性法案》所假設的運作環境。產品已不再受製造商控制。攻擊者直接與應用程式交互，修改其行為，並利用合法途徑進行攻擊。 

只有當申請中包含風險評估時，才會強制執行風險評估。 

第13條要求含有數位元件的產品製造商評估網路安全風險，並確保在設計、開發、生產和維護等各個環節都採取措施應對這些風險。該法規還要求將此評估結果記錄在案、持續維護，並體現在產品的運作方式中。實際上，評估結果僅以文件形式存在，而執行則依賴外部控制。逆向工程被認定為風險，但目前尚無有效機制來阻止它。運行時篡改也被承認，但檢測依賴基礎設施訊號，而這些訊號無法直接觀測到。 

Digital.ai 應用安全性透過將風險評估結果嵌入到應用程式本身來彌補這一漏洞。如果評估識別出逆向工程威脅，混淆技術會直接增強對這種活動的防禦能力。如果識別出篡改行為，防篡改機制會確保偵測並阻止修改後的執行路徑。如果敏感資產面臨風險，它們會在應用程式內部受到保護，從而無法透過靜態或動態分析提取出來。 

這就在CRA要求和產品行為之間建立了直接聯繫。該法規要求將風險降至最低，並防止事故發生或降低事故影響。只有當應用程式在執行過程中強制執行這些條件時，才能滿足此要求。 Digital.ai 應用安全部門不負責風險評估或維護合規性文件。它確保在應用程式的實際運作過程中，也就是法規最終接受檢驗的時候，能夠落實評估結論。 

該法規承認補丁缺口，但大多數架構並未承認。 

附件一第二部分要求立即修復漏洞，並有效分發安全性更新。該部分還要求進行持續測試、協調揭露，並建立更新交付機制。該法規承認漏洞的存在，並需逐步處理，但不假定立即修復。這就在漏洞揭露和全面採用修補程式之間形成了一個已知的暴露窗口期。在此期間，漏洞公開，利用技術可用，已部署的實例仍未打補丁。 

Digital.ai 應用程式安全（AppSec）降低了漏洞在此期間被利用的可能性。如果利用漏洞需要理解其邏輯，混淆技術會增加定位和解讀該邏輯所需的時間。如果利用漏洞需要修改執行過程，防篡改機制會阻止被修改的行為。如果利用漏洞依賴觀察執行時間行為，保護措施會幹擾用於執行該觀察值的工具。這改變了漏洞的實際影響。漏洞仍然存在，但更難被大規模利用。 

Digital.ai 應用程式安全並不能取代漏洞管理、安全營運手冊 (SBOM) 產生或修補程式分發。這些功能對於履行合規性審查 (CRA) 義務仍然必不可少。應用安全主要針對這些功能無法及時消除風險的情況。 

第十四條要求提供證據，而非臆測。 

CRA明確規定了針對已被積極利用的漏洞和嚴重事件的報告義務，並設定了通知和後續行動的時限。已被積極利用的漏洞是指有可靠證據顯示有惡意使用的漏洞。嚴重事件包括惡意程式碼被引入或產品安全性受到實質影響的情況。大多數組織無法僅憑現有的遙測資料滿足此要求。基礎設施日誌顯示請求，網路監控顯示流量模式，但兩者都無法顯示記憶體中的函數被覆蓋或執行過程被透過監控手段篡改。 

以一款標準的手機銀行應用程式為例，客戶端的驗證功能可以在運作時被重寫，從而允許原本會被阻止的交易繼續進行。該應用程式會持續發出完全符合後端預期的請求。這些請求在結構上仍然有效、經過身份驗證，並且與合法流量無法區分。基礎架構或網路日誌中均未出現任何異常。由於缺乏應用層面的偵測，因此無法證明攻擊已經發生。 Digital.ai 應用安全機制會在漏洞利用發生時發出訊號。當偵錯器附加到應用程式時，系統會偵測到它。當記憶體被修改時，系統會識別出這種變更。當執行行為偏離預期時，應用程式可以將其標記為異常。這為第 14 條規定所需的起點奠定了基礎。 

應用程式內部偵測到異常行為。該行為與已知的攻擊技術或漏洞相關聯。該事件將根據 CRA 對攻擊的定義進行驗證。它將被歸類為正在被利用的漏洞或嚴重事件。隨後，將在規定的 24 小時和 72 小時窗口期間提交報告。如果沒有應用程式層級的偵測，此流程將無法啟動。 Digital.ai 應用安全並不能取代事件回應系統或監管報告流程，它只是為這些流程提供所需的證據。 

支持期會將風險擴大到工程控制範圍之外。 

CRA 要求製造商設定支援期限，並在整個支援期限內處理漏洞，大多數情況下至少為五年。它還要求在此期間持續提供安全性更新，並持續修復漏洞。實際上，已部署的軟體並不會統一使用最新版本。舊版本會在不同的裝置、環境和使用者行為中持續存在。攻擊者之所以會重點攻擊這些版本，是因為它們的行為穩定且為人所知。 

Digital.ai AppSec 確保這些保護措施在這些版本中持續有效。即使應用程式未更新，它仍會繼續執行完整性檢查、抵禦逆向工程並偵測篡改嘗試。這降低了利用已知漏洞攻擊長期部署應用程式的有效性。 

Digital.ai 應用程式安全不會延長支援期限或管理更新交付。它降低的是當支援期限與實際使用模式相符時所累積的風險。 

供應鏈風險只有在最終產品中才可利用。 

《消費者權益保護法》（CRA）要求製造商對第三方組件進行盡職調查，並解決整個產品中的漏洞。它還要求透過諸如軟體物料清單（SBOM）之類的機制識別元件，並修復在這些元件中發現的漏洞。該法規將產品視為一個整體，無論其組裝方式如何，都應承擔相應的責任。 

Digital.ai 應用安全正是在這種融合點發揮作用。如果攻擊者試圖透過分析應用程式來識別易受攻擊的元件，混淆技術會限制對程式碼結構的可見性。如果利用漏洞依賴在運行時操縱這些元件，那麼防篡改和運行時保護措施會幹擾這個過程。但這並不能消除供應鏈漏洞，而是降低了它們在部署環境中的可用性。 

Digital.ai 應用安全性不追蹤依賴項或管理軟體業務物件手冊 (SBOM)。它確保當這些依賴項引入風險時，應用程式不會輕易將其暴露給攻擊者。 

邊界處往往是混亂發生的地方。 

《網路彈性法案》涵蓋多個領域，包括設計要求、漏洞處理、報告、一致性評估和市場監管。 

Digital.ai Application Security 它能精準地在這些領域之一中運作。它在運行時強制執行應用程式的安全措施。它保護可執行檔免受分析，偵測篡改，並限制攻擊成功率。它產生可用於驗證攻擊事件的訊號。  

它不執行靜態分析、管理依賴項清單、產生軟體物料清單 (SBOM)、協調發布流程、分發修補程式或產生合規性文件。這些系統負責定義和管理合規性義務。 Digital.ai AppSec 確保當應用程式面臨對抗性條件時，這些義務仍然有效。 

最終視角 

《網路彈性法案》假定漏洞必然存在，攻擊者必然會利用這些漏洞，且產品必須在這些情況下保持安全。該法規對設計、生命週期管理和報告等方面都制定了要求，但執行則在運行時進行。當應用程式落入攻擊者手中，其行為被檢查和篡改，以及漏洞被積極利用時，合規性才算真正得到判定。 

Digital.ai Application Security 在該層面上，CRA（安全風險評估）發揮作用。它確保應用程式能夠抵禦分析、維護完整性、偵測攻擊嘗試，並降低漏洞在實際運行中的影響。這正是CRA實際接受測試的層面。