HarborGuard掃描流水線代碼剖析一次鏡像掃描請求從ScanQueue到6大掃描器的全流程【免費下載鏈接】HarborGuardModern image vulnerability scanning patching platform with multi-tool integration.項目地址: https://gitcode.com/gh_mirrors/ha/HarborGuardHarborGuard 是一款現(xiàn)代化的容器鏡像掃描與修復平臺它把一次鏡像掃描請求拆解成一條清晰可控的掃描流水線請求先經(jīng)接口校驗進入 ScanQueue 優(yōu)先級隊列再由 Go 編寫的 sensor 傳感器統(tǒng)一調(diào)度 Trivy、Grype、Syft、OSV-Scanner、Dockle、Dive 這 6 大掃描器并行工作最后將報告結構化落庫并實時推送到前端界面。本文帶你走讀這條鏡像掃描流水線的完整鏈路從 API 接口的第一行校驗代碼到隊列的優(yōu)先級調(diào)度再到六大掃描器各掃一攤、結果四張表落庫的全過程幫你建立對整套掃描引擎的完整認知。 全景視圖一次鏡像掃描要闖過的 6 道關卡在看代碼之前先建立整體地圖。一次掃描請求依次經(jīng)過以下站點API 入口POST /api/scans/start校驗參數(shù)、預檢掃描器可用性數(shù)據(jù)庫預登記DatabaseAdapter為鏡像和掃描記錄建檔優(yōu)先級隊列ScanQueue按優(yōu)先級排序并控制并發(fā)掃描數(shù)模式分發(fā)SensorBridge決定本地直跑還是派發(fā)給遠程 agent六大掃描器執(zhí)行sensor 二進制調(diào)用 6 個 CLI 工具產(chǎn)出報告結果落庫 實時推送JSON 報告寫入結構化數(shù)據(jù)表進度經(jīng) SSE 推到前端 請求入口/api/scans/start 如何把關流水線的第一關是 route.ts 中的POST處理器它做三件關鍵的事Zod 參數(shù)校驗單個掃描需提供image tag或tarPath批量請求一次最多 100 個鏡像每 5 個一批并發(fā)提交避免瞬間打滿資源掃描器可用性預檢調(diào)用detectScanMode()如果既沒有可用的本地 sensor 也沒有已注冊的 agent直接返回 503提前攔截注定失敗的請求審計日志每次啟動掃描都通過auditLogger.scanStart()留痕校驗通過后請求以統(tǒng)一的ScanRequest結構交給核心服務并支持priority-10 到 10參數(shù)為任務設定優(yōu)先級。?? ScanQueue 隊列優(yōu)先級排序與并發(fā)控制隊列邏輯集中在 ScanQueue.ts。它是一個基于全局單例的內(nèi)存隊列核心機制非常直觀機制說明優(yōu)先級排序新任務入隊時按priority降序 入隊時間升序重排高優(yōu)先級任務先執(zhí)行并發(fā)上限processQueue()只在運行中任務數(shù)小于config.maxConcurrentScans默認 3時才放出新任務事件驅動通過scan-queued、scan-started、scan-completed、scan-cancelled四類事件解耦隊列與執(zhí)行器排隊透明度對外暴露隊列位置、預估等待時間、隊列統(tǒng)計前端可以顯示排隊中第 2 位任務出隊時狀態(tài)置為running隊列發(fā)出scan-started事件——這是整條流水線的發(fā)令槍。? 數(shù)據(jù)庫預登記DatabaseAdapter 先為掃描建檔在任務入隊前ScannerService.ts 的startScan()會先生成帶時間戳的requestId然后調(diào)用 DatabaseAdapter.ts 的initializeScanRecord()預登記按來源分三條路徑registry 來源解析鏡像名中的倉庫地址通過RegistryProviderFactory創(chuàng)建對應倉庫Docker Hub、GHCR、GCR、ECR、GitLab 等的 provider 去 inspect 鏡像拿 digest再以事務 upsert 鏡像記錄 創(chuàng)建掃描記錄local 來源直接調(diào)用本地 Docker API 檢查鏡像取 digest 建檔tar 來源為上傳的 tar 包生成占位 digest 建檔這一步保證了即使掃描還沒跑前端列表里已經(jīng)能看到一條運行中的掃描記錄用戶體驗上不出現(xiàn)空白等待。 SensorBridge本地直跑 vs 分布式派發(fā)任務出隊后SensorBridge.ts 的detectScanMode()決定執(zhí)行路徑agent-dispatch分布式模式只要數(shù)據(jù)庫中存在ACTIVE狀態(tài)的 sensor agent就創(chuàng)建一條AgentJob記錄寫入數(shù)據(jù)庫立刻釋放隊列槽位——真正的掃描在遠程 sensor 容器里完成完成后由 agent 回傳結果local-sensor單體模式檢查/app/sensor/harborguard-sensor二進制是否存在存在則通過execFile直接執(zhí)行 sensor CLI超時 30 分鐘unavailable兩者皆無標記掃描失敗并給出明確錯誤提示本地模式有一個值得細看的健壯性設計見 executeScanViaSensor即使 sensor CLI 因 stderr 日志而非零退出只要 stdout 中仍有合法 JSON 報告也會嘗試解析并采用——避免因日志輸出導致整次掃描被誤判失敗。? 六大掃描器各掃一攤覆蓋漏洞、SBOM、合規(guī)與效率sensor 是一個 Go 編寫的二進制源碼位于 harborguard-sensor/在 Dockerfile 的第一個構建階段編譯它接收scan 鏡像引用 --source 來源 --output json指令內(nèi)部并行調(diào)度六大掃描器。六大掃描器分工如下掃描器職責對應結果維度Trivy綜合漏洞掃描CVE、配置、密鑰泄露漏洞發(fā)現(xiàn)GrypeAnchore 出品的包漏洞匹配引擎漏洞發(fā)現(xiàn)OSV-ScannerGoogle 開源漏洞庫OSV匹配漏洞發(fā)現(xiàn)Syft生成 SBOM 軟件物料清單軟件包清單Dockle基于 CIS 基準的鏡像安全體檢合規(guī)檢查Dive逐層分析鏡像結構與膨脹浪費效率分析可以看到三個漏洞掃描器交叉驗證降低漏報Syft 負責這個鏡像里到底有什么Dockle 負責配置合不合規(guī)Dive 負責層結構健不健康——六個視角拼出一張完整的鏡像安全畫像。六大 CLI 工具在 Dockerfile 的 runtime 階段統(tǒng)一安裝并配置緩存目錄。每個掃描器都實現(xiàn)了統(tǒng)一的IScannerBase接口scan()getVersion()想接入第 7 個掃描器官方文檔 docs/ADDING-A-SCANNER.md 提供了從零到一的完整教程。 結果落庫一份 JSON 信封變成四張結構化表掃描完成后sensor 輸出一個標準化的ScanEnvelopeJSON 信封包含鏡像信息、四類 findings 和聚合指標。ingestEnvelope 負責把信封拆開入庫Scan 記錄更新狀態(tài)SUCCESS / PARTIAL / FAILED、風險評分、結束時間ScanMetadata寫入五級漏洞計數(shù)critical/high/medium/low/info、合規(guī)評分、各掃描器版本號四類歸一化發(fā)現(xiàn)表scanVulnerabilityFinding漏洞、scanPackageFindingSBOM 包、scanComplianceFinding合規(guī)、scanEfficiencyFinding效率所有掃描器的輸出都經(jīng)嚴重級別歸一化后匯入統(tǒng)一視圖這套設計讓前端無論用哪個掃描器都能在同一套界面上查看結果。 進度實時推送ProgressTracker 到掃描詳情頁整個過程中ProgressTracker.ts 持續(xù)把ScanProgressEvent狀態(tài)、百分比、當前步驟廣播給所有監(jiān)聽者最終通過 SSE 推送到瀏覽器前端在掃描詳情頁實時顯示運行中 30% — Running sensor scan這樣的進度條。結果呈現(xiàn)上前端為每個掃描器準備了獨立的結果頁簽src/components/scan-results/ 下的 TrivyResultsTab、GrypeResultsTab 等 6 個組件同時提供統(tǒng)一的漏洞、軟件包、合規(guī)、效率四個歸一化頁簽src/components/scan/findings/還支持 PDF / XLSX 報告導出。?? 上手調(diào)優(yōu)3 個環(huán)境變量決定流水線節(jié)奏部署時可以通過環(huán)境變量微調(diào)這條流水線的吞吐詳見 README.md 的環(huán)境變量說明變量默認值作用MAX_CONCURRENT_SCANS3ScanQueue 同時執(zhí)行的掃描數(shù)資源緊張調(diào)小、性能充足調(diào)大SCAN_TIMEOUT_MINUTES30單次掃描的超時上限ENABLED_SCANNERS全部 6 個按需裁剪如只跑trivy,grype可顯著提速 總結一張流程圖記住整條流水線回顧這次鏡像掃描請求的完整旅程API 校驗建檔 → ScanQueue 優(yōu)先級排隊 → SensorBridge 選擇本地/分布式執(zhí)行 → sensor 調(diào)度 6 大掃描器 → JSON 信封落庫四張表 → SSE 實時推送前端幾個值得借鑒的架構亮點隊列與執(zhí)行解耦事件驅動的 ScanQueue 讓并發(fā)控制、排隊查詢、取消操作互不干擾執(zhí)行路徑可插拔同一個ingestEnvelope同時服務本地直跑和 agent 回傳兩種模式單體與分布式部署結果格式完全一致歸一化視圖六大掃描器各產(chǎn)原始報告但前端只看統(tǒng)一的四類發(fā)現(xiàn)換工具零成本如果你想繼續(xù)深入建議按此順序閱讀源碼ScannerService.ts執(zhí)行調(diào)度核心、SensorBridge.ts模式分發(fā)與結果入庫再看 docs/ADDING-A-SCANNER.md 理解擴展機制即可完全掌握 HarborGuard 的掃描引擎設計?！久赓M下載鏈接】HarborGuardModern image vulnerability scanning patching platform with multi-tool integration.項目地址: https://gitcode.com/gh_mirrors/ha/HarborGuard創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 HarborGuard掃描流水線代碼剖析：一次鏡像掃描請求從ScanQueue到6大掃描器的全流程
HarborGuard掃描流水線代碼剖析一次鏡像掃描請求從ScanQueue到6大掃描器的全流程【免費下載鏈接】HarborGuardModern image vulnerability scanning patching platform with multi-tool integration.項目地址: https://gitcode.com/gh_mirrors/ha/HarborGuardHarborGuard 是一款現(xiàn)代化的容器鏡像掃描與修復平臺它把一次鏡像掃描請求拆解成一條清晰可控的掃描流水線請求先經(jīng)接口校驗進入 ScanQueue 優(yōu)先級隊列再由 Go 編寫的 sensor 傳感器統(tǒng)一調(diào)度 Trivy、Grype、Syft、OSV-Scanner、Dockle、Dive 這 6 大掃描器并行工作最后將報告結構化落庫并實時推送到前端界面。本文帶你走讀這條鏡像掃描流水線的完整鏈路從 API 接口的第一行校驗代碼到隊列的優(yōu)先級調(diào)度再到六大掃描器各掃一攤、結果四張表落庫的全過程幫你建立對整套掃描引擎的完整認知。 全景視圖一次鏡像掃描要闖過的 6 道關卡在看代碼之前先建立整體地圖。一次掃描請求依次經(jīng)過以下站點API 入口POST /api/scans/start校驗參數(shù)、預檢掃描器可用性數(shù)據(jù)庫預登記DatabaseAdapter為鏡像和掃描記錄建檔優(yōu)先級隊列ScanQueue按優(yōu)先級排序并控制并發(fā)掃描數(shù)模式分發(fā)SensorBridge決定本地直跑還是派發(fā)給遠程 agent六大掃描器執(zhí)行sensor 二進制調(diào)用 6 個 CLI 工具產(chǎn)出報告結果落庫 實時推送JSON 報告寫入結構化數(shù)據(jù)表進度經(jīng) SSE 推到前端 請求入口/api/scans/start 如何把關流水線的第一關是 route.ts 中的POST處理器它做三件關鍵的事Zod 參數(shù)校驗單個掃描需提供image tag或tarPath批量請求一次最多 100 個鏡像每 5 個一批并發(fā)提交避免瞬間打滿資源掃描器可用性預檢調(diào)用detectScanMode()如果既沒有可用的本地 sensor 也沒有已注冊的 agent直接返回 503提前攔截注定失敗的請求審計日志每次啟動掃描都通過auditLogger.scanStart()留痕校驗通過后請求以統(tǒng)一的ScanRequest結構交給核心服務并支持priority-10 到 10參數(shù)為任務設定優(yōu)先級。?? ScanQueue 隊列優(yōu)先級排序與并發(fā)控制隊列邏輯集中在 ScanQueue.ts。它是一個基于全局單例的內(nèi)存隊列核心機制非常直觀機制說明優(yōu)先級排序新任務入隊時按priority降序 入隊時間升序重排高優(yōu)先級任務先執(zhí)行并發(fā)上限processQueue()只在運行中任務數(shù)小于config.maxConcurrentScans默認 3時才放出新任務事件驅動通過scan-queued、scan-started、scan-completed、scan-cancelled四類事件解耦隊列與執(zhí)行器排隊透明度對外暴露隊列位置、預估等待時間、隊列統(tǒng)計前端可以顯示排隊中第 2 位任務出隊時狀態(tài)置為running隊列發(fā)出scan-started事件——這是整條流水線的發(fā)令槍。? 數(shù)據(jù)庫預登記DatabaseAdapter 先為掃描建檔在任務入隊前ScannerService.ts 的startScan()會先生成帶時間戳的requestId然后調(diào)用 DatabaseAdapter.ts 的initializeScanRecord()預登記按來源分三條路徑registry 來源解析鏡像名中的倉庫地址通過RegistryProviderFactory創(chuàng)建對應倉庫Docker Hub、GHCR、GCR、ECR、GitLab 等的 provider 去 inspect 鏡像拿 digest再以事務 upsert 鏡像記錄 創(chuàng)建掃描記錄local 來源直接調(diào)用本地 Docker API 檢查鏡像取 digest 建檔tar 來源為上傳的 tar 包生成占位 digest 建檔這一步保證了即使掃描還沒跑前端列表里已經(jīng)能看到一條運行中的掃描記錄用戶體驗上不出現(xiàn)空白等待。 SensorBridge本地直跑 vs 分布式派發(fā)任務出隊后SensorBridge.ts 的detectScanMode()決定執(zhí)行路徑agent-dispatch分布式模式只要數(shù)據(jù)庫中存在ACTIVE狀態(tài)的 sensor agent就創(chuàng)建一條AgentJob記錄寫入數(shù)據(jù)庫立刻釋放隊列槽位——真正的掃描在遠程 sensor 容器里完成完成后由 agent 回傳結果local-sensor單體模式檢查/app/sensor/harborguard-sensor二進制是否存在存在則通過execFile直接執(zhí)行 sensor CLI超時 30 分鐘unavailable兩者皆無標記掃描失敗并給出明確錯誤提示本地模式有一個值得細看的健壯性設計見 executeScanViaSensor即使 sensor CLI 因 stderr 日志而非零退出只要 stdout 中仍有合法 JSON 報告也會嘗試解析并采用——避免因日志輸出導致整次掃描被誤判失敗。? 六大掃描器各掃一攤覆蓋漏洞、SBOM、合規(guī)與效率sensor 是一個 Go 編寫的二進制源碼位于 harborguard-sensor/在 Dockerfile 的第一個構建階段編譯它接收scan 鏡像引用 --source 來源 --output json指令內(nèi)部并行調(diào)度六大掃描器。六大掃描器分工如下掃描器職責對應結果維度Trivy綜合漏洞掃描CVE、配置、密鑰泄露漏洞發(fā)現(xiàn)GrypeAnchore 出品的包漏洞匹配引擎漏洞發(fā)現(xiàn)OSV-ScannerGoogle 開源漏洞庫OSV匹配漏洞發(fā)現(xiàn)Syft生成 SBOM 軟件物料清單軟件包清單Dockle基于 CIS 基準的鏡像安全體檢合規(guī)檢查Dive逐層分析鏡像結構與膨脹浪費效率分析可以看到三個漏洞掃描器交叉驗證降低漏報Syft 負責這個鏡像里到底有什么Dockle 負責配置合不合規(guī)Dive 負責層結構健不健康——六個視角拼出一張完整的鏡像安全畫像。六大 CLI 工具在 Dockerfile 的 runtime 階段統(tǒng)一安裝并配置緩存目錄。每個掃描器都實現(xiàn)了統(tǒng)一的IScannerBase接口scan()getVersion()想接入第 7 個掃描器官方文檔 docs/ADDING-A-SCANNER.md 提供了從零到一的完整教程。 結果落庫一份 JSON 信封變成四張結構化表掃描完成后sensor 輸出一個標準化的ScanEnvelopeJSON 信封包含鏡像信息、四類 findings 和聚合指標。ingestEnvelope 負責把信封拆開入庫Scan 記錄更新狀態(tài)SUCCESS / PARTIAL / FAILED、風險評分、結束時間ScanMetadata寫入五級漏洞計數(shù)critical/high/medium/low/info、合規(guī)評分、各掃描器版本號四類歸一化發(fā)現(xiàn)表scanVulnerabilityFinding漏洞、scanPackageFindingSBOM 包、scanComplianceFinding合規(guī)、scanEfficiencyFinding效率所有掃描器的輸出都經(jīng)嚴重級別歸一化后匯入統(tǒng)一視圖這套設計讓前端無論用哪個掃描器都能在同一套界面上查看結果。 進度實時推送ProgressTracker 到掃描詳情頁整個過程中ProgressTracker.ts 持續(xù)把ScanProgressEvent狀態(tài)、百分比、當前步驟廣播給所有監(jiān)聽者最終通過 SSE 推送到瀏覽器前端在掃描詳情頁實時顯示運行中 30% — Running sensor scan這樣的進度條。結果呈現(xiàn)上前端為每個掃描器準備了獨立的結果頁簽src/components/scan-results/ 下的 TrivyResultsTab、GrypeResultsTab 等 6 個組件同時提供統(tǒng)一的漏洞、軟件包、合規(guī)、效率四個歸一化頁簽src/components/scan/findings/還支持 PDF / XLSX 報告導出。?? 上手調(diào)優(yōu)3 個環(huán)境變量決定流水線節(jié)奏部署時可以通過環(huán)境變量微調(diào)這條流水線的吞吐詳見 README.md 的環(huán)境變量說明變量默認值作用MAX_CONCURRENT_SCANS3ScanQueue 同時執(zhí)行的掃描數(shù)資源緊張調(diào)小、性能充足調(diào)大SCAN_TIMEOUT_MINUTES30單次掃描的超時上限ENABLED_SCANNERS全部 6 個按需裁剪如只跑trivy,grype可顯著提速 總結一張流程圖記住整條流水線回顧這次鏡像掃描請求的完整旅程API 校驗建檔 → ScanQueue 優(yōu)先級排隊 → SensorBridge 選擇本地/分布式執(zhí)行 → sensor 調(diào)度 6 大掃描器 → JSON 信封落庫四張表 → SSE 實時推送前端幾個值得借鑒的架構亮點隊列與執(zhí)行解耦事件驅動的 ScanQueue 讓并發(fā)控制、排隊查詢、取消操作互不干擾執(zhí)行路徑可插拔同一個ingestEnvelope同時服務本地直跑和 agent 回傳兩種模式單體與分布式部署結果格式完全一致歸一化視圖六大掃描器各產(chǎn)原始報告但前端只看統(tǒng)一的四類發(fā)現(xiàn)換工具零成本如果你想繼續(xù)深入建議按此順序閱讀源碼ScannerService.ts執(zhí)行調(diào)度核心、SensorBridge.ts模式分發(fā)與結果入庫再看 docs/ADDING-A-SCANNER.md 理解擴展機制即可完全掌握 HarborGuard 的掃描引擎設計?！久赓M下載鏈接】HarborGuardModern image vulnerability scanning patching platform with multi-tool integration.項目地址: https://gitcode.com/gh_mirrors/ha/HarborGuard創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考