作者 | 中國工商銀行軟件開發中心

一、工行軟件開發中心應用安全支撐體系概述

隨著安全成為數字時代最重要的問題之一，越來越多的企業已經整合了 DevSecOps (DevSecOps 是“開發、安全和運營”的縮寫，它可在軟件開發生命周期的各個階段自動集成安全性-從最初的設計到集成、測試、部署，一直到軟件交付)生命周期，從而進一步強化安全，同時 DevSecOps 也被用于簡化治理和提高可見性。

DevSecOps 的主要思想是安全應該遵循的“左移”方法，而不是事后修復和彌補。根據最新的 DevSecOps 趨勢，大約 40% 的企業有在使用 DAST (Dynamic Application Security Testing：動態應用程序安全測試，模擬黑客行為對應用程序進行動態攻擊，分析應用程序的反應，從而確定該Web應用是否易受攻擊)測試，50% 在使用 SAST（Static Application Security Testing：靜態應用程序安全測試，通常在編碼階段分析應用程序的源代碼或二進制文件的語法、結構、過程、接口等來發現程序代碼存在的安全漏洞），其余的企業通過掃描依賴項和容器來確保軟件安全。

工行軟件開發中心應用安全支撐體系建設圍繞安全左移、過程管控和安全右移三個方面開展。在安全左移方面，通過自研ide插件提前發現安全風險；在過程管控方面，通過持續集成流水線識別并阻斷安全風險，并通過 DAST 和 IAST 持續檢測安全問題；在安全右移方面，通過安全監控，完善可疑流量報警和攻擊行為阻斷，通過安全右移來反哺過程管控。安全團隊通過這些措施，將安全流程和工具更早的納入軟件開發生命周期（SDLC）中，在研發測試階段將安全問題檢出率提高到 99.22%。

圖片

二、當前主要問題及挑戰

從企業內部信息安全團隊的視角看來，企業內部在整個研發流程中遇到的風險點較多，通過對各種攻擊面的梳理和分析之后，我們發現在研發流程中經常提及的風險主要包含代碼安全風險、供應鏈相關的風險以及服務器安全三大類，下文將逐一展開。

安全問題的引入-構建-發布過程，往往和企業內部的持續集成流水線是高度一致的，簡單來說可以抽象成下圖形式：

圖片

開發人員在編寫完代碼后提交到源代碼管理平臺，然后觸發 CI/CD 的構建編譯打包流程，在這個過程中，構建平臺的服務器會從依賴倉庫（大型企業往往會自己建立 nexus 的私服）拉取所需的依賴包，完成構建編譯之后，做成鏡像推送到鏡像倉庫，通過項目分發平臺分發到生產環境上，完成系統的上線。開發視角看習以為常，但安全視角看危機四伏。

1.供應鏈安全

在依賴引入的過程中，如果引入了有問題的組件，則相當于引入了風險，這也是目前最典型的供應鏈攻擊手段，通過我們對各個源的安全調查和分析后發現，“投毒”的重災區在 Python 和 NodeJS 技術棧,投毒的主要目的是控制設備進行“挖礦。（一個原因是因為前端的“挖礦”已經很成熟，容易被黑產濫用，另外一個原因是 Python 的機器學習庫相當豐富，加上機器學習配套的計算環境性能強悍，導致“挖礦”的收益會比入侵普通 IDC 主機更高）。由于例子較多，這里就不一一列舉了。

2.服務器安全

研發前期，在完成了代碼完整性檢測的前提下，如果流程沒有被篡改或者構建平臺都運行正常，一般情況下，出現問題的幾率很低。但如果 CI/CD 平臺和前面的 Git 一樣被惡意篡改或是破壞，也會出現安全隱患，SolarWind 事件就是由于這一原因導致的，攻擊者在 CI/CD 過程中嵌入了“后門”，通過了簽名校驗，再通過 OTA 分發補丁之后，出現了讓人震驚的攻擊事件。

3.代碼安全

在軟件開發環節，開發人員因為水平、安全意識的諸多原因，往往會在開發過程中引入漏洞，這本身是一件十分正常的事情。但對于開源軟件而言，因為幾乎所有人都可以向開源項目提交代碼，并且通過審核后就可以 Merge 進項目，所以可能有不懷好意的人故意引入有問題的代碼，這種風險實際上有可能因為審核的疏忽導致風險直接被引入。

三、應用安全支撐體系建設

工行軟件開發中心應用安全支撐體系建設主要圍繞應用編寫、應用構建、應用發布和持續運營這幾個環節來開展，通過在各個階段提供完善的工具鏈支持，實現對各階段的安全賦能。

1.應用編寫環節

工行通過自研 IDE 插件，在開發人員的編碼階段對代碼及引入的依賴進行準實時檢測，根據風險特征匹配，提示開發人員在編碼早期就完成對安全問題的修復，減少后期修復成本。這其實也是“安全左移”的最佳實踐之一， 即將安全程序（代碼審查、分析、測試等等）移動到軟件開發生命周期（SDLC）早期階段，從而防止缺陷產生和盡早找出漏洞。通過在早期階段修復問題，防止其演變為需花費巨資加以修復的災難性漏洞，進而達到節省時間和金錢的目的。

2.應用構建和發布環節

工行軟件開發中心通過在應用構建和發布階段建立軟件物料清單（SBOM）來實現對軟件資產的透視，實現安全威脅的快速發現和清除。應用軟件通常由大量的開源代碼、自研代碼和第三方庫組成。由于除了直接引用的開源代碼、第三方庫之外，在構建階段開源代碼常常會引入額外的依賴項，因此在軟件開發階段生成 SBOM，對于提高軟件的透明度、提升安全事件處理效率有著重要意義。工行軟件開發中心在DevSecOps 流程上集成軟件物料清單，通過在 CI/CD 的標準實踐，盡量覆蓋絕大多數的場景（業務應用系統、Hadoop 作業等數據服務、Puppet 等運維服務等）。SBOM 包含的信息會隨流水線的推進不斷更新，SBOM 將作為軟件產品的一部分，在統一的存儲庫中存儲和管理。SBOM 作為軟件信息數據源為安全運營體系中各應用提供軟件信息數據支撐，包括但不限于安全資產管理、安全信息與事件管理（SIEM）、威脅情報管理等。SBOM 與安全運營平臺上各項業務功能集成后，在提高對組件漏洞的可見性的同時，也大幅提升對風險的主動響應和風險預防能力。

3.持續運營環節

工行軟件開發中心通過建設安全運營平臺，實現對安全風險的可視化及全生命周期管理。企業組織不能以犧牲運行時安全為代價整體左移。開發人員永遠無法編寫出完美的代碼，也無法在發布窗口期內足夠廣泛地掃描代碼，掃描器的設計目的是為了找出遵循明確模式的已知漏洞或弱點。因此，安全團隊通過對生產運行流量的監控，識別出威脅與攻擊流量并告警，通過建設風險告警與資產關聯的基礎設施，實現對被攻擊資產的快速定位與及時修復，通過安全右移來反哺過程管控。

四、結語

羅馬不是一日建成的，即使確定了整體應用安全支撐平臺建設需求和建設的方向，但落地仍然需要分階段完成。正如建設其他的安全子系統一樣，后續工行將持續從智能化、合規性和多層次防御等方面加強應用安全支撐體系建設，并在高度變化的威脅環境中保持戰略優勢。