Dependabot PR-ийг шууд бүү merge хий: production scope-оо эхлээд шалга

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

Dependabot alert-ийг засахдаа өртсөн dependency production хувилбарт ордог эсэхийг эхлээд тогтоо. Ордог бол эмзэг функц ажиллах боломжтой кодын замыг шалгаж, засвар орсон хувилбар руу шинэчлэх PR-ийг бэлтгэ. PR-ийн өөрчлөлт, CI-ийн үр дүн, буцаах аргыг нягталсны дараа merge хий; үндэслэлтэйгээр хаах бол шалгасан зүйлээ тэмдэглэ.

GitHub-ийн Dependabot alert-ийн заавар эрэмбэлэлтдээ CVSS оноо, dependency scope, эмзэг функцийн дуудлага илэрсэн эсэх, боломжит нөлөөлөл болон засах боломжийг харгалздаг гэж тайлбарладаг. Иймээс оноо өндөр гэсэн ганц шалтгаанаар бүх alert-ийг ижил дарааллаар засах нь багийн бодит өртөлтийг илэрхийлэхгүй. Эхний шийдвэр бол багц хаана сууж, ямар ажилд оролцож байгааг тогтоох явдал юм.

Өртсөн багц production хувилбарт ордог уу?

Repository-ийн Security and quality хэсэгт Dependabot-ийн Vulnerabilities жагсаалтыг нээж, alert-д заасан багц, өртсөн хувилбар, manifest болон засварын хувилбарыг хар. Development гэсэн шошго эсвэл scope шүүлтүүрээр жагсаалтыг багасгаж болно. Гэхдээ энэ тэмдэглэгээг байршуулсан хувилбарын бүрэлдэхүүнийг шалгасан дүгнэлттэй адилтгаж болохгүй.

Manifest, lock file, build тохиргоо болон байршуулалтад ашигладаг artifact-аа тулгаж үз. Багц шууд dependency юу, өөр багцаар дамжиж орж ирсэн үү гэдгийг dependency graph-аас тогтоогоод, production-д ашигладаг хувилбар үнэхээр өртөмтгий хүрээнд байгаа эсэхийг шалга. Repository-д бүртгэлтэй багц бүр хэрэглэгчид хүрдэг хувилбарт ордоггүй; мөн нэг repository-ийн туршилтын болон байршуулалтын тохиргоо өөр байж болно.

Development scope-той багцыг автоматаар хойшлуулах хэрэггүй. Уг багц CI, нийтлэх урсгал эсвэл нууц мэдээлэлтэй ажилладаг бол хэрэглэгчийн хүсэлтийг боловсруулдаггүй байсан ч өөр төрлийн өртөлт үүсгэж болно. Харин зөвхөн тусгаарлагдсан туршилтад ашиглагддаг нь тогтоогдвол production замд ордог багцын засварыг түрүүлж төлөвлөх үндэслэлтэй.

CVSS-ийн дараа эмзэг кодын замыг шалга

Alert-ийн тайлбараас өртөмтгий хувилбарын хүрээ, эмзэг байдлыг өдөөх нөхцөл, дурдсан функц эсвэл API-г унш. Төслийн код тэр функцийг шууд дууддаг эсэх, эсвэл дам dependency-ээр хүрдэг эсэхийг хай. Дуудлага production-д ажилладаг замд байгаа бол засварын ач холбогдол нэмэгдэнэ; дуудлага илрээгүй бол шинжилгээ бүх runtime замыг хамарсан эсэхийг тусад нь нягтал.

Олон alert зэрэг нээлттэй үед дараах богино ангилал шийдвэрийг нэг мөр болгоно:

Production-д ордог, эмзэг зам хүрч болох, засвар байгаа: засварыг түрүүлж бэлтгээд тухайн замын тестийг ажиллуул.
Production-д ордог, хүрэх зам тодорхойгүй: кодын дуудлага, тохиргоо болон байршуулсан хувилбарыг шалгаж дуустал alert-ийг нээлттэй үлдээ.
Development scope-той: CI, нийтлэх ажиллагаа болон нууц мэдээлэлд хандах боломжийг шалгаад дарааллыг тогтоо.
Засвар байхгүй эсвэл шинэчлэлт саатсан: өртөлтийг бууруулах түр арга, багц солих боломж болон дахин үнэлэх нөхцөлийг тэмдэглэ.

Энэ ангилал CVSS-ийг орлох шинэ оноо биш. Нэг багцын эрсдэл хувилбар, ашиглаж буй функц, байршуулалтын замаас хамаарна. Ялангуяа эмзэг функцийн дуудлага илрээгүй гэсэн дохиог «дуудах боломжгүй» гэсэн баталгаа болгохгүйгээр код болон ажиллах орчны мэдээлэлтэй тулгах нь чухал.

Автомат PR юуг засдаг вэ?

Security updates идэвхтэй үед Dependabot patch боломжтой alert-д PR нээхийг оролддог. GitHub-ийн security update-ийн тайлбар-т dependency graph-ийг эвдэхгүйгээр шинэчлэх боломжийг шалгаад, боломжтой бол засвар орсон хамгийн бага хувилбар руу PR нээх, боломжгүй бол alert дээр алдаа мэдээлэхээр заасан. Security update нь manifest эсвэл lock file-д заагдсан dependency-д тулгуурладаг тул PR харагдахгүй байх нь өртөлт арилсны шинж биш.

PR гарсан бол санал болгосон хувилбар alert-ийн өртөмтгий хүрээнээс гарч байгаа эсэхийг нягтал. Manifest дахь шууд dependency шинэчлэгдсэн ч lock file дахь дам dependency-үүдийн өөрчлөлтийг тусад нь үзэх шаардлагатай. Багцын хувилбарын хязгаарлалт шинэчлэлтийг саатуулсан бол алдааны тайлбарыг уншиж, parent dependency эсвэл төслийн өөр хязгаарлалтыг өөрчлөх хэрэгтэй эсэхийг тогтоо.

Засвар орсон хамгийн бага хувилбарыг сонгосон нь төслийн API хэрэглээ, тохиргоо эсвэл ажиллах орчинтой нийцнэ гэсэн баталгаа биш. Багцын changelog, release note-оос өөрчлөгдсөн зан төлөв болон шаардлагыг шалга. Хэрэв PR хэд хэдэн багцыг хамарсан бол нэг alert-ийн засварыг бүх өөрчлөлтөд шууд хамаатуулалгүй, багц бүрийн шинэ хувилбарыг ялгаж үз.

Merge хийхээс өмнө юуг шалгах вэ?

PR-ийн diff-ээс manifest, lock file болон холбогдох workflow-д ямар өөрчлөлт орсныг хар. GitHub-ийн dependency review-ийн тайлбар PR-д нэмэгдсэн, хасагдсан, шинэчлэгдсэн шууд болон дам dependency, тэдгээрийн мэдэгдэж буй эмзэг байдлыг харуулдаг. Шууд багцын хувилбар солигдоход дам багцууд ч өөрчлөгдөж болох учраас зөвхөн PR-ийн гарчиг эсвэл нэг мөрийн diff-ээр шийдэхгүй.

Дараа нь төслийн CI-д байдаг build, тест, lint болон security check-ийн үр дүнг шалга. Засвар нөлөөлж болох production замыг одоо ажиллаж буй тестүүд хамардаггүй бол тэр замд чиглэсэн шалгалт нэмэх буюу гараар баталгаажуулах хэрэгтэй. Ногоон CI нь ажилласан шалгалтууд амжилттай дууссаныг л хэлнэ; хамрагдаагүй хэрэглээний замд асуудал үүсэхгүйг батлахгүй.

Байршуулахаас өмнө өмнөх ажиллаж байсан хувилбар, lock file болон байршуулалтын аргаар буцах боломжоо тодорхойл. Шинэчлэлт өгөгдлийн хэлбэр эсвэл тохиргоонд нөлөөлсөн бол зөвхөн хуучин багцыг сэргээхэд хангалттай эсэхийг тусад нь үнэл. Шалгалтын үр дүн болон буцаах нөхцөлийг PR-д товч тэмдэглээд merge хий; байршуулсны дараа ажиллаж буй хувилбар болон alert-ийн төлөвийг шалга.

Alert-ийг хэзээ үндэслэлтэй хаах вэ?

Өртсөн хувилбар ашиглаж буй artifact-д байхгүй, эсвэл тухайн эмзэг нөхцөл төслийн хэрэглээнд хамаарахгүйг шалгасан бол alert-ийг хаах шийдвэр гаргаж болно. Зөвхөн CI амжилттай, CVSS бага, эсвэл автомат PR үүсээгүй нь хангалттай үндэслэл биш. Засварыг хойшлуулах шаардлагатай бол үлдэж буй өртөлт, түр хязгаарлалт, хариуцах хүн болон дахин үнэлэх нөхцөлийг тодорхой болго.

Dismiss хийхдээ тохирох шалтгааныг сонгож, шалгасан manifest, байршуулсан artifact, хувилбар болон кодын замаа сэтгэгдэлд бич. Ингэснээр дараагийн хүн шийдвэрийн үндэслэлийг сэргээж чадна. Dependency-ийн хэрэглээ, хувилбар эсвэл байршуулалтын зам өөрчлөгдвөл өмнөх дүгнэлтийг дахин шалгаж, шаардлагатай бол alert-ийг нээ.

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

Хуваалцах: