[本故事為作者本人於 iThome鐵人賽所寫，這邊擴充內容後重新刊登]
原因是前幾天看到一則標題『貼牌的中國製智慧門鈴內含安全漏洞』，讓我想到以前寫過類似的故事，以下內容純屬虛構，如有雷同那就雷同。
故事開始了
小彎是大學剛畢業的菜鳥 RD，公司主要就是開發網路設備，例如：防火牆、郵件伺服器...。
進去公司的第一週前輩要他熟悉程式碼，但當他打開程式碼以為他看錯了，一個網頁裡面 php 包 js ，js 裡面又包 php，讓他想起來一段影片 雞包紙 紙包雞
如此精美的程式碼，小彎當然是不敢動，前輩也叫他先看就好。
就這樣過了第一個月，小彎逐漸了解程式碼，某天上班主管要求緊急開會。
原來是客戶 SOC (資安監控中心)廠商間接通報公司產品有遠端執行程式碼的問題，小彎這時候想:「這麼重大的漏洞，駭客肯定很厲害吧！」，立馬說想要幫忙修這個漏洞來展現工作能力。
現實往往沒有電影來的那麼好看，原來駭客是透過網頁上面有測試網頁的功能，
而前端沒有做任何驗證，後端 100% 相信前端的資料，後端收到網址會直接把指令做執行，也就是所謂的 Command Injection。
小彎想說這不是非常基本的事情嗎，怎麼會有這種低級的錯誤在程式碼裡面？
小彎隨後就開始認真的去研究產品的程式碼安全性，發現有類似的問題至少有 10 多個。
隨後很高興的跟主管回報這些問題，但就單單這一個漏洞修復到發布是在三個月之後了，而公司的計劃就是默默出更新包供客戶自行更新，所以這些有漏洞的版本依舊存在於野外。
可怕的是類似小彎所在的公司在世界各地非常多，許多都是小公司並且最常提供合作的方式就是提供 OEM 版賣給其他廠商換成他們的名字，如此一來就變成國產、日產的設備了，並且搜尋不到 CVE 編號(根本沒有想過主動回報)，就算有編號也因為品牌名稱完全不同難以搜尋，所以在表面上這些產品沒有漏洞。
這類型設備/軟體便宜又可以包裝成國產，或許你正用著這些東西也說不定。
資安探討
小型資訊公司該怎麼辦
原本要寫小彎所在公司的如何解決這件事，但重寫整份程式碼所投資的人力、時間很有可能超出產品實際獲利。這類型的公司業務形式，相同版本的程式碼可能有 2,30 個分支，每個客戶都有一些功能上修改，導致維護與後續更新困難。
除了打掉重建這種建議，筆者認為還能從一些方向慢慢地去改進，有進步總比沒進步好：
- 積極面對漏洞，可思考為甚麼軟體大廠基本上都願意加入 MITRE CVE 的 CNA，認真面對漏洞有甚麼好處。
- 建立良好的開發文化，並將漏洞逐步排入更新計畫中，e.g. code review、避免紙包雞的程式碼、紀錄所用的套件版本並追蹤漏洞
- 出貨時程式做混淆，以增加攻擊者外帶程式回家研究的難度，防止更多安全性漏洞在短時間發生。
- 主動學習常見的開發錯誤，在開發時注意安全 (e.g. 例如大部分網頁開發人員都知道的 OWASP Top10 )
我們應該建立什麼意識？
這篇鬼故事並沒有要表示便宜就是不安全，就連國際大廠都經常出現漏洞，
架構造成的資安問題其實也存在於大廠中，但人家修比較快，資安人員也比較喜歡挖他們漏洞。
不曉得為甚麼的，大多數人喜歡採用買斷的方式而不是訂閱制，當然 $$ 長期來說一定是有差，所以通常買了一兩年之後就不續約，畢竟設備/軟體能動,沒有續約沒有維護漏洞自然就擺在那邊，但駭客與攻擊者們最喜歡這些不更新的系統與設備了。
真的攻擊者特別是背後是國家支持的網軍最喜歡鎖定挖掘這類型的設備，但他們不會回報 CVE 只喜歡默默地挖掘。
企業採購設備/軟體應該要考慮資安的部分。近年來慢慢有將資安當作一個選標的一環，漸漸最低標比較少。這環節通常會將程式碼掃描、公司資安認證等證明納入考慮。但實際上看到結果，也不代表東西沒有問題，畢竟掃描工具百百種，誰能保證大家交出來的報告品質一樣呢？公司過了資安認證，但場域包含範圍呢？但總歸能交出來這些證明的公司，總比產不出來的人好些。
當我們自己開發軟體或購買他人軟體時，應該建立 SBOM (Software Bill of Materials），並清楚列出伺服器和套件的對應關係表，甚至建立當有重大套件漏洞與清單相同時自動提醒，以便在重要套件出現漏洞時，能夠第一時間進行修復或聯繫廠商進行修補，其實如果是自己在開發的話，現在很多 DevSecOps 的軟體或是 github 都有提供類似的服務。
