低代碼/無代碼工具允許非程序員用戶通過一組拖放式用戶界面來創(chuàng)建或修改應用程序，這樣用戶就可以開發(fā)新的數(shù)據(jù)驅動的應用程序，而無需依賴傳統(tǒng)的開發(fā)團隊。低代碼/無代碼開發(fā)使企業(yè)能夠通過使用預構建的應用程序組件“塊”輕松創(chuàng)建可快速部署的應用程序。

【資料圖】

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

另一組是傳統(tǒng)的開發(fā)人員，他們使用這些預構建的模塊來簡化他們的工作，并幫助他們更快地將關鍵業(yè)務的預構建應用程序組件組合在一起。Mendix最近發(fā)布的一項調(diào)查[2]顯示，64%的IT專業(yè)人員贊成將低代碼作為他們的首選解決方案。

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

— 1 —

低代碼/無代碼的風險

與軟件供應鏈相關的業(yè)務風險也存在于低代碼/無代碼世界，因為它們也是傳統(tǒng)的開發(fā)范式，如基于容器的架構或無服務器計算。

任何范式的實現(xiàn)都依賴于他們使用的框架是基于安全的前提。換句話說，假設他們不具備任何在發(fā)生網(wǎng)絡安全事件時可能影響監(jiān)管合規(guī)性或直接影響商業(yè)信譽的欺詐能力。

比如以容器世界為例，我們看到了大量的相關報道：一些惡意用戶在容器鏡像中植入挖礦軟件，然后將惡意軟件發(fā)布到公共Docker注冊表中。這是一只肥羊，從一些知名注冊中心拉容器的用戶很少檢查。但是，如果不仔細檢查容器映像的內(nèi)容，任何引用它們的部署都將為各種網(wǎng)絡威脅打開大門，包括可能影響數(shù)據(jù)保護的意外功能。

這也是軟件供應鏈會成為網(wǎng)絡安全團隊首要考慮的原因之一。

— 2 —

搭建第三方API的交互

過去的2021年告訴我們關于軟件的一件事是，供應鏈是復雜的，攻擊者會利用我們對一些開發(fā)范式的信任，不斷尋找機會。

低代碼/無代碼產(chǎn)品的推出給平民開發(fā)者帶來的安全風險可能比用戶自己意識到的更復雜。

一個平民開發(fā)人員可能知道他的應用程序的數(shù)據(jù)隱私要求，但是他可能不完全理解腳手架如何與第三方API交互，這使得他的組織很容易在無意中違反一些遵從要求。

例如，《加州隱私法》(CPRA)定義了幾個新的個人身份信息類別(PII ),并將數(shù)據(jù)傳輸要求擴展到了《加州消費者隱私法》(CCPA)的定義之外。熟悉CCPA需求并使用低/無代碼框架的平民開發(fā)者可能不理解如何正確處理這些新需求，甚至不理解腳手架如何解決這些問題。

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

對一些常見的安全框架(如NIST 800-218 1.1、安全軟件開發(fā)框架等)進行了全面的安全審計。);

提供供應商給出的軟件物料清單(SBOM)，用于描述支持低代碼/無代碼框架的軟件供應鏈的復雜程度；

審計數(shù)據(jù)傳輸實踐和API使用，以確認數(shù)據(jù)操作的監(jiān)管影響；

了解低/無代碼供應商提供的漏洞管理相關補丁的服務水平協(xié)議(SLA)。

— 3 —

底層還是代碼。

雖然低代碼/無代碼框架為開發(fā)者和平民開發(fā)者提供了一個簡單的開發(fā)范式，但他們?nèi)匀恍枰a的支持。術語“低代碼”和“無代碼”表示用戶需要知道多少代碼細節(jié)，而不是它們包含多少代碼。

像所有現(xiàn)代軟件一樣，低代碼無代碼框架也是基于許多來源的代碼庫構建的：商業(yè)化的第三方供應商、開源組件和云API服務。這些元素中的每一個都可以代表一個獨立的代碼學校，每個學校都有自己的代碼流。它們放在一起就構成了現(xiàn)代服務供應鏈，所以任何破壞供應鏈的行為都可以被視為供應鏈攻擊。

這就是為什么理解軟件供應鏈如此重要，即使對于低代碼或無代碼框架也是如此。在底部，這些應用程序仍然由代碼支持。如果框架提供者不能管理相關的風險，他們的消費者最終仍將承擔這些風險。

標簽：