如何解決低代碼平臺中的安全問題？

在過去幾年里，低代碼和無代碼工具及平臺的興起席卷了企業領域的方方面面。Gartner 2021 年魔力象限報告稱，在低代碼這塊，41% 的非 IT 從業人員使用低代碼/無代碼工具定制或構建數據或技術解決方案。Gartner 預測，到 2025 年底，將會有一半的低代碼新客戶是來自于 IT 組織之外的商業買家。

低代碼/無代碼工具通過一套拖拽式的用戶界面，允許非程序員用戶創建或修改應用程序，使得用戶無需依賴傳統的開發團隊即可開發新的數據驅動型應用程序。低代碼/無代碼開發讓企業得以通過使用預構建好的應用程序組件“塊”，輕松地創建出能夠快速部署的應用程序。

低/無代碼工具及平臺的目標用戶是兩組完全不同的人群。一組是非技術人員，有時被稱作是“平民開發者”，他們使用這些工具來創建自己的應用程序，通常是為了簡化他們的工作流程然后連接一些可能無法相互通信的產品。

另外一組則是傳統的開發人員，他們使用這些預構建的塊來簡化自己的工作，幫助他們更快地將關鍵業務的預構建應用程序組件組合到一起。Mendix 最近發布的一項調查顯示，64% 的 IT 專業人士認可低代碼作為他們的首選解決方案。

在所有使用低代碼的項目里，有多達 59% 的項目是屬于業務和 IT 團隊之間的協作，這意味著用戶需要像處理其他任意第三方代碼組件一樣考慮軟件供應鏈里的低代碼/無代碼組件。

1. 低代碼/無代碼的風險

和軟件供應鏈有關的業務風險在低代碼/無代碼的世界里同樣存在，因為它們同樣是基于容器的架構或是無服務器計算這些較為傳統的開發范式。

任何這些范式的實現都有賴于它們所使用的框架是建立在安全的基礎之上這一前提假設。換句話說，這假定了它們沒有任何可能影響監管合規性或是在發生網絡安全事件時直接影響商業聲譽的造假能力。

舉個例子，拿容器世界作個示范，我們已經看到了相關的大量報道：一些惡意用戶在容器鏡像里植入了挖礦軟件然后將這些惡意軟件發布到公共的 Docker 注冊表。這可是一只肥羊，那些從一些知名的注冊表拉取容器的用戶很少會去檢查它們。然而如果沒有仔細檢查容器鏡像里面的內容的話，任何部署，只要引用了它們，也就等于為各種網絡威脅敞開了大門，這里面還包括了可能會影響數據保護的意想不到的功能。

這也是為什么軟件供應鏈會成為網絡安全團隊首要考慮因素的原因之一。

2. 將第三方 API 的交互腳手架化

過去的 2021 年在軟件方面教會我們的一件事情就是，供應鏈很復雜，而且攻擊者會利用我們對于一些開發范式的信任不斷尋找可乘之機。

向平民開發者推出低代碼/無代碼產品將會帶來的安全風險，可能會比用戶自身意識到的要更加復雜。

一個平民開發者也許知道其應用程序的數據隱私要求，但是他未必能完全清楚腳手架是如何與第三方 API 交互的，從而使他們的組織很容易無意中就違反了一些合規性要求。

比如，加州隱私權法案（CPRA）定義了幾個新的個人身份信息（PII）類別，并將數據傳輸要求擴展到加州消費者隱私法案（CCPA）定義的范疇之外。熟悉 CCPA 要求并且使用低/無代碼框架的平民開發者可能不理解如何正確處理這些新的需求，甚至對于腳手架是如何解決這些問題也并不是很清楚。

投資低代碼/無代碼解決方案的一些組織應當在其選擇供應商的過程中涵蓋以下部分：

• 執行過一些常見的安全框架（如 NIST 800-218 1.1，安全軟件開發框架等）的全面安全審核；
• 提供一份由供應商給出的軟件物料清單（SBOM），用于描述支持低代碼/無代碼框架的軟件供應鏈的復雜性；
• 審核數據傳輸實踐以及 API 的使用以確認數據操作的監管影響；
• 了解低/無代碼供應商提供的與漏洞管理工作相關的補丁的服務級別協議（SLA）。

3. 最底下的仍然是代碼

盡管低代碼/無代碼框架為開發人員和平民開發者提供了一種簡單的開發范式，它們卻仍然需要代碼的支持。“低代碼”和“無代碼”術語代表著用戶需要知道多少程度的代碼細節，而不是說它們具體包含多少代碼。

和所有現代軟件一樣，低代碼\無代碼框架同樣也是基于多種來源的代碼庫構建的：已經商業化的第三方供應商、開源組件以及云 API 服務。這些元素中的每一個都可以代表一門獨立的代碼流派，每個流派都擁有屬于自己的代碼流。將它們放到一起，也就構成了一個現代服務的供應鏈，因此任何損害該供應鏈的行為都可以看作是一次供應鏈攻擊。

這也即是為什么了解軟件供應鏈是如此重要的原因，即便對于低代碼或者無代碼的框架來說同樣如此。它們最底下仍然是靠代碼賦能了這些應用程序，如果框架提供者沒有能力管理相關風險的話，那么最終承擔這些風險的仍然會是它們的消費者。

來源：飛馬網

原文鏈接：https://coffee.pmcaff.com/article/zmLW5x5RBG