低代碼和無代碼開發的4個安全問題

李匯

低代碼并不意味著低風險，企業鼓勵更多人員開發應用程序，然而低代碼開發會產生新的漏洞，并可能出現隱藏的安全問題。

如今，公民開發者的積極性越來越高，同時企業也希望由非開發者開發和創建應用程序，這通常使用低代碼或無代碼框架來促進。這些框架和工具允許非開發人員使用GUI來獲取和移動組件，以制作業務邏輯友好的應用程序。

授權更廣泛的IT和業務社區創建應用程序以推動業務價值具有明顯的吸引力。也就是說，使用低代碼和無代碼平臺并非沒有安全問題，就像任何其他軟件產品一樣，開發平臺及其相關代碼的嚴謹性是一個不容忽視的問題。

低代碼和無代碼開發

無代碼工具和平臺使用拖放界面來允許業務分析師等非編程人員創建或修改應用程序。在某些情況下，可能需要編碼（低代碼）來與其他應用程序集成、生成報告或修改用戶界面。這通常使用SQL或Python等高級編程語言來完成。

低代碼/無代碼平臺的示例包括Salesforce Lightning，FileMaker，Microsoft PowerApps，Google App Maker。以下是使用此類平臺時應該注意的重要安全問題。

低代碼/無代碼應用程序的可見性低

使用由外部開發的平臺總是會帶來可見性問題。很多人使用這些軟件，卻不了解源代碼、相關漏洞或平臺所經歷的潛在測試和嚴格程度。

這可以通過利用向供應商申請軟件物料清單（SBOM）等做法來緩解。這將提供對其包含的軟件組件及其相關漏洞的深入了解。使用最新的Linux基礎研究表明，78 %的企業計劃在2022年使用軟件物料清單。盡管如此，軟件物料清單的使用仍在發展，該行業還有很大的發展空間規范實踐、流程和工具。

不安全的代碼

與可見性問題相吻合的是不安全代碼的可能性。低代碼和無代碼平臺仍然有代碼。他們只是抽象了編碼，并允許最終用戶使用預先提供的代碼功能。這很好，因為它使非開發人員無需自己編寫代碼。當使用的代碼是不安全的，通過低代碼和無代碼平臺在企業和應用程序之間進行推斷時，就可能會出現問題。

解決這個問題的一種方法是與平臺供應商合作，要求平臺內使用的代碼有安全掃描。靜態和動態應用程序安全測試（SAST/DAST）等掃描結果可以為消費者提供一定程度的保證，即他們不僅僅是復制不安全的代碼。在企業控制之外創建代碼的想法并不是一個新概念，并且在開源軟件的使用中很普遍，98 %以上的企業使用開源軟件，并且與其他存儲庫相關的軟件供應鏈威脅也很常見，例如用于基礎設施的代碼（IaC）模板。

另一個要考慮的方面是，許多低代碼和無代碼平臺都是以SaaS方式交付的。這使企業可以向供應商申請行業認證，例如ISO、SOC2、FedRAMP和其他認證。這為企業的運營和適用于SaaS應用程序/平臺，本身的安全控制提供了進一步的保證。

SaaS應用程序本身存在許多安全風險，需要適當的治理和嚴格的安全性。如果沒有對企業正在使用的SaaS應用程序和平臺進行適當的審查，可能會讓其業務面臨不必要的風險。

失控的影子IT

由于低代碼和無代碼平臺允許快速創建應用程序，即使是那些沒有開發背景的人員，也可能導致影子IT的泛濫。影子IT發生在業務部門和員工創建應用程序并將它們用在企業內部或外部時。這些應用程序可能包含企業和客戶敏感的或受監管的數據，如果這些應用程序在數據泄露中受到損害，可能會對企業產生一系列影響。

業務中斷

從業務連續性的角度來看，如果平臺出現中斷，作為服務交付的低代碼和無代碼平臺可能會中斷業務。對于企業而言，為關鍵業務應用程序（包括低代碼和無代碼平臺）建立服務水平協議（SLA）非常重要。

降低低代碼/無代碼開發風險的技巧

無論涉及何種技術，通用的安全最佳實踐都可以減輕開發風險，其中包括：

①從行業聲譽良好的值得信賴的供應商那里購買軟件和平臺；

②確保這些供應商擁有第三方認證證書，以代表其內部安全實踐和流程；

③在企業的應用程序和軟件清單中考慮低代碼和無代碼平臺，以及通過使用它們創建的應用程序；

④保持良好的訪問控制，知道誰在訪問平臺以及他們被允許執行哪些活動。

⑤實施安全數據實踐，以了解關鍵數據所在的位置，使用低代碼和無代碼平臺創建的應用程序是否包含敏感數據。

⑥了解托管低代碼/無代碼平臺的位置。這些平臺是否托管在AWS、Google或Microsoft Azure等超大規模全球云服務提供商的云平臺中？或者它們是否托管在內部部署數據中心中，僅限于沒有物理和邏輯訪問控制？