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

低代碼/無代碼工具通過一套拖拽式的用戶界面，允許非程序員用戶創(chuàng)建或修改應(yīng)用程序，使得用戶無需依賴傳統(tǒng)的開發(fā)團(tuán)隊(duì)即可開發(fā)新的數(shù)據(jù)驅(qū)動(dòng)型應(yīng)用程序。低代碼/無代碼開發(fā)讓企業(yè)得以通過使用預(yù)構(gòu)建好的應(yīng)用程序組件“塊”，輕松地創(chuàng)建出能夠快速部署的應(yīng)用程序。

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

另外一組則是傳統(tǒng)的開發(fā)人員，他們使用這些預(yù)構(gòu)建的塊來簡化自己的工作，幫助他們更快地將關(guān)鍵業(yè)務(wù)的預(yù)構(gòu)建應(yīng)用程序組件組合到一起。Mendix 最近發(fā)布的一項(xiàng)調(diào)查顯示，64% 的 IT 專業(yè)人士認(rèn)可低代碼作為他們的首選解決方案。

在所有使用低代碼的項(xiàng)目里，有多達(dá) 59% 的項(xiàng)目是屬于業(yè)務(wù)和 IT 團(tuán)隊(duì)之間的協(xié)作，這意味著用戶需要像處理其他任意第三方代碼組件一樣考慮軟件供應(yīng)鏈里的低代碼/無代碼組件。

1. 低代碼/無代碼的風(fēng)險(xiǎn)

和軟件供應(yīng)鏈有關(guān)的業(yè)務(wù)風(fēng)險(xiǎn)在低代碼/無代碼的世界里同樣存在，因?yàn)樗鼈兺瑯邮腔谌萜鞯募軜?gòu)或是無服務(wù)器計(jì)算這些較為傳統(tǒng)的開發(fā)范式。

任何這些范式的實(shí)現(xiàn)都有賴于它們所使用的框架是建立在安全的基礎(chǔ)之上這一前提假設(shè)。換句話說，這假定了它們沒有任何可能影響監(jiān)管合規(guī)性或是在發(fā)生網(wǎng)絡(luò)安全事件時(shí)直接影響商業(yè)聲譽(yù)的造假能力。

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

這也是為什么軟件供應(yīng)鏈會(huì)成為網(wǎng)絡(luò)安全團(tuán)隊(duì)首要考慮因素的原因之一。

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

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

向平民開發(fā)者推出低代碼/無代碼產(chǎn)品將會(huì)帶來的安全風(fēng)險(xiǎn)，可能會(huì)比用戶自身意識到的要更加復(fù)雜。

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

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

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

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

3. 最底下的仍然是代碼

盡管低代碼/無代碼框架為開發(fā)人員和平民開發(fā)者提供了一種簡單的開發(fā)范式，它們卻仍然需要代碼的支持?！暗痛a”和“無代碼”術(shù)語代表著用戶需要知道多少程度的代碼細(xì)節(jié)，而不是說它們具體包含多少代碼。

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

這也即是為什么了解軟件供應(yīng)鏈?zhǔn)侨绱酥匾脑颍幢銓τ诘痛a或者無代碼的框架來說同樣如此。它們最底下仍然是靠代碼賦能了這些應(yīng)用程序，如果框架提供者沒有能力管理相關(guān)風(fēng)險(xiǎn)的話，那么最終承擔(dān)這些風(fēng)險(xiǎn)的仍然會(huì)是它們的消費(fèi)者。