現如今，是“軟體定義一切”的時代，軟體已然成為人類社會基礎設施的一部分，與個人生活、社會民生、國家發展高度融合。而大力發展信創是我國目前重要的一項國家戰略，為當今形勢下國家經濟發展注入了新動能。
發展信創是為了解決本質安全的問題。本質安全也就是將以前依賴國外的產品和技術變成自己可掌控、可研究、可發展、可生產的產品與技術，透過發展信創產業構建自己的IT產業標準和生態，使得IT產品和技術安全可控。國產作業系統、資料庫、中介軟體、應用軟體快速發展，持續構建完善且豐富的行業生態。
01
軟體開發安全
當下因軟體存在的缺陷而導致的網路安全問題越來越嚴重，CNVD 已收錄各類安全漏洞資訊超16。6萬條，其中：超過95%的安全漏洞都發生在各類軟體本身，而當中又因為軟體開發相關問題造成的安全漏洞佔96% 以上。由此可判斷，在開發階段產生的軟體缺陷會成為阻礙信創發展的一道技術難關。
如果我們把軟體開發類比建築工程，一棟建築從設計到建設再到落成的過程中：
設計決定了建築的品質，基礎決定了建築的高度，材料結構決定了建築的安全程度。
同理，構造軟體的每一行程式碼、每一個元件都將影響整個軟體的可用性和安全性。我們需要像修建高樓一樣構造軟體，從規劃圖紙到著手建設的每個環節都要做好相應的安全措施，才能保證最終交付良好的產品。
由於軟體本身存在的安全隱患會被人有意或無意的攻擊後造成的資料洩漏、系統崩潰，需要我們對軟體本身的安全性額外加以重視。可以舉個更形象的例子，就像胎兒要進行產檢一樣，在整個胎兒發育過程中，我們需要持續地對胎兒進行觀察檢測，包括B超、基因篩查、唐氏篩查等等，透過各種指標來確定胎兒在發育過程中是否是健康的狀態。如果發現問題，就能趕在胎兒出生之前做好防護工作，如果等胎兒出生後再發現問題就為時已晚了。
我們的開發安全理念就類似於胎兒產檢，我們透過在開發過程中的各個階段做好相
應的安全設計或安全檢測等，來解決軟體的“先天缺陷”，如此一來軟體的交付就會像胎兒健康出生一樣有保障。
安全開發是從源頭減少損失
從更實際的角度看，開發安全不僅僅是為了降低安全風險。一方面， 我們都希望將軟體維護成本控制在合理範圍內。但如果忽視軟體開發安全，往往需要在軟體交付後花費大量資金填補安全漏洞，導致維護成本遠超預期。
早在多年前，國外調研機構就做過一項資料分析，分析表明：如果一個軟體在釋出後進行漏洞修復的成本，約是漏洞在研發階段被解決時投入的成本的上百倍，約是在設計階段被解決時投入的成本的上千倍，而這還不包括上線後漏洞所帶來的額外損失。
所以，我們希望在軟體開發中，安全是從設計源頭開始，透過開發安全的賦能引入自動化的安全工具並且為相應的開發人員進行安全技能的培訓，來消除安全風險，為未來降低安全維護的成本。
但從目前的企業情況來看，安全開發的能力普遍欠缺，缺失的方面有很多，包括架構上的缺失、人員上的缺失、資金上的缺失等等。
另一方面，很多開發人員不具備軟體開發安全的意識和技能，同時安全人員對開發又不熟悉，兩種人員在職責上有分歧，所以在此情況下也就造成了開發團隊和安全團隊專業知識的不對稱，無法在開發階段做好安全防護。
02
軟體開發安全方法
軟體工程發展過程就是管理和技術並行，共同迎接挑戰的歷史。軟體工程的發展歷史分為了三個階段：
第一個階段：上世紀五十年代開始，軟體屬於高精尖的技術，主要客戶以航天航空業和金融業為主。由於軟體複雜度上升，軟體質量出現了問題，造成工程進度不斷延期，在此階段，人們借鑑硬體製造業的管理方法，初步解決了軟體開發中質量差、不可控、無序等問題，專案從“混亂”逐漸走向“穩定可靠”。
第二個階段，上世紀八十年代開始，軟體行業爆發增長，各行業對軟體的需求開始增加，軟體行業開始注重人與技術的思維問題，創造出面向物件的方法。開發效率和交付速度成了該階段最大的問題，而軟體工程的發展出敏捷、精益、DevOps 等概念來解決研發效率問題，專案從“穩定+可靠”走向“速度+可靠”。
第三階段，正是現在我們處於的“軟體定義一切”的時代，在上個階段保障了開發效率和交付速度的開發方式下，解決軟體產品可信的問題成了重點任務，我們需要從“速度+可靠”開始向“可信+速度”演進， DevSecOps、S-SDLC、內生安全等理念也隨之而誕生。
從軟體工程學的角度看軟體開發安全
根據國家標準《GB/T 11457-2006 軟體工程術語》“軟體開發過程（2。1491）”是把使用者要求轉化為軟體產品的過程，此過程包括：把使用者要求轉換為軟體需求，把軟體需求轉化為設計，用程式碼來實現設計，對程式碼進行測試，包括安裝和驗收。
我們通常把軟體開發生命週期（SDLC）定義為：需求、設計、實現、驗證、釋出、運維6個生命週期階段。隨之產生的是我們典型的兩種開發模式，就是瀑布式開發、敏捷式開發，這兩種開發模式都有自己的適用場景和優勢，針對軟體開發安全，兩種模式也都有各自的方法。
首先我們來看瀑布式開發，由於瀑布式是隨著這個整個開發生命週期開展，所以在每一個階段融入相應的安全過程和安全實踐，就形成了我們的 S-SDLC 模型和方法論便得以形成。
作為軟體開發安全的開山鼻祖，微軟在前幾年更新了之前早期的 SDL 模型，包括適用於瀑布開發和敏捷開發的實踐。在新的方法論中適用於瀑布式開發的 SDL 中不在強調流程，而是強調實踐，這就對應上了 S-SDLC 模型。在 S-SDLC 中我們強調對開發過程中自動化檢測（包括：SAST、DAST、IAST 等），同時也強調對開發過程中人員、工具、元件的管理。
第二個是面向敏捷開發的軟體開發安全方法。由於敏捷開發是針對需求頻繁變更和細化的一種開發模式，同時伴隨著網際網路的快速發展，使用者需求快速變化，企業業務也相應的快速變化，再加上 DevOps 開發運營一體化的理念，推動敏捷開發下開發安全方法向 DevSecOps 這種快速交付保障安全的方式來實現。
03
軟體開發安全相關政策與標準
針對軟體開發安全，國家在政策上、安全標準上都有相應的檔案，也有行業標準來針對開發原始碼缺陷的規範。以下摘選了一些與軟體開發安全密切相關的標準與政策，可以在各軟體企業在執行開發安全落地時提供參考。
國家政策
《國家網路空間安全戰略》
第四章“戰略任務”
第七條
“夯實網路安全基礎”。堅持創新驅動發展，儘快在核心技術上取得突破。重視軟體安全，加快安全可信產品推廣應用。
《新時期促進積體電路產業和軟體產業高質量發展若干政策》
第十八條
鼓勵軟體企業執行軟體質量、資訊保安、開發管理等國家標準。加強積體電路標準化組織建設，完善標準體系，加強標準驗證，提升研發能力。提高積體電路和軟體質量，增強行業競爭力。
《網路安全產業高質量發展三年行動計劃（2021-2023年）（徵求意見稿）》
二、重點任務
（一）產業供給強化行動
6。 加強共性基礎支撐。持續建設高質量威脅資訊、漏洞、惡意程式碼、惡意地址、攻擊行為特徵等網路安全基礎知識庫，強化網路安全知識支撐能力。加快發展惡意程式碼檢測、高階威脅監測分析、資訊處理、逆向分析、漏洞分析、密碼安全性分析等底層引擎和工具，提升網路安全知識使用水平。加快發展原始碼分析、元件成分分析等軟體供應鏈安全工具，提升網路安全產品安全開發水平。積極推進網路靶場技術研究，建設結合虛擬環境和真實裝置的安全孿生試驗床，提升網路安全技術產品測試驗證能力。
等保2。0
自行軟體開發
二級
a） 應將開發環境與實際執行環境物理分開，測試資料和測試結果受到控制；
b） 應在軟體開發過程中對安全性進行測試，在軟體安裝前可能存在的惡意程式碼進行檢測。
三級、四級
a） 應將開發環境與實際執行環境物理分開，測試資料和測試結果受到控制；
b） 應制定軟體開發管理制度，明確說明開發過程的控制方法和人員行為準則；
c） 應制定程式碼編寫安全規範，要求開發人員參照規範編寫程式碼；
d） 應具備軟體設計的相關文件和使用指南，並對文件使用進行控制；
e） 應保證在軟體開發過程中對安全性進行測試，在軟體安裝前可能存在的惡意程式碼進行檢測；
f） 應對程式資源庫的修改、更新、釋出進行授權和批准，並嚴格進行版本控制；
g） 應保證開發人員為專職人員，開發人員的開發活動受到控制、監視和審查。
外包軟體開發
二級
a） 應在軟體交付前檢測其中可能存在的惡意程式碼；
b） 應保證開發單位提供軟體設計文件和使用指南。
三級、四級
a） 應在軟體交付前檢測其中可能存在的惡意程式碼；
b） 應保證開發單位提供軟體設計文件和使用指南；
c） 應保證開發單位提供軟體原始碼，並審查軟體中可能存在的後門和隱藏通道。
國家資訊保安標準：應用軟體安全程式設計指南
該標準提出了應用軟體安全程式設計的通用框架，從提升軟體安全性的角度對應用軟體程式設計過程進行指導。
該標準適用於客戶端/伺服器架構的應用軟體開發，其他架構的應用軟體也可參照使用。
標準內容：
1。 安全功能實現
2。 日誌安全
3。 程式碼實現安全
4。 資源使用安全
5。 環境安全
程式碼示例：
提供基於Java和C/C++的對應程式碼示例。
國家資訊保安標準：程式碼安全審計規範
該標準規定了程式碼安全的審計過程以及安全功能缺陷、程式碼實現安全缺陷、資源使用安全缺陷、環境安全缺陷等典型審計指標及對應的證實方法。
該標準適用於指導程式碼安全審計相關工作。
標準內容：
1。 審計概述
2。 審計過程
3。 安全功能缺陷審計
4。 程式碼實現安全缺陷審計
5。 資源使用安全缺陷審計
6。 環境安全缺陷審計
程式碼示例：
提供基於Java和C/C++的對應程式碼示例。
電子行業標準：開發語言原始碼缺陷控制與測試規範
《SJ/T 11681-2017 C#語言原始碼缺陷控制與測試指南》
《SJ/T11682-2017 C/C++語言原始碼缺陷控制與測試規範》
《SJ/T11683-2017 Java語言原始碼缺陷控制與測試指南》
規定了各語言程式中典型型別原始碼缺陷的表象說明、控制活動和測試方法。
適用於各類語言程式設計與測試。
04
給信創軟體企業落地的一些建議
信創軟體企業如何落地軟體開發安全？這裡從組織管理層面和技術層面分別提出4點建議：
管理層面
管理建議1：自上而下推行軟體開發安全落地，且有組織結構支撐
信創企業在軟體開發安全落地的時候，僅依賴傳統的資訊保安部門或者網路安全部門的規劃是遠遠不夠的，必須要有公司領導層自上而下的推動。其中一個非常重要的原因，是軟體開發安全需要和開發各個環節深度地結合，需要得到研發部門所有人全力的支援，還需要在各個開發環節給出相應的開發規範、相應的開發安全技能和工具——這些我們都需要去大力地做融合調整工作。因此，企業需要領導自上而下的推動，來引導開發安全的落地。
另一方面看，開發安全的成本投入是比較大的，但產生的收益卻是隱性的。開發安全所創造的價值主要體現在軟體的質量層面，一是減少了漏洞的存在，使得這個軟體的質量更加可信；二是降低了運維的成本，使軟體公司不必為補救漏洞而疲於奔命但這項價值並不能給軟體銷售額帶來直觀增長，無法創造近在眼前的利益、難以直接刺激員工積極性，必須使用眼界更開闊、目光更長遠的戰略加以支援。
除了自上而下的要求，企業還需要有相應的組織結構來做支撐，因為軟體開發安全在實施過程中，會產生大量的新工作內容和工作流程，如果在工作職責上混亂不清的話，會直接影響軟體開發安全的執行效率和實施效果。
管理建議2：軟體開發安全要與企業的質量管理體系相結合
大部分企業都設有質量管理部門，並有相應的質量管理人員。但是，質量管理部門通常不關心產品的安全問題，卻忽略了安全在本質上也是產品的一項質量指標。
在質量管理領域裡好的質量應該是設計出來的，同樣軟體安全也應該是在前期就應該做好的。業界已有成熟的方法和流程，如：ISO 9001、CMM等級，這些都用來保障產品的質量的方法。
在軟體開發安全落地的過程中，需要將一些具體的軟體安全指標作為質量管理的標準，比如說普通缺陷和高危漏洞的數量、漏洞修復情況等，質量管理部門可以根據這些指標來決定產品是否可以上線或交付。
管理建議3：用度量體系將軟體開發安全實施效果視覺化
一套成型的度量體系，能夠將軟體開發安全實施的效果形象化地呈現出來。為何要做效果視覺化，原因可見於第1點管理建議，軟體開發安全需要透過自上而下的推動。若要普及安全意識，就必須讓其他公司員工親眼“看見”安全的重要性。只有將安全的效果視覺化，才能更容易地獲得管理層和團隊其他人的持續性支援。
在做這個度量體系之前，我們還需要達成一個共識，就是“世界上沒有百分之百的安全，因為安全本身就是動態變化的。”我們不能保證實施了開發安全就不會有漏洞存在，但可以給出一個相對合理的預期，透過軟體開發安全實施後，我們儘可能減少了缺陷的存在，把風險控制在一個可控範圍以內，在這種情況下建立一套度量體系，透過度量方法把軟體開發安全成果呈現出來。
一般而言，成果呈現有兩種方式。一種是透過軟體開發安全能力成熟度來體現，能力成熟度的提升可以證明團隊的軟體開發安全能力得到了提高，能夠開發出更加安全可信的軟體產品。
另一種，是透過一些結果性的資料來判斷我們開發安全是有效的。比如說我們能夠在軟體上線前做了相應的測試和修復工作，來表明軟體上線時是不帶有嚴重高危漏洞，這種情況下也是一個非常好的這麼一種結果的一種展示。
在開發安全業界中，比較成熟的度量體系有兩種，一個是 OWASP SAMM 模型，另一個是 BSIMM 模型，這兩個模型在行業裡面有很高的知名度，也是很多團隊在做軟體開發安全能力評估的時候常用的方法。
管理建議4：建立合適的軟體開發安全人員培訓體系
軟體開發安全不僅僅是偏重於方法和實踐， “人”也是其中非常重要的一個因素。想讓開發人員瞭解並且關注軟體開發安全，就需要建立起一套合適的安全人員培訓體系。與資訊保安培訓不同，安全人員培訓更聚焦在軟體開發安全的意識理念和技術能力方面，其中的意識培訓板塊包括了軟體開發安全的基本知識，開發流程與典型的實踐，還有一些國家法律法規以及行業標準層面的資訊。
除了軟體安全意識培訓外，還有相應的技術能力培訓，其中包括安全編碼的能力、程式碼審計能力、威脅建模能力等。在整個培訓體系下，我們需要把培訓分成不同等級，再去面向不同型別的開發人員和安全人員來提供培訓內容。
技術層面
技術建議1：威脅模型可以使產品避免大的設計風險
在信創軟體開發過程中，增加一些威脅建模的設計工作。它能建立起產品的威脅模型，透過模型化的方法來管理軟體的安全威脅，能有效偵察風險與推進緩解措施的實施。
STRIDE 威脅建模方法可以將大顆粒度的威脅結構化，避免威脅模型遺漏大顆粒度的威脅，保證威脅的完整性；
一套威脅模型的最核心價值，就在於能發現軟體的設計漏洞，即發現某個具體的威脅沒有相應的緩解措施或緩解措施不足。
技術建議2：安全特性元件化可儘量避免編碼漏洞
安全功能的元件化，能幫助我們有效規避編碼漏洞。固然，安全掃描工具能夠識別一些已經存在的編碼漏洞，卻無法從防治編碼漏洞的產生。安全功能的元件化的意義，就在於從根源上遏制漏洞的產生。
雖然之前提到了透過培訓提高安全編碼能力，但我們還是不能保證所有開發人員編寫的程式碼都不含漏洞。而如果我們能把一些安全功能元件化，儘可能簡化開發人員自主編寫的流程，就能降低程式碼出錯的風險、提高程式碼編寫的規範性。因為這些元件在成為開發團隊的公共元件時，本身就獲得了安全團隊的重點保障。
技術建議3：管理第三方元件和第三方軟體的風險
第三點是管理好開發過程中應用的第三方元件的風險。這裡的“第三方元件”不僅僅包括開源元件，還包括商業性的元件，這些元件不僅多見於信創行業，在其他行業所應用的佔比也是非常大的。
尤其是現在對軟體供應鏈安全的高度重視，大家對元件自帶安全漏洞而造成的破壞力也是有目共睹。所以，我們有必要做好第三方元件和軟體的資產管理，透過相應的資產清單，來確定團隊研發的軟體哪些使用了第三方，一旦軟體發生漏洞事件，可以根據清單迅速排查處理。
技術建議4：使用自動化軟體安全測試工具鏈
無論是瀑布式開發場景下的 S-SDLC 還是敏捷開發場景下的 DevSecOps，軟體開發安全的落地始終離不開流程體系和高度自動化的工具鏈的融合，常見的應用檢測工具包括 SAST、DAST、IAST、SCA 、FUZZ 等，都是有助於軟體開發安全落地工作的自動化工具，我們可以透過使用這些工具來提升真正軟體安全測試的效率和軟體開發安全的工作效率。