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

01.

低可見性（Low visibility）

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

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

02.

平臺組件安全漏洞

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

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

03.

業(yè)務邏輯風險

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

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

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

首先，技術(shù)方面

1.借助第三方測試工具

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

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

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

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

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

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

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

其次，流程控制方面

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

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

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

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

結(jié)語

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

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