本文分享自華為雲社群《程式碼檢查服務三級檢查體系中門禁級檢查範圍介紹》，作者： gentle_zhou。
在日常團隊研發過程中，有三個階段是程式碼檢查服務關注的安全檢測點：IDE級檢查、MR門禁級檢查和版本級檢查；分別對應著：在開發人員本地桌面IDE端對原生代碼進行靜態掃描，在Merge Reuqest階段對待合入分支的變更程式碼檔案進行分析，在釋出階段對待發布主幹或分支的全量程式碼檔案進行掃描。
IDE級檢查的特點是快速且準確，版本級檢查的特點則是需要掃描的儘量全面，這兩者的特性在研發團隊看來都是定位比較準確的。但是，對於處在中間階段的MR門禁級檢查來說，定位就略顯“尷尬”；其肩負著輔助研發團隊把控好每次變更程式碼入庫稽核的職責，特徵是務必做到檢查快速、精準且掃描範圍是增量性的。那隨著研發人員對程式碼檢查服務的深入使用，必定會提出的兩個訴求：
- 能否將門禁級檢查的範圍和IDE級檢查的範圍的保持一致，讓檢查能力左移保持一致，都做到快速且準確呢？
- 能否將門禁級檢查的範圍和版本級檢查的範圍保持一致，儘可能多的在MR門禁階段就攔截防護住問題，保障問題可以及時清理掉呢？
這兩個一眼看矛盾的問題，甚至很有可能是由同一個團隊，同一個人提出。但這對於參與過全流程開發的研發人員來說很容易理解，在研發生命週期的不同階段中，研發團隊和個人關注的側重點也是不同的。比如在前期專案開發過程中，研發人員關注的是本地IDE上的程式碼以及提交到雲端的增量程式碼；而在專案開發後期，研發人員會更加關注版本級全量程式碼的質量與安全。
| IDE級檢查 | 門禁級檢查 | 版本級檢查 | |
|---|---|---|---|
| 特徵 | 快速、準確 | 快速、精準、增量性 | 全面、全量 |
| 檢查週期 | 本地按需 | 程式碼合入必需 | 版本釋出按需或定期掃 |
| 預期合理時間 | 秒級 | 分鐘級或秒級 | 小時級或分鐘級 |
那麼，面對這兩個問題，作為程式碼檢查工具方，該提供怎樣的解決方案呢？或則說該如何回答呢？本文嘗試做一個簡單的分析。
門禁級檢查流程介紹
在分析兩個問題之前，我們先簡單介紹下門禁級檢查的流程。
在團隊日常研發過程中，必不可少的一個環節就是將本地開發的程式碼合併到雲端程式碼倉裡去；其中涉及到的兩個git命令就是git commit（將本地一個或多個檔案內更改的程式碼提交到原生代碼倉）以及git push（將本地分支的commit 推送到遠端倉庫的相應分支）。而Merge Request（合併請求）的操作則是請求將一個或多個commit合併到不同的分支裡去，它不是git命令，而是GitLab、GitHub這類程式碼倉託管服務提供的一個功能。通常MR用於將特性分支的程式碼合併到主分支或則開發分支上。
Merge Request作為一種請求機制，可以處於不同的狀態，以確保程式碼審查和合並過程的透明性和可控性；比如說：已開啟、進行中、已關閉、已合併、失敗、無法合併等。而MR只要還沒有被關閉或則合併處於已結束狀態，就可以啟動程式碼檢查服務開啟門禁級的檢查掃描。
門禁級檢查範圍和IDE級檢查範圍保持一致？
首先是第一個問題：能否將門禁級檢查的範圍和IDE級檢查的範圍的保持一致，讓檢查能力左移保持一致，都做到快速且準確呢？
要回答這個問題，我們首先就要先了解下安全領域很火的一個概念“安全左移”。所謂“安全左移”，就是一種在軟體開發生命週期中儘早整合安全措施的實踐，意味著在研發生命週期的早期階段就開始關注安全問題，而不是等到開發後期或臨近釋出前才開始安全整改。這種做法可以幫助研發團隊儘早地發現和修復安全漏洞，從而降低修復成本。
那在程式碼檢查服務中，相比於版本級全量的掃描，門禁級檢查就是一種“安全左移”；而相比於門禁級，IDE級的檢查是一種更左的“安全左移”手段。針對本節的問題，是否應該讓門禁級和IDE級檢查的範圍保持一致，就不是簡單的YES OR NO了，需要考慮本專案程式碼檢查的側重點和程式碼檢查工具使用流程的差異，明白安全左移裡的左移也並非是無限制、無條件的。
首先要明確的是兩種檢查的範圍是不一致的，IDE級檢查的範圍是本地的程式碼，範圍不固定，可以是一個檔案，一個資料夾甚至是整個專案；而MR門禁級檢查的範圍則是本次MR提交的增量程式碼，每次MR檢查的範圍都是不固定的（可能只有一個commit，或多個commit；每個commit包含的掃描內容也不相同），即待合入分支內變更檔案內的程式碼。不同的掃描範圍，就需要挑選不一樣的規則才可以產生相對來說更好效果的結果。
其次是兩種檢查的背後邏輯是不同的，IDE因為是在使用者本地，允許使用者在無網環境下也可以使用，因此檢查掃描的邏輯支援（甚至優先）在本地進行；而MR門禁級檢查必定會涉及到將程式碼提交到雲端程式碼倉，需要在網路環境下進行這個步驟，因此門禁級的程式碼檢查是會在雲端進行。而這些未下沉至IDE端的引擎（可能是因為引擎過大，引擎需要較多資源啟動等）就會導致兩種掃描的結果天然就不相同。
然後就是掃描效率的問題。結合前面一點，因為IDE基本上是在本地進行掃描，受限於本地電腦的效能；而MR門禁級檢查則是在雲端伺服器上進行掃描檢查。兩者的掃描效率也不盡相同，強行一致的規則會導致在IDE端掃描時長不可控。
因此，門禁級檢查範圍和IDE級檢查範圍沒有必要強制保持一致，兩者無論是檢查範圍、背後邏輯還是掃描效率都不相同。當然在本地IDE端包含了掃描引擎、規則的前提下，希望節省門禁掃描時間，不是那麼在意IDE端掃描時長的前提下，兩者保持一致也是可以的。
門禁級檢查範圍和版本級檢查範圍保持一致？
接著是第二個問題，能否將門禁級檢查的範圍和版本級檢查的範圍保持一致，儘可能多的在MR門禁階段就攔截防護住問題，保障問題可以及時清理掉呢？
我們還是從3個角度來思考這個問題：檢查範圍，掃描效率和分析精確度。
首先是檢查範圍，MR門禁級掃描的範圍是本次MR提交的增量程式碼，而版本級掃描的範圍則更全，針對的是待發布主幹或分支的全量程式碼檔案。兩者的掃描範圍不在一個層級，一般來說，MR增量掃描的程式碼量級在幾千行上下；版本級因為針對的是整個分支，程式碼量級在部分開發場景下可能會達到千萬行的級別。
其次是掃描效率，MR門禁級檢查一般都會有時間限制，每個MR裡每次程式碼檢查任務最好控制在分鐘級。但每次啟用程式碼檢查服務，都是需要一套環節的：申請環境、排程任務、準備環境搭建、下載程式碼、掃描分析、生成報告等，每個步驟累計下來，整體上看時間就不少。如果再將門禁級檢查的範圍擴大補充了版本級檢查裡才覆蓋的編譯類規則，先不提掃描效果，每次MR門禁級檢查的整體時間也將會大幅提升。
第三點則是分析精確度的問題。門禁級檢查因為只針對本次MR增量檔案，存在資訊缺失的情況（比如依賴的標頭檔案、三方件等），在這種情況下，即使規則本身很完善、引擎效能優秀，也會導致掃描準確率下降。再加上部分編譯類規則的誤報率高，強行左移到門禁級檢查，會影響MR合入整體的流程體驗（一般來說，每個MR合併會有誤報率的把控，大於XX%就會認為未達到誤報率要求導致整個MR合入失敗）。
點選關注，第一時間瞭解華為雲新鮮技術~