網絡安全大模型和普通大模型最大的區(qū)別不在模型結構也不在訓練框架而在數據。普通模型要的是語言通順、知識廣博網絡安全模型要的是“在正確的時候給出正確的攻擊或防御動作”。差之毫厘謬以千里。所以這個系列寫到第十四篇專門拿出一整篇來聊數據獲取我覺得是非常有必要的——數據這一關過不了后面做對齊、做微調、做評測全部是空中樓閣。這篇內容我會按照我實際做項目時的思路來講先厘清網絡安全大模型到底需要哪些數據再逐一拆解可以從哪里拿、怎么拿、拿到之后怎么清洗和標注最后聊一聊這個過程中我踩過的一些坑。整個過程里涉及的工具和平臺大部分都是公開的你自己就能上手去試。1. 先搞清楚網絡安全大模型到底需要什么數據很多人一上來就急著到處爬數據結果爬到的東西七零八落喂進模型里跑了一輪效果慘不忍睹。我個人的習慣是動手之前先把“數據需求畫像”畫出來也就是想清楚我要訓練的模型將來在什么場景下用輸入是什么輸出是什么需要具備哪些能力。1.1 從能力反推數據需求網絡安全大模型通常需要具備以下幾類核心能力每類能力對應的數據來源和格式差異非常大漏洞檢測與利用、惡意流量識別、日志分析與告警研判、攻擊溯源、代碼審計、安全知識問答、合規(guī)與應急響應建議。不同的任務有不同的輸入輸出格式要求比如漏洞檢測需要以代碼或請求包為輸入輸出是漏洞類型和位置而知識問答需要的是結構化的安全知識對。如果這些能力混在一起用一份“萬能語料”去訓練效果會非常差。實際項目里我往往會按任務類型把數據強行拆分成多個子集每個子集單獨清洗、單獨標注在后續(xù)訓練階段再決定是混合采樣還是分階段訓練。1.2 數據量的“夠用”標準很多入門者都喜歡問到底要多少數據才算夠這個問題沒有標準答案但是有一個經驗值可以參考——對于微調場景基于開源基座模型做SFT一個任務方向如果能有2萬條以上高質量的“指令-回答”對基本就能看到一個比較明顯的能力涌現如果少于5000條效果往往和隨機噪聲差不多。如果是從零預訓練那數據量就不是這個量級了至少幾十億token打底這種情況對個人開發(fā)者幾乎不現實所以本篇默認站在“微調開源模型”這個語境下討論。另外要說清楚質量遠比數量重要。我在實驗里發(fā)現3000條精心篩選、格式統一的漏洞分析數據訓練出來的模型在漏洞類型識別上的準確率比用3萬條從網上隨手抓來的亂七八糟數據訓出來的模型高出接近20個百分點。原因很簡單大模型對數據中的“噪聲模式”非常敏感垃圾進垃圾出這句話在網絡安全領域體現得尤其明顯。2. 數據來源全景公開數據集、安全社區(qū)與自建語料網絡安全領域有個好現象就是行業(yè)內公開的數據集和知識庫非常多只是分布得很散需要自己花時間去找、去整理。我按照來源把它們分成三大類每一類拿到的數據在后續(xù)訓練中的角色完全不同。2.1 公開數據集質量最穩(wěn)的第一桶金公開數據集是首選的啟動數據因為它們已經經過了一定程度的整理和驗證格式相對規(guī)范拿過來做初步清洗就能用。我常用的幾類包括漏洞描述與CVE數據NVD、CVE Details、GitHub Advisory Database這些地方能拿到結構化非常好的漏洞信息包括漏洞編號、影響組件、危害等級、CVSS評分、漏洞描述和參考鏈接。這部分數據最適合用來訓練模型對漏洞的基礎認知。安全公告與補丁信息各大廠商的安全公告頁面、Red Hat Security Advisories、Ubuntu CVE Tracker這些數據時效性強能幫助模型了解最新的漏洞態(tài)勢。但這類數據噪聲多需要重點處理時間信息。惡意樣本與流量數據MalwareBazaar、VirusShare、Stratosphere Lab的流量數據集、CICIDS系列數據集這些偏二進制和流量抓包適合做基于流量或樣本分析的模型訓練但和純文本大模型之間的格式轉換成本比較高。CTF題目與WriteUpGitHub上有大量CTF比賽存檔比如CTFd導出的題目、各大比賽的公開WriteUp倉庫這些是訓練漏洞利用思路和解題邏輯的好材料缺點是文本質量參差不齊需要大量手工篩選。在使用這些公開數據集的時候有一個原則不要貪多要帶著“這個數據對應模型哪個能力”的問題去篩選。比如我想讓模型學會“從代碼里找SQL注入”那么我需要的核心數據就是包含漏洞代碼片段和對應修復代碼的pair而不是一個籠統的漏洞描述文本。2.2 安全社區(qū)與知識庫高質量語料的富礦如果說公開數據集是骨架那么安全社區(qū)的知識沉淀就是血肉。這些內容往往由一線安全研究員撰寫包含大量實戰(zhàn)細節(jié)和判斷邏輯非常適合用來培養(yǎng)模型在真實場景下的“手感”。我個人最常抓取的內容源有以下幾類技術博客與深度分析文章FreeBuf、先知社區(qū)、看雪論壇、安全客、Seebug Paper等里面大量漏洞分析文章、紅隊攻擊手法梳理、應急響應復盤。這些文章的特點是上下文完整、邏輯鏈條清晰非常適合做“長文本理解類”訓練數據。安全工具使用文檔與手冊Burp Suite官方文檔、Metasploit官方文檔、Nmap手冊、sqlmap的Wiki、YARA規(guī)則編寫指南。工具文檔相對枯燥但術語準確指令性明確對模型理解“具體操作步驟”很有幫助。OWASP類知識框架OWASP Top 10、OWASP ASVS、OWASP Testing Guide這些可以作為結構化知識框架的數據源用來給模型建立安全知識的坐標體系。這類數據在安全問答場景中效果非常好。采集方式上可以用爬蟲去抓也可以去GitHub找別人已經爬好的鏡像倉庫。我自己的習慣是優(yōu)先找現成的因為自建爬蟲的維護成本遠高于大部分人的預期——目標網站改版、反爬策略調整、編碼問題哪一個都能折騰一整天。市面上很多開源爬蟲腳本本身也是學習爬蟲的好案例直接改改比從頭寫省事得多。2.3 自建語料繞不開但價值最高的部分僅僅靠公開數據和社區(qū)內容來訓練網絡安全大模型最后得到的模型大概率只是一個“安全知識問答機器人”而不是真正能動手解決問題的“安全助手”。要讓模型具備實戰(zhàn)能力必須投入人力構建自建語料這部分的產出才是模型的核心競爭力。我常用的自建語料生成方法有幾種基于滲透測試報告的改寫把真實的滲透測試報告脫敏后改寫成“輸入一個靶標范圍輸出測試思路和發(fā)現的問題”這種問答格式。這種數據對培養(yǎng)實戰(zhàn)思維非常有用但因為涉及脫敏和改寫成本最高。用規(guī)則引擎自動生成帶標簽數據比如寫一套正則/Parser規(guī)則從已有的漏洞數據庫中自動生成“請求包-漏洞類型-修復建議”的樣本或者用GDB/objdump配合腳本從二進制中提取漏洞特征。這種方式效率高但需要較強的工程能力。模擬環(huán)境自動采集自己在本地搭一套靶場DVWA、vulhub、Sqli-labs等通過自動化腳本模擬掃描和攻擊把流量和日志采集下來作為訓練“告警研判”能力的數據。這里有個重點靶場環(huán)境相對簡單數據多樣性有限后期需要結合真實業(yè)務環(huán)境的脫敏數據一起用。自建語料是一件費時費力的事情但從我自己的實驗結果來看它帶來的模型能力提升是其他任何數據來源都無法替代的。尤其是模型對任務指令的遵循能力幾乎完全取決于自建語料中“指令-預期輸出”對的質量和數量。3. 實操搭建一個最小可用的數據采集流水線這一節(jié)我會把前面提到的數據來源落到具體的操作層面。以“從公開渠道自動采集漏洞信息”這個最常見的場景為例從環(huán)境搭建到采集入庫完整走一遍。這套流程我在自己的項目中跑過很多次整體比較穩(wěn)定你可以直接照著搭。3.1 環(huán)境準備我用的主力語言是Python 3.10核心依賴庫就幾個requests、BeautifulSoup4、pandas、SQLAlchemy再加一個tqdm做進度展示。數據庫方面我習慣先用SQLite做原型驗證等數據量上來之后再遷到PostgreSQL。安裝依賴非常簡單pip install requests beautifulsoup4 pandas sqlalchemy tqdm另外強烈建議準備一個代理池因為很多安全類網站對高頻訪問的IP封禁非常果斷我試過用一個固定IP去抓某知名漏洞庫抓了不到八百條就被限流了后來換成輪換代理才好一些。3.2 以NVD CVE數據為例的采集實現NVDNational Vulnerability Database提供了官方的REST API這比直接爬HTML頁面要穩(wěn)定得多。API接口地址是https://services.nvd.nist.gov/rest/json/cves/2.0這個接口支持分頁和關鍵詞過濾單次最多能拉取2000條記錄對于大多數場景完全夠用。下面這段代碼演示了如何拉取指定時間窗口內的CVE數據并將其入庫到SQLiteimport requests import sqlite3 import time from datetime import datetime, timedelta API_URL https://services.nvd.nist.gov/rest/json/cves/2.0 def fetch_cves(start_date, end_date): 拉取指定日期范圍內的CVE漏洞信息 all_results [] start_index 0 while True: params { pubStartDate: start_date, pubEndDate: end_date, startIndex: start_index, } resp requests.get(API_URL, paramsparams, timeout30) if resp.status_code ! 200: print(f請求失敗狀態(tài)碼: {resp.status_code}等待30秒重試) time.sleep(30) continue data resp.json() results data.get(vulnerabilities, []) all_results.extend(results) total_results data.get(totalResults, 0) print(f已拉取 {len(all_results)} / {total_results} 條) if start_index len(results) total_results: break start_index len(results) # NVD API 限流建議請求間隔不低于6秒 time.sleep(6) return all_results def save_to_db(cve_list, db_pathcve_data.db): 將CVE數據存入SQLite conn sqlite3.connect(db_path) c conn.cursor() c.execute( CREATE TABLE IF NOT EXISTS cves ( id TEXT PRIMARY KEY, published_date TEXT, description TEXT, cvss_score REAL, severity TEXT ) ) for item in cve_list: cve item.get(cve, {}) cve_id cve.get(id, ) published cve.get(published, ) desc_data cve.get(descriptions, []) description for desc in desc_data: if desc.get(lang) en: description desc.get(value, ) break metrics cve.get(metrics, {}) cvss_score None severity None if cvssMetricV31 in metrics: cvss_data metrics[cvssMetricV31][0].get(cvssData, {}) cvss_score cvss_data.get(baseScore) severity cvss_data.get(baseSeverity) c.execute( INSERT OR REPLACE INTO cves (id, published_date, description, cvss_score, severity) VALUES (?,?,?,?,?), (cve_id, published, description, cvss_score, severity) ) conn.commit() conn.close() if __name__ __main__: end datetime.now() start end - timedelta(days30) cves fetch_cves( start.strftime(%Y-%m-%dT%H:%M:%S.000), end.strftime(%Y-%m-%dT%H:%M:%S.000) ) save_to_db(cves) print(f共入庫 {len(cves)} 條CVE記錄)這段代碼里有兩個比較重要的細節(jié)。一個是NVD API有嚴格的速率限制參考官方文檔是每30秒最多5個請求所以我把請求間隔設成了6秒寧可慢一點也不要觸發(fā)封禁。另一個是入庫時用了INSERT OR REPLACE這樣重復運行采集腳本不會產生重復數據。3.3 社區(qū)文章采集尊重規(guī)則控制頻率社區(qū)文章類的數據采集本質上就是對目標站點做定制的爬取。這里有一個非常關鍵的合規(guī)提示在抓取任何網站之前先看對方的robots.txt并嚴格遵守網站的條款。很多安全社區(qū)的規(guī)則非常嚴格有些甚至明確禁止未經授權的爬蟲。所以抓取前先做一個簡單的合規(guī)自查是否用于商業(yè)用途如果是需要獲得授權。目標站點是否明確禁止爬蟲如果是就不要去碰。抓取是否會影響到網站正常服務如果會就該降低頻率或者換一種獲取方式。對于允許抓取的站點我的建議是將抓取頻率控制在每秒不超過一個請求并且最好在非高峰時段運行。爬蟲本身實現不復雜核心就是找到文章列表頁的分頁規(guī)律和詳情頁的正文提取規(guī)則。這里給一個通用思路的偽代碼import requests from bs4 import BeautifulSoup def crawl_article_list(list_url): resp requests.get(list_url, headers{User-Agent: Mozilla/5.0}) soup BeautifulSoup(resp.text, html.parser) # 這一步需要根據目標站點的DOM結構調整 for link in soup.select(.article-title a): title link.text.strip() url link.get(href) content crawl_article_detail(url) save_article(title, url, content) def crawl_article_detail(detail_url): resp requests.get(detail_url, headers{User-Agent: Mozilla/5.0}) soup BeautifulSoup(resp.text, html.parser) # 正文通常都在某個特定的容器中需要按站點適配 content soup.select_one(.article-content) return content.text if content else 社區(qū)采集最大的問題在于網站的DOM結構經常變今天能跑通的代碼下周可能就失效了。所以建議從一開始就把選擇器和URL規(guī)則寫成配置文件不要硬編碼在代碼里這樣維護起來會輕松很多。3.4 把非結構化文本變成訓練語料拿到原始數據之后還不能直接拿去訓練因為這時的數據格式是“文章標題正文”而大模型微調需要的是“指令-回答”的問答格式。轉換這一步是整個數據流水線里最需要花心思的地方。對于CVE數據可以設計以下指令模板指令請分析這個漏洞的成因、影響范圍并給出修復建議。輸入CVE編號、受影響的組件和版本、漏洞描述。輸出包含漏洞成因分析、危害評級、利用難度評估、修復方案的完整回答。數據轉換的常用方法有兩種基于規(guī)則的模板轉換和基于大模型本身的生成式轉換。規(guī)則模板速度快、一致性高但生成的內容比較死板用大模型來改寫則更靈活但需要消耗一定量的token并且生成質量需要人工抽檢。我實際項目里的做法是“兩條腿走路”對于結構化程度高的數據如CVE、漏洞描述、工具輸出用規(guī)則模板直接轉換對于非結構化的長文章如技術博客、應急響應報告用現成的開源大模型做一次摘要與問答對生成然后人工抽檢。這樣做既能保證效率又能控制成本。4. 數據清洗與去重訓練出好模型的分水嶺很多人在數據獲取上花了大量時間卻在數據清洗上草草了事。這是非常可惜的。從我自己的實驗經驗來看清洗環(huán)節(jié)決定了一個數據集的“可用上限”清洗做不好后面所有工作都要打折扣。4.1 敏感信息與合規(guī)性處理網絡安全領域的數據清洗有一個其他領域不常遇到的特殊要求大量文本中會包含IP地址、域名、人員姓名、企業(yè)名稱、真實漏洞詳情等敏感信息。如果直接把這些數據喂給模型模型在生成回答時有可能把這些敏感信息“吐”出來這在真實業(yè)務場景中是不能接受的。所以清洗的第一件事就是做敏感信息脫敏。需要處理的內容包括IP地址和端口號替換為保留結構但不指向真實目標的占位符如x.x.x.x真實域名替換為example.com一類的公共保留域名郵箱和手機號統一替換為脫敏格式真實的人名和公司名替換為虛構名稱仍然在有效期內的未公開漏洞詳情直接刪除相關段落不要留。這里要特別提醒一句脫敏不是簡單地把值替換掉就完事而是要考慮上下文中的關聯信息。比如一篇報告里同時出現了某公司名稱和對應的系統架構信息即使IP被替換了這兩條信息聯合起來仍然可能指向真實目標。所以安全行業(yè)的脫敏必須和領域專家一起做一輪“語義級”審查。4.2 去重與質量過濾去重是提高數據集質量最有效的手段。網絡安全領域的文章相互引用、抄襲、轉發(fā)的現象非常普遍尤其是漏洞分析類文章經常能在多個平臺看到高度相似的版本。如果不去重模型就會被同一內容的多個變體“帶偏”導致重復內容在訓練集中占比過大。去重我一般分兩層做第一層是精確去重直接用內容的MD5或SHA256哈希值做比對這個簡單高效能去掉完全重復的文本第二層是語義去重用SimHash或MinHash算法對文本做指紋提取然后把海明距離小于某個閾值的文本判定為近似重復再做合并或剔除。質量過濾方面我通常會設計一個多維度評分規(guī)則。最基本的幾條規(guī)則包括文本長度不足200字的內容直接丟棄有效字符占比去除標點和空白后的字符比例低于85%的丟棄包含大量亂碼、特殊符號、無意義重復詞的內容丟棄明顯是廣告、招聘、灌水的內容按關鍵詞庫過濾掉。4.3 標注與格式統一清洗完成后最后一步就是讓所有數據變成統一的“指令-回答”格式。這一步如果前面做得好現在就是純粹的執(zhí)行工作。我常用的做法是維護一套JSONL格式的數據集每行一個JSON對象結構如下{ instruction: 請分析以下代碼中存在的SQL注入漏洞并給出修復建議, input: SELECT * FROM users WHERE id user_input, output: 該代碼存在SQL注入漏洞因為user_input未經過濾直接拼接進入SQL查詢...建議使用參數化查詢... }在指令設計上有一個比較容易忽略的點指令的粒度要適中。指令太寬泛比如“分析這個漏洞”模型的輸出會因為沒有邊界而跑偏指令太狹窄比如“列出CWE-89的修復方式中的第二條”數據集的通用性又不足。我通常會把指令粒度控制在“任務類型目標對象輸出約束”這個層級上。舉個例子“請分析這個PHP代碼片段是否存在文件包含漏洞如果存在請指出觸發(fā)路徑并給出修復建議”就是一個粒度合適的指令。5. 常見問題與排錯實錄數據獲取和清洗這個環(huán)節(jié)踩坑的概率遠高于訓練本身。我把經常遇到的問題整理成一個簡要的清單希望能幫你少走彎路。5.1 反爬限制觸頂怎么辦抓取過程中最常見的報錯是403 Forbidden和429 Too Many Requests。前者通常是因為請求頭缺失或不合法后者是因為請求頻率過高。解決辦法很簡單加全的User-Agent、Referer等請求頭降低請求頻率必要時加隨機延時。如果目標網站對特定IP的封禁時間較長配置代理池基本上能解決。但有一個底線要守住不要對公開網站發(fā)起高強度抓取這既是對目標站點的尊重也是保護自己的方式。如果確實需要大量數據優(yōu)先通過官方API獲取或者郵件聯系網站所有者說明用途很多安全社區(qū)的維護者本身也是技術人溝通得當的情況下能直接拿到脫敏后的數據。5.2 數據集標注質量不穩(wěn)定這是自建語料階段最難纏的問題。我最早做漏洞問答數據時直接找了一批技術群的朋友幫忙標注結果發(fā)現不同人的標注風格和理解水平差異極大導致數據集的回答風格五花八門訓練出來的模型也表現得“人格分裂”。后來我調整了策略先自己花費一周時間梳理標注規(guī)范把回答格式、語氣、詳略標準、邊界情況全部寫成文檔并做了二十條示范樣本。標注人拿到規(guī)范后先做測試標注我逐條審核通過后才讓他們正式開工。同時在最終入庫前我會對所有標注數據做一次隨機抽樣審核抽檢比例不低于5%。這套流程走下來數據集質量明顯穩(wěn)定了。5.3 數據分布失衡網絡安全領域的數據分布天然是不均衡的SQL注入和XSS的資料鋪天蓋地而SSRF、反序列化、條件競爭這些方向的優(yōu)質數據則相對稀缺。如果不加干預訓練出來的模型會對常見漏洞非常敏感對冷門漏洞的判斷能力會很差。我的辦法是對數據集做類別重采樣。簡單來說對樣本量少的類別做上采樣復制或通過改寫擴增對樣本量多的類別做下采樣隨機抽樣或聚類去重讓各類別在最終數據集中盡量均衡。這個過程可以用一個非常簡單的方式實現import pandas as pd df pd.read_json(raw_dataset.jsonl, linesTrue) # 按漏洞類型統計樣本數量 counts df[vuln_type].value_counts() # 設置目標數量為最大類別的80% target_count int(counts.max() * 0.8) balanced_dfs [] for vuln_type in counts.index: sub_df df[df[vuln_type] vuln_type] if len(sub_df) target_count: balanced_dfs.append(sub_df.sample(target_count, random_state42)) else: # 樣本量不足時采取簡單的文本改寫擴增 balanced_dfs.append(sub_df) balanced_df pd.concat(balanced_dfs).sample(frac1, random_state42) balanced_df.to_json(balanced_dataset.jsonl, orientrecords, linesTrue)需要注意上采樣如果只是簡單復制模型容易過擬合。更好的做法是結合同義詞替換、句式改寫等方式做數據增強但這部分對領域理解的要求比較高需要謹慎操作。5.4 數據編碼與格式混亂從不同渠道抓來的數據編碼問題非常讓人頭疼。有的頁面是UTF-8有的是GBK/GB2312有的還在UTF-8里混入了ISO-8859-1的二進制殘留。我建議在數據入庫前統一做一次編碼檢測和轉換import chardet def normalize_encoding(content: bytes) - str: 檢測并將字節(jié)內容轉換為UTF-8文本 detection chardet.detect(content) encoding detection.get(encoding, utf-8) try: return content.decode(encoding, errorsreplace) except Exception: return content.decode(utf-8, errorsreplace)chardet這個庫對常見編碼的識別率還是比較高的雖然偶爾會誤判但結合errorsreplace策略至少不會讓程序崩潰。排序下來編碼問題在清洗環(huán)節(jié)中雖然煩人但解決起來其實是最機械、最沒有技術含量的。6. 數據迭代與持續(xù)更新策略最后聊一個很多教程不會講、但實際項目中特別重要的點數據不是一次性收集完就結束的它是需要持續(xù)迭代的資產。6.1 建立數據閉環(huán)網絡安全領域變化極快新的漏洞類型、新的攻擊手法、新的工具鏈幾乎每天都在出現。如果你的模型只基于某一時刻的快照數據訓練那么它會在未來半年內迅速過時。所以我建議在你整個訓練體系中建立一條數據閉環(huán)定期比如每周或每兩周從各個源自動增量拉取最新數據經過清洗和去重后合并到已有數據集中再定期對模型做增量訓練或全量重訓。這里面有一個工程上的小技巧增量更新的關鍵是要有可靠的“最后更新時間”字段。無論是CVE數據還是社區(qū)文章每條記錄都應該記錄首次入庫時間和最后更新時間這樣不僅能追蹤數據的時效性還能在數據源出現問題后快速定位和回滾。6.2 建一個自己的評測集很多人把精力全放在訓練數據上卻忘記留一部分高質量數據作為評測集。我自己的經驗教訓是評測集的價值一點也不比訓練集低。因為你無法確保訓練出來的模型在真實任務上表現如何除非有一批“標準答案”可以對照。建議在數據積累過程中每收集和清洗完一批數據就抽取其中5%左右作為評測集。這5%的數據永遠不進入訓練集只用來評估模型效果。評測集里要覆蓋各類漏洞類型、不同難度的樣本、不同格式的問法這樣才能比較全面地判斷模型的真實水平。我的個人體會是評測集從第一天就開始積累不要等模型訓練一輪之后才想起來去構建。因為如果評測集是后補的你很難證明它沒有無意中受到訓練數據的影響。那種“評測結果完美”的情況很多時候只是評測集和訓練集重疊過多造成的假象。網絡安全大模型的數據獲取說到底是在一個高度專業(yè)化的領域里做高質量語料的“淘金”。沒有捷徑也沒有一招鮮的標準方案更多是把公開數據、社區(qū)知識、自建語料結合起來反復迭代、持續(xù)積累的一個過程。我踩過不少坑比如盲目追求數據量導致模型學習了很多噪聲比如清洗不到位導致模型輸出敏感信息再比如數據分布失衡把模型帶偏。每一坑最后都是靠更細致的數據工程補回來的。希望這篇內容能讓你在開始之前就建立起對數據獲取這件事的基本判斷少走幾步彎路。