Нууц үг, token хулгайлах шаардлагагүй: npm-ийн Trusted Publishing системээс 1,500 гаруй санг булаан авах "SlugFest" цоорхой илэрлээ

Нээлттэй эхийн (open-source) экосистемд хувийн нууц түлхүүр (API token) алдагдах эрсдэлийг тэглэх амлалттайгаар нэвтэрсэн Trusted Publishing системээс ноцтой эмзэг байдал илэрлээ. Аюулгүй байдлын Bloom Security судалгааны багийнхны дэлгэсэн "SlugFest" хэмээх энэхүү цоорхойн улмаас нийт 10 сая гаруй таталттай 1,500 гаруй npm багц ямар ч халдлага, нууц үг хулгайлалгүйгээр шууд эзэмшигчээ алдах эрсдэлд байсныг зарлав.

Энэхүү алдаа нь криптографын сангаас эхлээд өргөн хэрэглэгддэг аутентификацийн хэрэгслүүдийг хамарсан бөгөөд программ хангамжийн нийлүүлэлтийн сүлжээний (software supply chain) аюулгүй байдлын суурь сууринд томоохон дохио боллоо.

Trusted Publishing уг нь ямар асуудлыг шийдэх ёстой байв?

Олон жилийн турш npm дээр багц нийтлэхийн тулд хөгжүүлэгчид NPM_TOKEN хэмээх урт хугацааны хүчинтэй secret түлхүүрийг GitHub Actions эсвэл CI/CD орчиндоо хадгалдаг байв. Хэрэв энэ token алдагдвал халдагчид хортой шинэчлэлтийг шууд цацах боломжтой болдог байсан билээ.

Үүнийг шийдвэрлэхийн тулд GitHub болон npm хамтран Trusted Publishing-ийг танилцуулсан. Энэ механизм нь OpenID Connect (OIDC) протокол ашиглан:

GitHub Actions дээр build ажиллах үед түр хугацааны тоон гарын үсэгтэй identity token үүсгэдэг.
npm уг token-ийг баталгаажуулж, хэдхэн минутын хүчинтэй нийтлэх эрх (publish credential) олгодог.
Ингэснээр ямар ч тогтмол token хадгалах шаардлагагүй болж, аюулгүй байдал үнэмлэхүй түвшинд хүрнэ гэж тооцоолж байв.

Гэвч аюулгүй байдлын энэхүү төгс загварт нэгэн энгийн атлаа үхлийн аюултай архитектурын алдаа нуугдаж байжээ.

"SlugFest": Тогтмол ID биш, өөрчлөгддөг нэрэнд итгэсний гор

Алдааны гол цөм нь npm систем GitHub репозиторыг хэрхэн таньж, холбож байсантай холбоотой.

GitHub дээр репозитор бүр owner/repo-name гэсэн уншигдахуйц хаягтай байдаг бөгөөд үүнийг slug гэж нэрлэдэг. Үүний зэрэгцээ GitHub уг репозиторт хэзээ ч өөрчлөгддөггүй байнгын тоон ID (immutable numeric ID) давхар олгодог.

Харамсалтай нь, npm анх Trusted Publishing тохиргоог бүртгэхдээ репозиторын тогтмол ID-г шалгахын оронд хүний уншиж болдог өөрчлөгддөг slug-ийг хадгалж байжээ. Халдлагын хувилбар яг эндээс эхэлнэ:

Хаягдсан slug: Нээлттэй эхийн хөгжүүлэгч өөрийн репозиторын нэрийг солих, өөр байгууллага руу шилжүүлэх эсвэл репог устгах үед хуучин owner/repo-name хаяг чөлөөлөгдөнө.
Нэрийг эзэмших: Халдагч GitHub дээр яг тэр хуучин чөлөөлөгдсөн нэрээр (slug) шинэ репозитор үүсгэнэ.
Хуурамч CI/CD: Халдагч шинэ репозитортоо анхны хөгжүүлэгчийн ашиглаж байсантай адил GitHub Actions workflow файл үүсгэнэ.
Хүчинтэй OIDC эрх: GitHub Actions ажиллах үед GitHub нь OIDC токеноо хууль ёсоор өгнө. npm нь хадгалсан нэрээрээ л шалгаж байсан тул уг токенийг хүчинтэйд тооцож, npm дээр шинэ хувилбар нийтлэх эрхийг халдагчид олгоно.

Үр дүнд нь халдагч хөгжүүлэгчийн бүртгэлийг хакердахгүйгээр, албан ёсны Sigstore provenance attestation (гарал үүслийн баталгаажуулалт)-тай жинхэнэ хувилбарыг npm дээр шууд байршуулж чадах нөхцөл бүрдсэн байв.

AI кодинг агентууд: Аюулыг хэд дахин өсгөх хүчин зүйл

Bloom Security-ийн судалгаанд онцолсон хамгийн түгшүүртэй дүгнэлт нь зөвхөн логик алдаа өөрөө биш, өнөөгийн AI агентуудын хэрэглээ байлаа.

Судлаачдын хийсэн хэмжилтээр өнөөдөр байгууллагуудын хөгжүүлэгчдийн компьютер дээр ажиллаж буй AI агентууд (жишээ нь Cursor, Claude Code, GitHub Copilot CLI г.м.) сард дунджаар 70-аас 350 хүртэлх шинэ багцыг автоматаар татаж суулгаж байна.

Хөгжүүлэгч хүн гараараа package нэмэхдээ өөрчлөлтийн түүх, хувилбарын логикийг ямар нэгэн хэмжээгээр анзаардаг бол AI кодинг агентууд зөвхөн шаардлагатай санг хамгийн сүүлийн хувилбараар нь автоматаар татаж, суулгадаг. Хэрэв булаан авсан багцад postinstall script агуулагдсан байвал тухайн шинэ хувилбар суумагц ямар ч хүний оролцоогүйгээр хөгжүүлэгчийн машин дээр хорт код шууд ажиллах нөхцөл үүсэх байв.

GitHub ба npm ямар арга хэмжээ авсан бэ?

Bloom Security уг цоорхойг илрүүлж мэдээлснээс хойш GitHub болон npm дараах өөрчлөлтүүдийг системдээ оруулжээ:

Тогтмол ID-тай холбох (Immutable Identity Binding): Trusted Publishing нь цаашид зөвхөн slug биш, GitHub-ийн өөрчлөгдөшгүй тоон ID-тай шууд холбогдоно.
48 цагийн хүчинтэй хугацаа: Хэрэв шинээр тохируулсан Trusted Publishing тохиргоо 48 цагийн дотор анхны нийтлэлээ амжилттай хийж баталгаажихгүй бол уг тохиргоо автоматаар хүчингүй болно.
Workflow хязгаарлалт: issue_comment зэрэг аюултай триггерүүдээс OIDC token авах эрхийг бүрэн хаав.

Монгол хөгжүүлэгчид өөрсдийн төсөлд юу хийх ёстой вэ?

Төслийн нэр солихдоо болгоомжтой байх: Хэрэв та өөрийн GitHub репозиторыг шилжүүлсэн эсвэл нэрийг нь сольсон бол хуучин slug-аа хэн нэгэнд чөлөөлөхгүйн тулд хоосон репо үүсгэж түгжих (placeholder үлдээх) нь ухаалаг алхам юм.
Trusted Publishing тохиргоогоо хянах: Өөрийн npm дээрх багцуудын "Settings > Publishing access" цэс рүү орж, хуучин идэвхгүй болсон эсвэл нэр нь өөрчлөгдсөн холбоосууд байгаа эсэхийг шалгаж, цэвэрлээрэй.
AI агентуудын эрхийг хязгаарлах: Өөрийн ажлын станц дээр AI хэрэгслүүдийг багц суулгахдаа (npm install) сүлжээ болон системийн орчинд хатуу хязгаарлалттай (sandbox/container) ажиллуулах дадлыг хэвшүүлэх цаг болжээ.

Эх сурвалж: Bloom Security Research, CSO Online, Help Net Security