什麼是低程式碼/無程式碼開發？
無程式碼工具和平臺使用拖放介面來允許業務分析師等非程式設計師建立或修改應用程式。在某些情況下，可能需要實際編碼（低程式碼）來與其他應用程式整合、生成報告或修改使用者介面。這通常使用 SQL 或 Python 等高階程式語言來完成。
低程式碼/無程式碼平臺的示例包括 Salesforce Lightning、FileMaker、Microsoft PowerApps 和 Google App Maker。這是使用此類平臺的四個最重要的安全問題。
1.低程式碼/無程式碼應用程式的可見性低
使用由外部方開發的平臺總是會帶來可見性問題。您正在使用該軟體，因此不知道原始碼、相關漏洞或平臺所經歷的潛在測試和嚴格程度。
這可以透過利用諸如向供應商請求軟體材料清單 (SBOM) 等做法來緩解。這將提供對其包含的軟體元件及其相關漏洞的洞察。SBOM 的使用正在上升，最新的Linux 基金會研究表明，78% 的組織計劃在 2022 年使用 SBOM。也就是說，SBOM 的使用仍在成熟，該行業還有很大的發展空間規範實踐、流程和工具。
2.不安全的程式碼
與可見性問題相吻合的是不安全程式碼的可能性。低程式碼和無程式碼平臺仍然有程式碼；他們只是抽象了編碼並允許終端使用者使用預先提供的程式碼功能。這很棒，因為它使非開發人員無需自己編寫程式碼。當使用的程式碼不安全並且透過低程式碼和無程式碼平臺跨組織和應用程式推斷時，就會出現問題。
解決此問題的一種方法是與平臺供應商合作，要求平臺內使用的程式碼的安全掃描結果。靜態和動態應用程式安全測試 (SAST/DAST) 等掃描結果可以為消費者提供一定程度的保證，即他們不僅僅是在複製不安全的程式碼。在組織控制之外建立程式碼的想法並不是一個新概念，並且在開源軟體的猖獗使用中很普遍，超過 98% 的組織使用開源軟體，並且與其他儲存庫相關的軟體供應鏈威脅也是如此，例如用於基礎設施即程式碼 (IaC) 模板的那些。
要考慮的另一個方面是，許多低程式碼和無程式碼平臺都是作為軟體即服務 (SaaS) 交付的。這使您可以向供應商申請行業認證，例如 ISO、SOC2、FedRAMP 和其他認證。這為組織的運營和適用於 SaaS 應用程式/平臺本身的安全控制提供了進一步的保證。
SaaS 應用程式本身存在許多安全風險，需要適當的治理和嚴格的安全措施。如果不正確審查您的組織正在使用的 SaaS 應用程式和平臺，您可能會使組織面臨不適當的風險。如果使用低程式碼和無程式碼平臺開發會暴露敏感組織或客戶資料的應用程式，這種情況會進一步加劇。
3、失控的影子IT
由於低程式碼和無程式碼平臺允許快速建立應用程式，即使是那些沒有開發背景的人，也可能導致影子 IT 猖獗。影子 IT 發生在業務部門和員工建立應用程式並將它們在組織內部或外部向世界公開時。這些應用程式可能包含敏感的組織、客戶或受監管資料，如果這些應用程式在資料洩露中受到損害，可能會對組織產生一系列影響。
4. 業務中斷
從業務連續性的角度來看，如果平臺出現中斷，依賴作為服務交付的低程式碼和無程式碼平臺可能會中斷業務。對於組織而言，為關鍵業務應用程式（包括低程式碼和無程式碼平臺）建立服務水平協議 (SLA) 非常重要。
降低低程式碼/無程式碼開發風險的技巧
無論涉及何種技術，通用安全最佳實踐都可以減輕上述風險，包括：
從具有受人尊敬的行業聲譽的可信賴供應商處購買軟體和平臺。
確保這些供應商擁有第三方認證證照，以代表其內部安全實踐和流程。
在您的應用程式和軟體清單中考慮低程式碼和無程式碼平臺，以及透過使用它們建立的應用程式。
保持良好的訪問控制；知道誰在訪問平臺以及他們被允許執行哪些活動。
實施安全資料實踐以瞭解您的關鍵資料所在的位置，以及使用低程式碼和無程式碼平臺建立的應用程式是否包含敏感資料。
瞭解低程式碼/無程式碼平臺的託管位置。這些平臺是否託管在 AWS、Google 或 Microsoft Azure 等超大規模全球雲服務提供商 (CSP) 中？或者它們是否託管在傳統的本地資料中心中，僅限於沒有物理和邏輯訪問控制？
考慮組織的安全文化也很重要。雖然平臺使用者可能不是行業的開發人員或安全專家，但他們應該瞭解他們正在使用和建立的低程式碼和無程式碼平臺和應用程式的安全含義。正如他們所說，強大的力量伴隨著巨大的責任，這適用於低程式碼和無程式碼平臺。