近日某研發兄弟對我說，他們回溯csec原始碼問題想改進辦法，最後開發了乙個***原始碼掃瞄工具。。。我說怎麼又開發工具，他說想基於kora作定製，結果聯絡作者得不到任何支援，想基於coverity做定製，定製一條規則要乙個月，並且僅僅定製規則又不能全搞定。。。。研發同事也是實屬無奈
研發的同事對pclint、coverity和fortify等應該都無比熟悉，記得公司從2010前後開始大力推廣敏捷開發的時候，這些原始碼檢查工具一開始作為提公升**質量的工具，到現在的作為消除安全編碼問題的有效手段，一直被使用。
針對c/c++，covertity功能最強，誤報率最低，問題種類覆蓋最廣，一直是世界上技術領先的工具，包括符號執行、汙點分析、數值分析等等先進技術，應用效果最好。但是任何一款通用的工具，都不能完全滿足個體使用者的需求，交付的原始碼最終還是會被安全審計部門發現問題。因此很多開發部門都自研工具，比如2023年開始u2000就比較火的ebcc、2023年比較火的kora，這也只是我個人知道的，相信應該還有很多不知名的以及還正在開發中的工具，以前每年的各種獲獎改進建議和各種獲取qcc圈都少不了這些工具的身影。
自研工具有什麼特點？
1、功能簡單
功能簡單並不是壞事，壞就壞在做完乙個1.0稍有成績，就想要2.0版本推廣搞大成績。工具的初衷就是拿來彌補coverity「本地化」的不足的，定位就應該是乙個改進建議那麼大，拼命包裝也掩飾不了功能單一的事實。
2、重複造輪子嚴重
我司研發聚焦的是業務，研發不懂**分析技術非常正常，因此多數工具從專業角度看都非常粗淺，無非是詞法語法分析、正則式匹配這些，然後再基於此定義匹配規則。所有工具語法分析部分的**、報告生成等等大同小異的功能都不是重用，必定自己重新寫一遍。
3、後續沒人維護
通常這些工具都是個人開發，部門內沒有專門設定專案組，如果作者工作重心有變動、崗位有變動工具就沒人維護了。使用中遇到各式各樣的bug，比如掃瞄卡死，規則定義問題，提新需求等等，可能就沒人理了。
4、誤報率超高
由於技術落後，匹配規則幾乎玩得都是人海戰術，錯殺一千不放過乙個，導致效率低下
自研工具是因為coverity會漏報，那麼它為什麼會漏報？根據個人經驗分析及彙總他人分析結果，從工具自身角度出發，原因無外乎就兩點：
1、攻擊模式已知，但是沒匹配成功。
也就是說整數溢位、記憶體越界、死鎖等等這些攻擊模式工具都能夠很好的識別，但是存在乙個匹配度的問題。工具為了提公升準確性，預設匹配度可能是80%，但是我們期望的可能是50%甚至更低，這就會導致人工認為是問題工具認為不是問題的現象。具體一點，比如某個漏洞分支需要整數n在(5,20)才會觸發，工具在計算時認為它可能為(20,25)並不會觸發問題，所以不報；再比如汙點分析場景，某些corba、thrift、webapi等服務介面並沒有被識別為資料入口，也就沒法設定汙染源，從而不會報出資料傳播路徑上的問題。這些通過定製coverity規則很明顯是無法解決的。
2、攻擊模式未知
也就是說人已知的攻擊模式，但是工具不知道。比如dopra平台的記憶體申請函式vos_memalloc、vos_memfree函式，如果乙個指標使用了vos_memalloc申請後沒有釋放，人工自然知道它是記憶體洩露問題，但是vos_memalloc不是標準的記憶體申請函式，工具不知道，也自然無法報出問題。
上面的具體例子提到的是整個華為研發的共性問題，僅僅對coverity規則進行定製並不能解決。但如果能對coverity廠商提定製需求，應該都能夠輕鬆解決，其他沒提到的問題也應該會有解決方案。華為作為coverity的超級大客戶，我覺得需求是能夠得到廠商的重視和滿足的，他們也應該樂於我們反饋需求意見。所以希望2012安全能力中心和工具部能夠收集各研發部門需求，與廠商提出定製需求，評估一下定製的成本與無窮盡的自研工具哪個成本低。
以上個人愚見，歡迎討論
軟體專案經理新手上路 5 頭痛醫頭，腳痛醫腳
專案總有各種各樣的指標，用指針對專案健康情況進行檢查就像人的體檢一樣合理，但是會體檢並不意味著會治病。1.小故事 張三受到了領導嘉獎。當張三剛到專案的時候，中國團隊的任一指標都比國外團隊差很多。張三選定了產出指標作為突破口。他憑藉個人魅力和努力工作極大的激勵了專案團隊成員，終於在半年後，專案團隊成員...
軟體專案經理新手上路5 頭痛醫頭，腳痛醫腳
1.小故事 張三受到了領導嘉獎。當張三剛到專案的時候，中國團隊的任一指標都比國外團隊差很多。張三選定了產出指標作為突破口。他憑藉個人魅力和努力工作極大的激勵了專案團隊成員，終於在半年後，專案團隊成員的產出指標已經與國外置軌。張三也因為卓越的領導力和卓有成效的工作成果受到領導嘉獎。2.常規想法 張三的...