Docker Scout эсвэл Trivy: CVE тоо зөрөхөд аль тайланд итгэх вэ

2026 оны аравдугаар сарын 9 23:00|Зохиогч: QUASA редакцын баг|5 мин уншина

Docker Scout ба Trivy нэг container image-д өөр CVE тоо гаргавал олон илрүүлсэн тайланд шууд итгэх үндэсгүй. Ижил image digest, ижил платформ дээр илэрсэн package бүрийг хувилбар болон түүнд хамаарах advisory-тай тулгаж байж зөрсөн мөрийг шийднэ. CI-д хэрэглэх сканнерыг ч нийт CVE тоогоор бус, баталгаажсан олдвор болон танай image-ийн package-уудыг хэр бүрэн хамарч байгаагаар сонгоно.

Зөрүү хэр том байж болохыг өндөр өртөлттэй Docker Hub image-үүдийн 2026 оны судалгаа харуулжээ: Trivy, Grype, OSV-Scanner-ийн бүртгэсэн 80.7 сая ялгаатай CVE–package хосын 66.8% нь зөвхөн нэг сканнерт, 2.7% нь гурвууланд илэрсэн. Docker Scout уг хэмжилтэд оролцоогүй тул эдгээр хувь нь хоёр хэрэгслийн нарийвчлалын оноо биш. Харин нийт тоо дангаараа аль мөр зөв болохыг тогтоохгүйг харуулна.

Нэг image-ийг үнэхээр ижил нөхцөлд шалга

Харьцуулалтын эхлэл нь image-ийн tag биш, registry дахь digest болон сонгосон платформ юм. Tag дараагийн build рүү шилжиж болно; олон архитектуртай image-ийн өөр хувилбар сонгогдвол доторх package ч өөрчлөгдөнө. Хоёр тайланд яг ямар manifest, үйлдлийн систем, архитектур ашигласныг тэмдэглээд, боломжтой бол нэг registry дахь digest-ээр image-ийг заа.

Скан хийсэн цаг, хэрэгслийн хувилбар, vulnerability өгөгдлийн сангийн шинэчлэгдсэн үе, image-ийг registry эсвэл локал сангаас уншсан эсэхийг хамт хадгал. Өнөөдөр ижил digest дээр гарсан хоёр тайланг өөр өдөр дахин ажиллуулахад шинэ advisory нэмэгдсэнээс тоо өөрчлөгдөж болно. Эхний харьцуулалтад severity, зөвхөн засвартай CVE, ignore болон exception шүүлтүүрээр мөр хасахгүй; CI-ийн бодит тохиргоог дараагийн шатанд тусад нь үнэл.

SBOM ба package-ийн хамрах хүрээг тулга

CVE-г харьцуулахаас өмнө хоёр хэрэгсэл юу олж бүртгэснийг үз. Docker Scout-ийн SBOM зааварт image-д SBOM attestation байвал түүнийг ашиглаж, байхгүй бол image-ийн агуулгыг индексжүүлдэг; мөн docker scout sbom --format spdx тушаалаар SPDX гаралт авах боломжтой гэж тайлбарласан. Attestation болон шинээр үүсгэсэн inventory хоёрын алийг ашигласныг тэмдэглэх нь зөрүү хаанаас эхэлснийг тогтооход тустай.

Хоёр package inventory-г төрөл, нэр, суулгасан хувилбар, боломжтой бол package URL буюу PURL, файл эсвэл layer дахь байршлаар зэрэгцүүл. Үйлдлийн системийн package болон хэлний dependency-г тусад нь бүлэглэ: ижил нэртэй бүрэлдэхүүн өөр экосистемд өөр эх сурвалж, өөр advisory-тай байж болно. Нэг package олон layer-д харагдвал зөвхөн нэрийг нь тоолохын оронд эцсийн image-д суусан хувилбарыг тогтоо.

Нэг тайланд CVE гарсан боловч нөгөө inventory-д package огт байхгүй бол эхлээд image доторх package manager-ийн бүртгэл, lockfile эсвэл холбогдох файлаас бүрэлдэхүүнийг нягтал. Package үнэхээр байхгүй бол advisory-ийн оноо маргааны гол зүйл биш; inventory-ийн хамрах хүрээ эсвэл таних дүрэм зөрсөн байна. Харин хоёр тал ижил package, хувилбарыг бүртгэсэн бол CVE тааруулах дүрмийг шалгах дараагийн үндэслэл бий.

Зөрсөн CVE-г advisory-тай нь тулга

Ижил package дээрх зөрүүг шийдэхэд тухайн package-ийг нийлүүлсэн эх сурвалжийн advisory хамгийн чухал. Үйлдлийн системийн package-д түгээлт, түүний хувилбар, package-ийн бүрэн хувилбарын мөрийг хамтад нь ашигла. Нийлүүлэгч upstream засварыг өөрийн хуучин дугаартай package-д буцаан оруулсан бол зөвхөн upstream хувилбарыг хараад өртсөн гэж дүгнэх нь алдаа болно.

Docker Scout-ийн matching тайлбар package-ийг PURL-аар CVE-тэй холбож, severity үнэлэхдээ тухайн package болон хувилбарт тохирох нийлүүлэгчийн advisory-г түрүүнд хэрэглэдгийг заадаг. Иймээс хоёр тайлангийн severity өөр байвал CVE ID адил эсэхээс гадна аль нийлүүлэгчийн мэдээлэл, ямар үнэлгээний эх сурвалж хэрэглэснийг үз. Severity-ийн зөрүүг шинэ CVE илэрсэнтэй андуурч болохгүй.

Маргаантай мөр бүрт CVE ID, package-ийн төрөл ба суулгасан хувилбар, түгээлтийн хувилбар, advisory-ийн өртсөн хүрээ болон зассан хувилбарыг нэгтгэ. Хэлний сан бол тухайн dependency-ийн бодитоор суусан хувилбарыг экосистемийн advisory-тай тулга. Үр дүнг «батлагдсан», «package image-д байхгүй», «энэ хувилбарт хамаарахгүй» эсвэл «нотолгоо дутуу» гэж ялгах нь CI gate яагаад ажилласан, эсвэл яагаад ажиллаагүйг дараа нь тайлбарлах боломж өгнө. Нэг CVE хэд хэдэн package-д хамаарч болох тул CVE ID-ийн тоо болон CVE–package хосын тоог тусад нь хадгал.

Засвар болон ашиглалтын дохиог салгаж үнэл

Батлагдсан CVE-д зассан хувилбар байгаа эсэх нь ажлын дараалалд нөлөөлнө. Docker Scout-ийн cves тушаалын заавар засвартай мөрийг ялгах --only-fixed, CISA KEV жагсаалтад орсныг шүүх --only-cisa-kev, package-ийн байршлыг харуулах --locations сонголтыг жагсаасан. Шүүсэн үр дүнг бүрэн тайлангийн оронд тавихгүй: шүүлтүүрт ороогүй, засваргүй эмзэг байдал ч хэвээр үлдэнэ.

«Засвартай» гэсэн тэмдэг нь танай base image эсвэл dependency-ийн хэрэглэж буй салаанд шинэчлэл шууд суухыг батлахгүй. Санал болгосон хувилбар түгээлтийн repository-д байгаа эсэх, шинэчлэл build болон ажиллуулах үеийн нийцлийг өөрчлөх эсэхийг тусад нь шалга. Шинэ image гаргасны дараах скан нь зөвхөн шинэ digest дээрх үр дүнг батална; хуучин тайлан дахь мөр автоматаар арилсан гэсэн үг биш.

KEV-д орсон эсэх нь эрэмбэлэхэд хэрэгтэй дохио боловч тухайн container эмзэг кодыг ажиллуулдаг, эсвэл гаднаас хүрэх боломжтойг дангаараа тогтоохгүй. Ажиллах зам, ил гарсан үйлчилгээ, тухайн функц ашиглагддаг эсэх болон байгаа бол VEX тайлбарыг CVE-ийн мөртэй хамт үз. Ингэж «засах хувилбар бий юу» болон «манай орчинд өртөх зам бий юу» гэсэн хоёр өөр асуултыг салгана.

Secret ба тохиргооны шалгалтыг CVE тоонд бүү холь

Сканнер сонгоход зөвхөн CVE биш, image доторх secret болон тохиргооны алдаа ч хамаарч болно. Trivy-ийн container image заавар vulnerability ба secret шалгалт анхдагчаар идэвхтэй, зөвхөн CVE-д trivy image --scanners vuln хэрэглэж болохыг тайлбарладаг. Мөн image доторх IaC файлын тохиргооны шалгалт болон image metadata дахь тохиргоо, secret-ийн шалгалт өөр тохиргоотой: metadata шалгалтыг тусад нь идэвхжүүлдэг.

Тиймээс цэвэр CVE харьцуулалтад vulnerability гаралтыг ялгаж, secret болон misconfiguration-ийн үр дүнг өөр мөрөөр бүртгэ. Төрөл бүрийн шалгалтад яг юу идэвхжүүлсэн, ямар файлыг хамарсан, олдворыг хэрхэн баталсныг тэмдэглэхгүйгээр «нэг хэрэгсэл илүү олон асуудал олсон» гэж дүгнэх нь аргачлалын зөрүүг чанарын зөрүү мэт харагдуулна. Secret-ийн боломжит утгыг багийн нийтлэг тайланд хуулж тараах шаардлагагүй; жинхэнэ credential эсэхийг хязгаарлагдсан орчинд тогтооно.

CI-д аль тайланг баримтлах вэ

Танай image-үүдэд давтагддаг package-ийн төрөл, зөрсөн мөрүүдийн баталгаажсан байдал, засварын мэдээллийн ашиг тус, тайланг дахин гаргах боломж, CI-д нэгтгэх өртгөөр сонголтоо хий. Шалгаагүй хоёр тайлангийн нийлбэрийг үнэн гэж зарлавал худал эерэг олдвор ч жишигт орно. Эхлээд gate-д нөлөөлөх зөрсөн CVE–package хосуудыг advisory-тай тулгаж, дараа нь батлагдсан мөрөөр хоёр хэрэгслийн хамрах хүрээг харьцуул.

Нэг хэрэгсэл CI gate-ийг ажиллуулж, нөгөө нь чухал image эсвэл маргаантай package-ийг давхар шалгах хувилбар бий. Аль алинд нь итгэх нэгж нь тайлангийн нийт тоо биш, ижил digest дээр бүртгэгдсэн package, түүнд хамаарах advisory, боломжтой засвар болон ашиглалтын нөхцөл юм.

Мөн уншаарай:

Хуваалцах: