低程式碼/無程式碼開發有望彌合存在於偉大想法和數位創新絕佳執行之間的開發待辦事項清單鴻溝。然而，若沒有關於存取控制、程式碼品質和應用程式可見度等方面的安全政策，該鴻溝的彌合便無法辦到。

文／Ericka Chickowski‧ 譯／酷魯

低程式碼/無程式碼開發有望彌合存在於偉大想法和數位創新絕佳執行之間的開發待辦事項清單鴻溝。然而，若沒有關於存取控制、程式碼品質和應用程式可見度等方面的安全政策，該鴻溝的彌合便無法辦到。在專業程式碼開發人員的手中，低程式碼開發平台可以加速開發週期。與此同時，一般商務使用者也可以利用無程式碼工具使自己成為公民開發者（citizen developer，亦翻作「平民開發者」），如此一來他們便能快速開發應用程式來自動執行任務，將現有應用程式連接在一起，抑或進行軟體客製化以完全滿足自身需求。

然而，所有這些彈性之舉都可能導致安全成本的增加。如果沒有適當的安全政策和控制機制，低程式碼/無程式碼可能會加劇現有的應用程式安全問題，並有可能侵蝕有關存取控制、程式碼品質和應用程式等方面可見度的安全性。儘管人們一開始的直覺反應可能會完全禁止低程式碼/無程式碼開發，但現實情況是，這是一場資安長（CISO）無法贏得的戰鬥，低程式碼/無程式碼安全公司 Zenity 共同創辦人兼技術長（CTO） Michael Bargury 表示。

[ 推薦文章：【CDO專欄】低碼程式與公民開發者 ]

「你無法對抗這個趨勢，」身為 OWASP 低程式碼/無程式碼十大清單共同作者的 Bargury 表示。「我看到一些組織最常嘗試兩種做法，不是抱持『低程式碼和無程式碼在這裡不會發生』的想法，就是採取『我們將允許它，但只能在這個平台上』的說法。身為安全領導者，你可以用這些方法說服自己，但這種方法就像多年前禁止人們攜帶自己裝置上班連網一樣無效。」

相反的，他和其他具有前瞻性的應用程式安全倡導者一致建議，組織應開始制定可執行的低程式碼/無程式碼開發政策，並建立適當的流程和技術來管理開發環境中的最大風險。以下是安全領導者應考慮的 10 大低程式碼/無程式碼安全政策。

1.可接受的使用案例目的和範圍政策

與許多安全實踐一樣，在確定和執行政策之前，組織最好對現狀進行稽核和記錄。並且評估專業程式碼開發人員和商務使用者在企業中運用低程式碼和無程式碼技術的狀況，務必深入探索一切。

Bargury 警告說，許多資安長和技術領導者並未意識到低程式碼和無程式碼在當前環境中已經有多麼普遍。因此評估上，不僅應該注意已知的企業級無程式碼/低程式碼平台，還應該對精通技術的商務使用者在 IT 範圍之外可能買單的較小專業產消者（prosumer）選擇保持關注。此外，該評估還應該在現有 SaaS 軟體即服務供應商和軟體平台供應商中，找出能將無程式碼/低程式碼功能直接嵌入自家產品中，以便讓使用者能在沒有開發團隊參與的情況下，自行客製化和新增連接器（connector）的供應商。

這中間可以學到的教訓就是務必徹底評估，然後對現有的使用案例進行記錄和定義。了解為什麼某些用戶群正在利用特定的低程式碼/無程式碼平台，將有助於安全和業務領導者進行風險計算，進而確定未來政策的方針路線。經由這項工作而產生的最直接政策莫過於，定義出整個業務中低程式碼/無程式碼可接受的使用案例。

「務必明訂低程式碼和無程式碼開發的跨部門應用範疇，並明確說明低程式碼和無程式碼開發的目的，」開發顧問公司 TechAhead 執行長 Vikas Kaushik 表示。這種明訂目的和範圍的政策對於設定以使用案例為核心之風險管理政策的方針和基調至關重要。一些公司可能會選擇對此進行極精細的劃分，亦即按業務範圍、業務功能、用戶群或使用者團隊進行細分。其他公司則可能僅僅劃分成專業開發人員和所謂的公民開發者（亦即精通技術的業務利益相關者）。

[ CSO 都在讀：安全性能指標對資安長的 10 個好處 ]

2. 平台審查政策

不論從功能的角度，還是從安全成熟度的角度來看，並非所有低程式碼/無程式碼平台或 SaaS 擴充都是平等的。「當前開箱即用的低程式碼平台成熟度充其量還處於萌芽階段，」程式碼安全平台供應商 GitGuardian 安全專家 Thomas Segura 解釋道。「許多平台本身並不包含確保遵循嚴格法規和標準所需的強健安全功能。它們通常缺乏複雜的資料治理工具、全面性的稽核追蹤以及必要的加密標準來充份保護敏感資訊。由於安全成熟度不足，致使企業組織在採用這些平台時需要額外的措施與步驟來加強安全性和合規性。」

當前企業組織想要制定的第一套政策之一莫過於，在平台被批准使用之前，將對平台進行多少審查和什麼樣的審查。這將幫助他們確定每個平台上有多少會提高其風險閾值的安全缺口，並決定是否值得投入一切。評估政策應該規定組織不僅要檢查平台的安全功能和合規控制，還要檢查平台本身的安全狀態。這可能包括要求提供文件紀錄，並可能請求進行滲透測試的許可，經驗豐富的安全顧問兼 AI 風險評估服務供應商 StackAware 創辦人Walter Haydock 解釋說，他最近在開發工作中使用了幾個低程式碼平台，並在他使用的平台中尋求這種保證。

「因此，以無程式碼軟體開發平台Bubble 為例，他們已經制定一項有關如何對其平台進行滲透測試的明確政策，」Haydock 說。「我採用了可擴展後端應用程式無程式碼開發工具 Xano 作為我的後端，該工具確實已通過 ISO 27001 認證。因此，他們已經對其安全計畫進行了正式的稽核，並且在其子流程和技術堆疊等方面非常透明。這給了我十足的信心。」

此外，安全團隊並且希望能標準化評估平台及其所產生應用程式如何處理敏感資料，以及平台如何與現有安全控制機制之間協同運作，GitGuardian 的 Segura 透露道。「組織應對他們考慮採用的任何平台進行嚴格的安全盡職調查，以防止資料和個人可識別資訊（PII）蔓延，確保這些平台能夠與現有安全基礎設施無縫整合，」Segura 表示。「在必要時，應優先考慮自建主機（self-hosting）解決方案，以保持對資料的完全控制權。」

3. 可接受的平台政策

一旦定義了使用案例，並對當前正在使用的平台進行了審查，企業就可以著手確定哪些無程式碼/低程式碼平台最適合啟用特定的使用案例。參與的平台越多，就越難管理平台內部的風險和由它們產生的應用程式。因此，從安全的角度來看，確保簡單明瞭的可接受平台清單會是理想的做法。「組織應該實施集中化開發和部署低程式碼應用程式的政策，以有效管理這些風險，」更喜歡選擇一個最符合內部和外部合規要求之平台的 Segura 表示。「這項政策將減輕影子 IT （shadow IT）的風險，確保統一的安全實踐，並簡化合規流程。」

然而，Bargury 警告說，在許多組織中，期望單一平台（甚至在一些大型企業中可能是二到三個平台）能夠充分滿足不同團隊和業務利益相關者的所有使用案例需求是不切實際的。他建議採用一種投資組合方法，能聚焦在以風險適中的方式來滿足使用者需求。他建議不妨根據當前的使用情況和業務需求來挑選幾個平台，並為這些平台提供開發和安全支援。就此一觀點來看，應該讓安全工程師肩負「鋪平道路」的使命——為公民開發者和專業開發者提供指導方針，讓他們在如何使用這些平台時難以做出不安全的選擇。這將需要為整個平台進行政策工作、配置工作、客製化和控制作業。這個想法是選擇工作量最少的平臺，同時仍然能滿足每個關鍵使用案例的需求。

作為此一系列政策的一部分，組織還應該定義何時可以在通用軟體平臺或 SaaS 服務中啟用嵌入式或附加低程式碼/無程式碼功能，以及在哪些情況下安全團隊將禁用這些擴充功能。例如，是否允許業務運行像 Salesforce 業務規則引擎之類的無程式碼規則自動化工具？該政策應該要明確釋疑並回答此類問題。

[ 加入 CIO Taiwan 官方 LINE 與 Facebook ，與全球CIO同步獲取精華見解 ]

4. 環境規範政策

Bargury 推薦的一種限制風險的策略是，為專業開發人員和業務開發人員提供個別不同環境的明確規定。理想情況下，當專業開發人員使用低程式碼工具來協助加速自身開發工作時，該開發工作的產出物仍將在一個安全的開發生命周期中運行。所以應該建立安全政策和程序，以便在開發生命周期的關鍵點實施安全和品質閘控，Bargury 表示，組織應該對開發人員從低程式碼平台上所擷取的內容進行運行時監控和其他控制。

與此同時，公民開發者的無程式碼工作流程可能會更寬鬆一些，因此，企業應該考慮實施有效的隔艙（bulkhead）機制。Bargury 說：「請嘗試分隔開來。你不能讓每個人都在同一地方進行應用程式的構建，因為那只會是災難的根源。」他建議根據使用案例進行環境分隔。

5. 風險邊際政策

根據使用案例分隔不同的環境也有助於根據生成的低程式碼/無程式碼應用程式在上線後的實際運行狀況和方式建立風險邊際政策。根據 Bargury 的說法，如今許多成功的組織都採取寬鬆的方式來構建應用程式，一旦暴露了應用程式的性質，就會加強控制。

「他們建立了一個環境，讓每個人都可以毫無障礙地在其中構建應用程式，但是一旦應用程式觸及敏感資料或與超過10個人共享時，你可以對應用程式設定特定的邊際底限，」Bargury 說。」當你觸及這些邊際底限時，你會收到一封電子郵件，並通知你：「你已觸及邊際底限。不過還有另一個環境適合你使用。我們可以將你的基礎設施搬移到那裡，但這裡需要進行安全意識的教育訓練。」

除了風險邊際的安全意識教育訓練之外，其他可能要求業務程式設計人員與專業開發人員配對，以強化該應用程式，甚至可能完全重新構建該應用程式——使用無程式碼程序作為如同洛克馬丁公司所運用彈性自主「臭鼬工廠」（skunkworks）開發專案模式般的概念驗證產生器。一旦觸發特定變數時，應用程式便「畢業」了，亦即通過風險邊際的驗證。想要做到這一點，企業組織首先必須在政策框架中列出風險升級的所有觸發因素和路徑。

[ CSO 都在讀：企業面臨的 4 大項 LLM 威脅 ]

6. 資料治理政策

針對低程式碼/無程式碼平台的資料治理和合規，企業組織應具備極其明確的政策，以免違反監管機構的規定。首先，組織應該明確規定每個平台能夠存取什麼類型的資料。Segura 警告說，如果允許低程式碼/無程式碼應用程式接觸敏感資料並建立允許該資料流經他們的應用程式，那麼組織將需要制定資料治理政策和控制措施，以合規友善的方式追蹤所有內容。

「其中一個主要風險莫過於個人可識別資訊和機密資料分散在眾多平台上，由於低程式碼/無程式碼解決方案的去中心化特性，使得追蹤和保護敏感資訊變得更加困難，」Segura 表示。「因此，組織在維護資料完整性和機密性方面面臨挑戰，這對其網路安全狀態構成重大風險。」

EFS 雲端安全和 DevOps 程式開發顧問 Youssef El Achab 表示，即使具有強固的嵌入式安全控制機制，更成熟的低程式碼/無程式碼平台可能仍然需要額外的安全或合規工具控制機制，以完全滿足 GDPR、HIPAA 和 CCPA 規定的資料隱私和資料安全要求，更不用說內部對 SOC 2 或 ISO 27000 等合規性的要求了。

「一些平台更先進，提供了加密、基於角色的存取控制和稽核追蹤機制，這有助於降低風險。但是這些功能可能無法涵蓋所有合規性要求，組織必須根據其特定需求進行配置和自訂，」El Achab 表示。「組織可能無法適當處理使用者資料，提供足夠的同意機制或維護處理活動的紀錄。這可能導致來自監管機構的罰款和聲譽損害。」資訊治理政策應規定何時需要採取額外的措施。

7. 程式碼測試政策

當企業組織描述使用案例和平台時，它們應該根據 Bargury 所提到每條「鋪平道路」上產生的應用程式類型，來制定有記錄的程式碼測試政策。風險較高的使用案例將需要更多的測試程序，並且還可能需要對進入生產環境的低程式碼應用程式進行定期的滲透測試。

「組織絕對應該對其低程式碼/無程式碼應用程式和 API 進行與傳統客製化程式碼軟體相同類型的安全測試，」應用安全軟體平台供應商 Contrast Security 共同創辦人兼技術長 Jeff Williams 表示。「沒有理由相信所有傳統漏洞（比如 OWASP 十大漏洞中的漏洞）完全不可能出現在低程式碼/無程式碼應用程式中。」

低程式碼/無程式碼的問題在於，當前並沒有一個可以在每個平台和使用案例中插進統一安全測試的簡單按鈕。他認為，安全政策和測試程序應該以低程式碼/無程式碼的問題在於，沒有一個簡單的按鈕可以跨每個平臺和用例插入統一的安全測試。他認為，安全策略和測試程式應該以安全護欄思維的模式進行開發，這種思維模式已經滲透到許多現代開發營運安全（DevSecOps）工作中。

一些低程式碼/無程式碼平台可能包括基本的測試或控制，而政策應該規定預設情況下為使用者啟用它們。不過，這些可能不足以讓企業組織能一路越過終點、達成目標。Bargury 認為，安全和工程團隊還得建立能自動測試並執行安全程式碼與功能標準的機制。「我們必須確保做出正確的選擇是容易的，」Bargury 表示。「銷售團隊中的某個人不應該知道如何儲存信用卡資訊。這需要一個自動化的安全護欄，需要有人幫助他們，需要更簡單容易。並且有必要讓犯錯也變得很困難。」

[ 推薦文章：物聯網安全：從規格到程式碼 ]

8. 存取控制政策

理想情況下，組織應該會核准低程式碼/無程式碼平台，並且讓這些平台變得更加簡單容易，這些平台對其應用程式如何提供基於角色的存取控制方面採取成熟的立場。安全政策應該定義低程式碼/無程式碼應用程式環境中的存取控制、權限和機密管理要求。「這些需要包括設置安全控制、構建應用程式、簽署應用程式以及發揮對系統進行管理和稽核作用的能力，」網路防禦自動化平台供應商 Appdome 產品長（CPO） Chris Roeckl 透露。

組織應傾向於採用能使強大的存取控制更容易配置的平台，因為好的配置就是成功的一半。Haydock 建議，企業組織對於公民開發者所制定應用程式中的權限層級結構必須要有明確的指導方針。「思考權限結構並在書面政策中加以記錄可說是最佳實踐，但若也在程式碼中進行記錄（和預設配置），這可以說是盡可能地強制執行該政策的最佳方法，」Haydock 表示，建議組織也應該制定並執行有關低程式碼/無程式碼平台和應用程式如何管理令牌和金鑰等機密的政策。

企業需要特別注意低程式碼/無程式碼平台如何在應用程式之間共享憑證。根據 Bargury 過去所進行的研究顯示，即使是聲譽卓著的平台，在預設情況下也會在其生成的應用程式中共享公民開發者的憑證，使得生成的應用程式能完全規避基於角色的存取控制。這是一個重大的安全盲點，應該透過政策、配置和強制執行控制加以解決。

9. 程式碼擁有權政策

隨著時間推移，在管理低程式碼/無程式碼應用程式的品質和安全性中，出現了涉及程式碼擁有權和責任的重大問題。「你會得到一些能像病毒一樣迅速傳播開來的應用程式，或者得到能成為業務關鍵的應用程式，但這些應用程式卻是由一名商務使用者構建的，這些使用者最終可能轉到另一個職位或離開公司，」Bargury 進一步闡述道，然後組織陷入滾雪球般的技術債（technical debt）之中，因為沒有人在關注那個應用程式。

為了更好地執行上述所有其他政策，Bargury 強調，公司需要建立一套政策和程序，以便能在技術和業務層面上建立在低程式碼/無程式碼環境中所產生各種應用程式的擁有權。「人們目前正在為這件事而苦苦掙扎：『誰是這個應用程式的擁有者？』」Bargury 說。「我談到的既可能是身為開發者或技術專家的擁有者，也可能是身為業務負責人的擁有者。」

強制執行這些政策並追蹤擁有權會帶來新的技術問題，因為在傳統開發中，工程團隊通常擁有作為系統記錄的組態管理資料庫（CMDB）。對於由各種平台生成的分散式低程式碼/無程式碼應用程式組合，這種系統並不存在。但這是一個治理問題，不僅需要解決安全問題，還需要解決像是品質、彈性和開源授權合規性等其他問題。

[ CIO 必讀：強化 IT 和業務協同的 6 大有效策略]