0x01 寫在前面

---

這篇文章主要是為了分享和記錄自己的一些成長，如有寫得不好的地方，還望斧正。在最早期針對漏洞管理這個事情，個人覺得比較噁心。特別是各種郵件發來發去，到最後追溯到某個系統曾經出現的安全風險時，一頓猛翻，甚至連源郵件出處都找不到…然後就有了這篇文章。

0x02 原來的方式

---

原來的方式比較蛋疼的是，這裡面有很多各種各樣的問題，各種各樣的拖延，例如：研發會質問，這個漏洞嚴重嗎，為啥要馬上修復？又比如：這個漏洞是正常邏輯，需要修改還要過產品那邊，又或者這個漏洞看不懂啥的，又比如你提供的資訊不夠全面等等。因為這些問題導致修復一個漏洞需要2-3天，甚至更長的時間。

然而對於我們來說，這是0容忍的。所以我們需要推動，浪費很多口水跟這些人解釋，如果title比較高的情況下，可能比較好操作，如果只是最基層，可能就….而且還有一個問題，不知道其他的小夥伴有沒有遇到過，就是突然某天你所管轄的系統被人爆了，然後莫名其妙的可能存在很多未知的風險，再然後就是領導找你談話，問你這個系統曾經出現過哪些風險，還有記錄麼？….然後，你就說，都有郵件…然後領導說：你搞下，把這些東西整理出來…然後：xx^&*($%^&

0x03 改善

---

在發現這個問題以後，我試圖改變這個現狀，從溝通需求開始、去諮詢研發、還有我們需要服務的部門，到底怎樣做才能做到最好。逐步，我開始設計一個自動化的方式來提高整體的效率，包括流程的問題。我初步認為，這個流程不需要太複雜，並且我認為這個跟快遞管理的理念是一致的『使命必達』。說幹就幹，梳理下我認為比較達標的方式：

想到達到這個目標不是一般的難，起碼中間扯皮是比較麻煩的事情，但是如果我們能把這個東西做出來，也是一種成就。

0x04 擼成程式碼

---

既然我們知道了目標就可以開始試圖模擬這種場景來實現這個效果。當然，前題你需要得到上面的支援，非常榮幸，在堅持自己見解後，得到了最大力度的支援。

我的設計如下：

1. 發現漏洞，上報漏洞（透過安全平臺發起=>研發收到該漏洞資訊郵件）他可以透過登入平臺檢視詳細資訊，或者透過郵件瞭解該漏洞的細節。在確認知悉後，點選『已知悉』會透過該方式對安全平臺的API進行一次請求，並且更新當前該漏洞的處理狀態。（安全提交=>平臺傳送=>研發收）

   

2. 在點選『已知悉』後，研發再次收到平臺發起的一個電子流，提示該漏洞執行中的流程，在修復完成後，研發再次進行下一步操作。（平臺發=>研發收）

   

3. 在確認漏洞已修復的時候，透過點選『已修復』進入漏洞的複檢流程。（平臺發=>研發收）

   

4. 在確認漏洞已經修復完成後，安全人員針對漏洞進行復查，灰度測試環境上線。（平臺發=>安全收）在這裡，安全人員有兩個選擇，一個是『確認修復』、一個是『漏洞打回』由於有的時候漏洞有可能修復不全面，導致可以二次利用。所以有可能漏洞會被打回。（平臺發=>安全收）

   

5. 在漏洞測試完成後後，研發或運維會根據實際情況，對程式碼進行完整的同步。在全部完成後，點選『已同步環境』則漏洞修復流程結束。（平臺發=>研發/運維收）

整個過程透過電子流的方式實現，同樣使用了郵件的方式，但是可以明顯看出來整個漏洞的處理過程非常清晰、直觀。同時，媽媽再也不擔心漏洞的歷史無法追溯了。有了資料，隨時可查。視覺化管理~

展示下平臺的漏洞管理是啥樣的。

0x05 需要注意

---

1. token的時效問題：首先，你是透過郵件的方式發出、發入，勢必會有時效的問題產出，你需要將token設定在合理的範圍時間，這個根據你的實際情況來定，我預設的是在1天內token有效。
2. 風險描述問題：以上的描述和實際使用的版本有些不同，畢竟有保密的需求，這個東西需要你跟研發、運維、還有你們自己的大哥溝通清楚，瞭解清楚怎麼做才是最合理的。
3. 在風險處理時間上，在系統上最好做個關聯，例如該類風險超過一定時間沒有修復，提前多久給研發發提醒，畢竟有的時候可能會忘記，最好就是有一定的提醒功能，這樣會更加友好。（我還是挺關注使用者體驗的）

0x06 送個漫畫