與傳統(tǒng)開發(fā)模式相比，低代碼平臺在應(yīng)用開發(fā)效率、易用性和釋放生產(chǎn)力方面為專業(yè)和公民開發(fā)人員帶來巨大優(yōu)勢，一改傳統(tǒng)開發(fā)冗長復(fù)雜的固化流程，幫助企業(yè)快速建立“敏捷能力”。然而，與任何新興技術(shù)一樣，企業(yè)和IT團隊需要意識到伴隨它們的潛在安全風(fēng)險。

01.

低可見性（Low visibility）

一般來說，大型公司中的IT團隊擁有嚴(yán)格的安全實踐準(zhǔn)則、風(fēng)險預(yù)防措施和標(biāo)準(zhǔn)化工作流程，以保證應(yīng)用程序的安全性。但是許多利用低代碼平臺開發(fā)的應(yīng)用程序，可能沒辦法遵循這些準(zhǔn)則，因為低代碼廠商提供的封裝代碼模塊是無法被開發(fā)者檢查測試的，開發(fā)過程類似于“黑箱狀態(tài)”，只能通過低代碼平臺內(nèi)置的組件和流程來大致檢查其內(nèi)在邏輯是否相容。尤其是對于公民開發(fā)者來說，缺少開發(fā)技術(shù)的他們就更無法保證應(yīng)用程序的安全性了。

由于核心代碼在低代碼廠商手里，一旦應(yīng)用出現(xiàn)bug，企業(yè)將很難及時進(jìn)行排查和解決。當(dāng)?shù)痛a無法保證安全控制時，企業(yè)又不得不采購額外的安全管理工具，造成低代碼應(yīng)用運維成本高昂，甚至可能高于傳統(tǒng)開發(fā)。

02.

平臺組件安全漏洞

沒有一款產(chǎn)品是完美的，如果低代碼平臺的組件開發(fā)得不夠完善，這將會產(chǎn)生潛在的安全問題。有漏洞的代碼片段不可避免地會被復(fù)制粘貼到其他地方。尤其是對于沒有開發(fā)經(jīng)驗的公民開發(fā)者來說，他們的首要目標(biāo)是保證應(yīng)用程序的正常運行。在此過程中，任何bug和安全問題都會被低代碼平臺開發(fā)出的應(yīng)用所繼承。

目前市場上多數(shù)低代碼平臺組件對客戶都是透明公開的。但也有一些低代碼平臺不提供其整體平臺的開源訪問權(quán)限。因此，客戶需要自己去購買第三方審安全審查服務(wù)，浪費不必要的成本和時間。現(xiàn)在有不少低代碼供應(yīng)商通過提供可訪問和透明的審計方法來改善風(fēng)險管理服務(wù)，如此一來，企業(yè)將能夠避免在第三方安全工具上的昂貴支出。

03.

業(yè)務(wù)邏輯風(fēng)險

當(dāng)人們從商業(yè)的角度看待軟件開發(fā)，而忽略了信息技術(shù)的一面時，問題就出現(xiàn)了。由于利用低代碼平臺開發(fā)程序是如此的簡單，在這種情況下，開發(fā)者可能會不小心忽視傳統(tǒng)開發(fā)流程中的安全問題，而公民開發(fā)者往往安全意識淡薄，最終難免會犯錯誤。人為錯誤引發(fā)的業(yè)務(wù)邏輯問題是無法被安全工具檢測到的，如果忘記了什么，敏感數(shù)據(jù)就有可能暴露給錯誤的人，并通過API連接進(jìn)一步擴大應(yīng)用程序的威脅面。

隨著IT團隊的不斷擴展，杜絕人為的業(yè)務(wù)邏輯風(fēng)險這種低級錯誤必須成為企業(yè)采用低代碼平臺時的首要任務(wù)。在傳統(tǒng)的軟件開發(fā)中，企業(yè)一般已經(jīng)有了安全流程來保證開發(fā)過程的標(biāo)準(zhǔn)化。低代碼平臺應(yīng)該考慮將企業(yè)的安全標(biāo)準(zhǔn)擴展到低代碼開發(fā)環(huán)境中以確保企業(yè)的風(fēng)險管理需求得到滿足。

那么企業(yè)應(yīng)該如何避免低代碼安全風(fēng)險呢？本文將從技術(shù)方面和流程控制方面展開聊聊。

首先，技術(shù)方面

1.借助第三方測試工具

有一些測試工具可用于檢測應(yīng)用程序平臺中的安全漏洞。由于手動測試和調(diào)試是不總是可行的，自動化工具會大幅提升效率。

A. OWASP ZAP: 由OWASP(Open Web Application Security Project)開發(fā)，ZAP(Zed Attack Proxy)是一個跨平臺、開源的安全測試工具。它通過測試攔截代理服務(wù)器、傳統(tǒng)和AJAXWeb爬蟲、自動掃描器、被動掃描器、強制瀏覽、模糊測試、WebSocket支持、腳本語言和plug-n-hack支持等，來用于在開發(fā)和測試階段發(fā)現(xiàn)web應(yīng)用程序中的安全漏洞。豐富經(jīng)驗的專業(yè)人士和初學(xué)者均可靈活使用。

B. W3af: Python開發(fā)最流行的安全測試框架之一是W3af。它能夠幫助測試人員在web應(yīng)用程序中發(fā)現(xiàn)200多種類型的安全問題，包括盲SQL注入、緩沖區(qū)溢出、跨站點腳本、CSRF和不安全的DAV配置。

C. SonarQube：它是一個開源測試工具，能夠進(jìn)行代碼分析和檢查安全漏洞。SonarQube用Java編寫，可以分辨20多種編程語言的漏洞，包括跨站點腳本、拒絕服務(wù)(DoS)攻擊、HTTP響應(yīng)分裂、內(nèi)存損壞和SQL注入等。此外，它很容易與持續(xù)集成工具集成，例如Jenkins和TeamCity。

2.檢查云基礎(chǔ)設(shè)施安全性和開源漏洞

云服務(wù)和開源平臺這些基礎(chǔ)設(shè)施漏洞同樣不可忽視。并非所有低代碼平臺都是商業(yè)化的，還有許多開源平臺，開源低代碼平臺可能依賴于許多插件和第三方集成，即使我們的源代碼不構(gòu)成任何安全威脅，插件和集成也可能帶來大量風(fēng)險。保護應(yīng)用程序免受此類攻擊是非常必要的，例如 WhiteSource Bolt可作為開源平臺的測試工具。

大多數(shù)低代碼平臺都提供公有云服務(wù)器部署，但是與私有云相比，公有云更需要注意其安全風(fēng)險，大多數(shù)公有云都包含驗證基礎(chǔ)架構(gòu)安全性的工具?？梢允褂肅I/CD工具來完成，這些工具提供了針對惡意軟件的持續(xù)保護。Jenkins是開發(fā)人員中流行的開源CI/CD選擇，可幫助開發(fā)人員快速查找和解決代碼庫中的問題并自動測試其構(gòu)建。

其次，流程控制方面

首先企業(yè)應(yīng)該謹(jǐn)慎選擇低代碼供應(yīng)商和合作伙伴，選擇安全流程清晰透明的平臺。企業(yè)應(yīng)該對選擇的任何低代碼平臺進(jìn)行評估審計，包括漏洞掃描、進(jìn)行滲透測試等。深入了解低代碼平臺的安全實踐方法，了解他們使用的是什么技術(shù)，SAST、DAST還是IAST？

另外，無論大中小企業(yè)，都應(yīng)該注意對公民開發(fā)者的培訓(xùn)，確保他們謹(jǐn)記安全開發(fā)流程，提高風(fēng)險意識。在部署低代碼應(yīng)用程序之前，開發(fā)者應(yīng)該咨詢他們的信息技術(shù)部門和網(wǎng)絡(luò)安全團隊，開發(fā)人員需要遵循包括端口安全在內(nèi)的最佳實踐，注意應(yīng)用程序處理的數(shù)據(jù)類型，并設(shè)置防火墻來防止SQL注入和其他攻擊。

一個容易被忽略的可能暴露企業(yè)敏感數(shù)據(jù)的漏洞是API接口。低代碼平臺通常會通過大量的API來傳遞數(shù)據(jù)，API安全性不能被忽視。企業(yè)可通過身份驗證和令牌，或者使用API網(wǎng)關(guān)來保護API和REST調(diào)用。

對于大企業(yè)來說，適當(dāng)提高預(yù)算來選擇安全性更高的低代碼平臺是一勞永逸的事情。例如，ServiceNow的Security Operations產(chǎn)品通過在其平臺中內(nèi)置的安全控件和AI能力，能夠?qū)崟r監(jiān)控各個流程節(jié)點的動態(tài)和技術(shù)指標(biāo)，實現(xiàn)風(fēng)險提前預(yù)警、快速響應(yīng)。對小企業(yè)來說，更需要的是加強組織的安全意識和規(guī)范操作流程。

結(jié)語

低代碼平臺對開發(fā)者和尋求數(shù)字化轉(zhuǎn)型的企業(yè)來說是一個福音，但是有各種各樣的陷阱需要警惕，其中最重要的是安全風(fēng)險。大部分低代碼平臺的安全問題都可以通過正確合規(guī)的流程來有效規(guī)避。開發(fā)效率的提高，沒有嚴(yán)格的技術(shù)要求，易于部署，這些低代碼獨有的優(yōu)勢值得企業(yè)付出一些前期審查的成本。

來源：低代碼LowCode，微信號：do1didaima