蜻蜓低代碼安全工具平臺開發之路
一、背景
蜻蜓內測版在五一前夕上線，很快就積累了很多工具，用戶數也逐漸增多，但我也逐漸發現這種堆積式的平臺沒太多技術含量；我在想是否可以做一些有挑戰的事情，正好這幾年低代碼平臺比較火熱，我在想是否能在安全場景做一個低代碼平臺。
1.1 需求出發點
在安全行業中，我們可以想到兩類群體，開發大佬，和腳本小子；
開發大佬能力強，可以寫出很厲害的工具，但一個人或者一個團隊的精力終究是有限的的，功能相對單一，很難做出類似像AWVS類似綜合型工具；
每個團隊開發出來的工具都在某一方面比較好用，很難做到全方面，而且不會考慮太多外置接口用于集成上下游；
而腳本的主要精力在于使用工具掃描到漏洞，它們會收集各類型的工具，不過對一做紅隊或者SRC挖洞場景來說，一款工具基本不太可能滿足自己的需求；
于是這天我突發奇想，能不能做一個平臺，將各種工具連接起來，這樣各種工具就不會零散，把大神開發的工具封裝一個接口，讓這些工具的數據流能串起來，并且盡可能適合每一個人場景。
1.2 蜻蜓與Soar
在市面上我們可以看到很多安全相關的soar平臺，soar平臺的重點是在于編排，蜻蜓也是編排，方向是一致的；
但蜻蜓和soar也有不一樣的地方，是在于蜻蜓的組件支持在用戶機器上運行，而常規的soar平臺應用場景大多是云平臺運行，支持的場景基本是運維和運營場景；
為什么蜻蜓支持重度掃描呢？和蜻蜓的架構模式有關，常規的soar平臺基本是saas平臺，蜻蜓除了saas外還需要添加工作節點；
蜻蜓的SaaS平臺僅用于應用編排和控制臺，節點作為任務真正執行的地方，因此無需考慮用戶規模大性能跟不上，執行節點和不在用戶網絡空間等諸多問題。
二、低代碼平臺的意義是什么？
2.1 打造自己的工作流
場景一：漏洞檢測
從指定網頁中獲得一批URL(每次請求返回內容不同)，檢測URL是否存在SQL注入漏洞，并將檢測的漏洞信息釘釘通知到群里。
對于有開發經驗的工程師來說，這個流程相對簡單，無非是寫一個腳本，不斷請求地址獲得URL，然后去除重復數據，再調用SQLmap進行檢測，最后再寫一個釘釘通知事件；
但是實現起來其實還是要費不少時間的，但他如果知道蜻蜓安全平臺可以這樣來實現，心中估計會忍不住吐槽`WC，還能這樣實現！`
在上圖中可以看到，只需要拖動幾個組件按鈕，將必要的參數往上面填寫即可；這個圖的流程是先 `獲取URL內容`->`對數據做過濾`->`掃描器掃描`->`釘釘通知`；
前后可能不會超過五分鐘時間，就可以把需求做完。而且會發現這個圖中，并不需要多少代碼卻可以讓打造適合自己的安全工具；
場景二：情報通知
每天從一個網頁中獲取安全情報信息，并將信息中包含`反序列化`的信息發送到你的服務器。
那么編排的流程可以是這個樣子，如下圖所示
你需要提供漏洞情報的`URL`，少量篩選數據的`Python腳步`,你服務器的`URL`地址，從圖里在這里對于普通用戶不便的是還是需要寫Python腳步；
不過也不用太擔心，我們會將熱門的數據過濾腳本直接封裝成組件，這樣用戶可以直接拖動組件就行，那么只需要填寫情報URL和服務器URL就可以實現了。
場景三：代碼批量掃描
給你一批Git代碼倉庫地址，需要你對代碼進行安全分析，并將結果推送到指定地址
你可以構建這樣一個流程圖
首先使用`讀取文件內容`組件讀取倉庫地址列表，使用`運行Python腳本`組件將代碼拉取到本地，然后使用`墨菲代碼掃描`組件進行掃描，最后使用`webhook`組件將結果進行通知
這個里面的Python腳本，其實在晚一點時間我會封裝成一個組件，這樣你會發現你并不需要編寫代碼，輕松構建了一個業務場景。
2.2 精力放在構建場景中
借助低代碼平臺，還有一個希望是能幫助開發者站在巨人的肩膀上，快速實現自己的需求，避免反復造輪子；
三、平臺開發難點
蜻蜓低代碼平臺開發中會遇到一些和常規應用開發所不同的難點，比如說各流程節點的通信問題、節點間的數據傳遞、數據傳遞；
3.1 組件間的通信
在蜻蜓低代碼平臺中，希望各組件節點之間相互隔離，又希望它們能夠通信；隔離是為了讓每個組件節點能夠更自由的編排，而通信的需求在于B節點需要在A節點執行完畢之后才執行；
需求是有些矛盾的，但是卻必須要做，因此在設計的時候我做了一個公共組件，所有的組件都可以與公共組件通信，來告知當前的執行狀態，再由公共組件調度下一個組件的執行狀態。
3.2 數據共享
蜻蜓的各節點數據是相互獨立的，但一些場景下需要共享數據，比如代碼審計場景下，節點A負責拉取代碼到本地，節點B負責對代碼進行掃描；
這些文件需要存儲在文件系統中，蜻蜓各節點運行其實是基于docker容器，所以蜻蜓的解決方案是將宿主機某一個目錄掛載到所有容器中，數據都存儲在容器指定目錄。
3.3 調試鏈路長
在開發的階段我們需要對每個組件進行單元測試，調試完畢之后還需要進行組件間的聯合調試，因為組件間的環境是隔離，所以調試程序過程非常繁瑣
比如說我們有一個場景用到了A、B、C、D四個節點，當運行結果沒有達到預期的時候，你或許一下子就定位到是哪一個節點出現異常、但異常很有可能不是此節點本身造成的，而是上游節點數據本身所造成；
平臺的組件可能來自于團隊其他人，也有可能來自于社區，你可能沒有辦法一人獨立解決，這就極大的耗費了開發時間；
這里需要注意的是，每個組件的單元測試一定要反復驗證，在接收參數的時候也要嚴格驗證，否則極其容易出現此問題。
四、開發歷程
低代碼平臺最重要的是讓用戶易懂，能夠快速上手，否則低代碼平臺的價值幾乎是不存在的。
為了讓普通用戶能夠快速上手，前端的交互體驗顯得格外重要，為了讓用戶理解數據的傳遞過程，低代碼平臺通常會使用流程圖來展示數據流轉，蜻蜓安全平臺的流程圖組件選擇的是antv的Xflow
xflow用的typescript語言開發，另外使用了react，之前我的前端技能主要用bootstrap和jQuery實現，前端技術棧的跨度對我來說是最大的技術風險點
花了一周把typescript和react的基礎教學學完了，第二周嘗試自己獨立用react寫一個todolist，再接著嘗試寫了一個訂單評價功能，再逐漸將后端數據管理功能搭了一個架子，再回過頭來看Xflow基本能看懂大致要怎么做了。
五、最后
蜻蜓的低代碼平臺目前還是一個雛形，功能組件還不夠全面，隨著時間的推移和我們的快速開發，組件一定會越加全面，總有一天會覆蓋到你的使用場景。
蜻蜓安全平臺地址：http://qingting.starcross.cn/
蜻蜓GitHub倉庫地址：https://github.com/StarCrossPortal/QingTing
