GitHub лансира npm заштитен ѕид за блокирање на злонамерни пакети пред нивната инсталација

GitHub објави дека воведува нов заштитен ѕид за пакети (Package Firewall), кој засега е достапен во пробна верзија, а чија цел е да спречи инсталирање сомнителни npm пакети уште во текот на процесот на инсталација.

„Заштитниот ѕид ги проверува и барањата за метаподатоци и преземањата на пакетите во потрага по знаци на злонамерна активност, дејствувајќи како безбедносна контролна точка за време на инсталацијата“, соопшти GitHub.

Функцијата моментално поддржува само npm пакети и е достапна во јавна пробна верзија за сите корисници на GitHub Enterprise Cloud, вклучувајќи ја и верзијата GitHub Enterprise Cloud со локално складирање на податоците во одреден регион.

Според компанијата, која е дел од Microsoft, заштитниот ѕид е поставен помеѓу крајните уреди или внатрешните регистри и надворешните складишта на пакети, со цел да спречи напади со малициозен софтвер што можат да ги компромитираат системите при инсталирање пакети.

Ваквиот начин на работа може да ги изложи корисниците на сериозни безбедносни ризици, особено кога агентите со вештачка интелигенција (AI) и CI извршувачите автоматски инсталираат зависности за да завршат одредена задача или да изградат софтвер, без нивна изречна дозвола.

Идејата е крајните уреди, како што се агентите за програмирање и CI/CD хостовите, да го користат заштитниот ѕид за испраќање на своите барања, наместо директно да се поврзуваат со јавните регистри на пакети.

Заштитниот ѕид потоа ги проверува преземањата на пакетите според безбедносните правила, како што се минималната старост на пакетот и безбедносните предупредувања за малициозен софтвер. Преземањата што не ги исполнуваат овие правила автоматски се блокираат.

За да го користат заштитниот ѕид, администраторите мора да ги конфигурираат безбедносните правила, меѓу кои се и следниве:

– Блокирање на познат малициозен софтвер – проверка на GitHub Advisory Database за активни безбедносни предупредувања поврзани со малициозен софтвер.

– Блокирање пакети врз основа на сериозноста на ранливостите – проверка на GitHub Advisory Database за безбедносни пропусти што влијаат врз бараната верзија на пакетот. Стандардно, инсталацијата се блокира само за критични ранливости („Critical only“), но корисниците можат да изберат и „High or higher“, „Medium or higher“ или „Any severity“.

– Блокирање на намалувањето на нивото на безбедносна потврда (attestation downgrade) – споредување на безбедносните потврди за бараната верзија на пакетот со оние од претходните верзии. Преземањето се блокира доколку бараната верзија нема SLSA безбедносна потврда.

– Блокирање новововедени скрипти за инсталација – проверка дали пакетот неодамна додал скрипти што се извршуваат преку механизмите preinstall или postinstall. Овие скрипти можат да бидат злоупотребени за кражба на чувствителни податоци.

– Блокирање пакети врз основа на период на чекање (cooldown period) – спречување инсталација на верзии на пакети што се понови од минималната старост дефинирана во безбедносните правила. Периодот може да се постави од 1 до 365 дена. Стандардната вредност е еден ден, а корисниците можат да ја исклучат оваа функција со поставување на вредноста 0.

Корисниците на кои им е потребен пристап до пакет што погрешно бил блокиран од заштитниот ѕид можат да поднесат барање за исклучок. Барањето потоа може да биде одобрено од администраторите на претпријатието и одговорните за безбедноста.

Овој развој доаѓа во период кога Rust 1.100, чие објавување е планирано за 12 ноември 2026 година, се подготвува да воведе поддршка за конфигурирање на минималната старост на објавените пакети. Ова ќе им овозможи на безбедносните скенери и одржувачите на пакетите да добијат време да ги откријат и блокираат злонамерните верзии пред тие да можат да бидат инсталирани или користени од корисниците.

Вредноста се дефинира преку опцијата „global-min-publish-age“ во датотеката „cargo/config.toml“ и им овозможува на корисниците да постават минимална старост на објавување на пакетите, изразена во денови или недели. Доколку не се постави конкретна вредност, стандардно се применува период на чекање од седум дена, со што се прескокнуваат верзиите објавени во тој временски период.

Во текот на изминатата година, слични периоди на чекање беа воведени во повеќе екосистеми со отворен код, вклучувајќи ги npm, Python, Microsoft Visual Studio Code, Ruby, Bun, pnpm и Yarn. Целта е да се зајакне безбедноста на синџирот на снабдување со софтвер преку намалување на можноста новообјавена и сè уште непроверена верзија веднаш да биде вклучена во процесот на изградба на софтверот.

Периодите на чекање додаваат дополнителна пречка и ги забавуваат нападите во кои злонамерни лица, откако ќе преземат контрола врз сметката на одржувачот на некој популарен пакет, објавуваат компромитирана верзија. На овој начин се спречува нејзиното брзо ширење преку рачни или автоматизирани инсталации.

„Компромисот е во тоа што и легитимните безбедносни поправки мора да почекаат, освен ако програмерите не направат исклучок“, соопшти Socket.

„Злонамерниот код не станува безопасен само затоа што поминало одредено време од неговото објавување. Верзијата што ќе успее да избегне откривање едноставно може да го надживее периодот на чекање. Вистинската корист е што им се дава време на истражувачите, одржувачите и регистрите да реагираат пред следното ажурирање на зависностите да го прошири нападот понатаму.“

Извори:

• The Hacker News – GitHub Launches npm Firewall to Block Malicious Packages Before Installation The Hacker News