一、背景
蜻蜓內測版在五一前夕上線了，很快就積累的很多工具，使用者數也逐漸增多，但我也逐漸發現這種堆積式的平臺沒太多技術含量；我在想是否可以做一些有挑戰的事情，正好這幾年低程式碼平臺比較火熱，我在想是否能在安全場景做一個低程式碼平臺。
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/StarCrossP...
日期：2022年06月23日
微信：songboy8888
作者：湯青松