使用開原始程式碼開發金融科技應用程式是否安全？

斯蒂芬·文特爾

實施期間： 2023年4月 13 日 - 技術佈道者

金融科技應用需要特別強大的安全態勢。畢竟，您正在保護客戶的財務數據（甚至更令人不安的是金錢）。

金融服務供應商是駭客有利可圖的目標，成功的攻擊會給擁有和運行金融科技應用程式的使用者和組織帶來巨大風險。因此，金融科技開發人員是否應該使用非商業性的開原始程式碼？

這是一個「開放」的問題，在本文中，我們將討論風險 - 包括金融科技開發人員可以做些什麼來保護開原始程式碼。

金融科技軟體開發面臨的嚴峻安全挑戰

由於涉及高風險，金融科技應用程式對網路安全的要求特別嚴格。金融科技中常見的網路安全風險和挑戰包括雲計算問題、惡意軟體攻擊、第三方訪問、系統複雜性和相容性、洗錢風險、身份盜竊和身份驗證，以及至關重要的合規性。

例如，為了確保電子支付的安全性，許多司法管轄區都執行了《支付服務指令》（PSD2），並制定了關於確保數據安全的具體規定。在美國，支付卡行業數據安全標準（PCI DSS）負責規範支付卡數據的收集、處理和使用，但它是全球適用的標準。

因此，金融科技應用程式不僅面臨網路攻擊的風險，而且還面臨不合規的危險。安全故障很快就會產生嚴重後果。因此，依賴「免費」代碼是個好主意嗎？

什麼保證了數據的安全：開原始程式碼還是商業代碼？

這是一個激烈的爭論，正確的答案並不是付費的商業代碼更安全，僅僅因為用錢換取應用程式代碼。

開原始程式碼更容易受到審查，因為每個人都可以查看它。因此，從理論上講，更有可能發現開原始程式碼中的錯誤。另一方面，不能保證合適的人會批判性地看待開原始程式碼，或者開發人員有動力去發現缺陷。事實上，可能是威脅行為者在尋找缺陷。

然而，由利潤驅動的閉源商業軟體不一定更安全，因為供應商可能不會部署安全研究人員來檢查代碼中的缺陷，並且可能會匆忙完成編碼以滿足最後期限。

最終，無論開發人員是否獲得報酬，他們都會犯錯誤，因此對開源和閉源軟體進行安全性審查和測試非常重要。對於開發人員來說，這意味著必須以相同的謹慎態度對待這兩個代碼庫。

開源安全是每個人都關心的問題

但有趣的是：商業代碼通常依賴於開原始程式碼元件，因此組織可能會在其應用程式中使用開原始程式碼，即使他們主要依賴商業合作夥伴。

從本質上講，開源庫和包激增。在基於雲的應用程式中，多個開源庫和服務通常集成到技術堆疊中，使開發人員能夠從現有工作中受益。

但是，在某些情況下，它還為攻擊者提供了破壞網路的閘道。這些開源元件可能存在滲入生產的漏洞，如果在構建過程後期或部署后發現，則會導致項目延遲。

這是一個複雜的情況，依賴關係的依賴關係構成了明顯的威脅，因為當應用程式調用包含漏洞的包時，很容易被忽視。無論哪種方式，開源漏洞都是金融科技開發過程的一部分，無論開發人員主要依賴商業代碼還是開原始程式碼。

專注於開發安全運營以實現安全性

現代軟體開發需要一個持續的安全流程，而不是一次性的解決方案，代碼庫是商業的還是開源的並不重要。此方法稱為 DevSecOps，涉及開發、安全和運營團隊之間的安全共用責任。

威脅建模、安全測試工具、滲透測試和審核都合併到 CI/CD 管道中。開發人員還可以使用軟體組成分析來監控整個開發過程中的開源元件，並觀察已知的主要缺陷，這些缺陷使數據難以保持安全。這種協作方法為金融科技應用程序帶來了更快、更安全的軟體交付。

當然，所有其他好的建議也是有效的：始終如一地應用良好做法，例如 MFA、強密碼、憑據管理和嚴格許可權。監控和測試還可以識別入侵者和缺陷。瞭解所依賴的工具和基礎構建基塊，包括庫和依賴項。

可以說，軟體安全最關鍵的元素是補丁。全面的修補可防止已知漏洞，無論是使用免費軟體還是商業軟體。但是，持續修補具有挑戰性且耗時，通常只能解決優先順序最高的漏洞。

更重要的是，修補可能需要重新啟動或重新啟動，開發團隊可能會延遲或避免修補以保持可用性。即時修補值得考慮作為一種解決方案。

結論

問題不在於在金融科技應用程式中使用開原始程式碼是否安全。開原始碼無處不在，無論如何都可能會進入您的金融科技應用程式。你應該使用更多還是更少的開原始程式碼？這是另一個問題 - 但你不能真正構建一個論點，即開原始程式碼本質上不太安全。