GitHub Actions сигурност и укрепване на веригата за доставки на софтуер

Начало » Python » GitHub Actions сигурност и укрепване на веригата за доставки на софтуер

GitHub се превърна в де факто дом за съвременна разработка на софтуер, CI/CD и сътрудничество , което означава, че защитата на GitHub Actions и целия набор от инструменти DevOps вече не е по избор. От изтекли тайни до компрометирани зависимости или прекалено разрешителни работни процеси, нападателите все по-често се насочват към самата автоматизация, а не само към приложенията, които изграждате.

Ако вашата GitHub конфигурация не е проектирана с мисъл за сигурността от първия ден, всяко изпълнение на работен процес или актуализация на зависимости може да се превърне в потенциална входна точка . В това ръководство ще разгледаме как да защитим действията, хранилищата, зависимостите и идентификационните данни на GitHub, използвайки вградените възможности на GitHub (включително GitHub Advanced Security, Secret Protection и Code Security) и как тези функции се вписват в по-широкия проблем с веригата за доставки на софтуер, пред който са изправени екипите в реалния свят.

Защо сигурността на GitHub Actions е важна за DevOps и CI/CD

Сигурността сега е в основата на всяка сериозна DevOps практика . Тъй като екипите разчитат на GitHub за контрол на изходния код, преглед на кода, CI/CD конвейери и автоматизация, потенциалният радиус на взрив от един-единствен неправилно конфигуриран работен процес или изтичащ токен нараства драстично.

Последните инциденти във веригата за доставки показват ясна закономерност: атакуващите са насочени директно към автоматизацията на CI/CD и работните процеси на GitHub Actions . Типичните потоци на атака включват злоупотреба с ненадеждни заявки за изтегляне (pull requests), свръхпермисивни токени, променливи препратки към действия и непрозрачни транзитивни зависимости. След като злонамерен работен процес се изпълнява с мощни идентификационни данни и неограничен достъп до мрежата, изтичането на данни и страничното движение стават тривиални.

Пътната карта на GitHub за 2026 г. за Actions има за цел да обърне този модел към автоматизация, защитена по подразбиране . Вместо да разчита на всеки отделен автор на работен процес, за да осигури правилната сигурност, GitHub въвежда контроли на ниво платформа: детерминистични зависимости, управление на работен процес, управлявано от политики, ограничени секретни данни, наблюдение в реално време и защитни стени за изход от мрежата за изпълнители.

В допълнение към тези промени в пътната карта, GitHub Advanced Security и свързаните с него функции вече ви предоставят мощни инструменти : сканиране на код с CodeQL, секретно сканиране и защита от push-ове, Dependabot за предупреждения за уязвимости и злонамерен софтуер, преглед на зависимости, атестации на артефакти, набори от правила за хранилища и други. Използвани заедно, тези възможности могат да трансформират GitHub от потенциална пречка в засилена SDLC платформа.

Основни най-добри практики за защита на GitHub и GitHub Actions

Преди да се потопят в разширените функции на платформата, всеки екип трябва да разбере основите на сигурността на акаунтите и хранилищата . Тези контроли драстично намаляват повърхността за атака и правят по-ефективни по-късните усилия за защита.

Започнете с прилагане на многофакторно удостоверяване (MFA/2FA) за всеки акаунт на разработчик и автоматизатор . Една-единствена открадната парола е достатъчна, за да предостави на атакуващия разрешения за изпращане на код, да отвори злонамерени заявки за изтегляне или да промени работни процеси. С прилагането на 2FA на организационно ниво, достъпът само с парола е ефективно изключен за атакуващите.

След това, третирайте всяко хранилище като чувствителен актив, независимо дали е публично или частно . Задайте хранилищата като частни по подразбиране и ги показвайте публично само когато имате конкретна причина. Редовно преглеждайте достъпа на сътрудниците, екипите и разрешенията, така че всеки потребител да има само това, от което се нуждае (принцип на най-малките привилегии).

Правилата за защита на клонове са друг неподлежащ на договаряне контрол за критични клонове, като например main или release . Изискват проверки на статуса за преминаване, налагат одобрения за преглед на кода, забраняват принудителни push-ове и блокират директни push-ове от отделни лица. Това принуждава всички рискови промени – включително актуализации на работния процес, подобрения на зависимостите и чувствителни към сигурността рефактори – да преминават през проверяем pull request.

Комбинирайте тези контроли с култура на разработка, съобразена със сигурността . Насърчавайте разработчиците да проверяват двойно поетапните промени, да подписват своите комити, да използват пре-комити hooks и да разчитат на CI проверки, които включват сканиране за сигурност. Тази промяна в начина на мислене намалява вероятността тайни, неправилни конфигурации и несигурни модели някога да попаднат във вашия клон по подразбиране.

Пазете тайни и идентификационни данни извън историята на Git

Тайните данни – API ключове, токени, пароли, SSH ключове – са сред най-ценните цели за нападателите . След като бъдат изложени в хранилище, особено публично, те често биват изтрити в рамките на минути и злоупотребявани за дълги периоди, ако не бъдат отменени.

Като основа, никаква тайна не трябва да се споделя с Git.Това включва .env файлове, локални конфигурационни файлове, SSH ключове, облачни идентификационни данни и всеки файл, който може да съдържа чувствителни токени. Строг .gitignore Политиката е първата ви линия на защита: изрично игнорирайте файловете на средата, хранилищата за идентификационни данни, локалните конфигурации и временните артефакти, така че те никога да не се превърнат в проследявано съдържание.

GitHub Advanced Security и GitHub Secret Protection разширяват този модел на превенция с автоматизирано откриване и блокиране . Сканирането на секретни данни идентифицира токени и идентификационни данни във вашите хранилища и повдига предупреждения в раздела „Сигурност и качество“, докато защитата от push-ове активно проверява новите push-ове и може да ги блокира, ако бъде открит секретен файл.

Защитата от push може да бъде настроена и с делегирано байпасиране , където на конкретни потребители, екипи или роли е разрешено да отменят блокове в контролирани сценарии. Когато се случи отменяне, GitHub го записва и въпреки това повдига предупреждение, което ви дава проследимост, вместо тиха повреда.

За персонализирани или вътрешни формати на идентификационни данни можете да дефинирате персонализирани шаблони за сканиране на секретни данни . Тези шаблони разширяват вградените детектори на GitHub, за да улавят специфични за организацията токени, които обикновено не биха били разпознати, като например собствени API ключове или вътрешни системни идентификационни данни.

Използване на тайното сканиране на GitHub и откриването, задвижвано от Copilot

Сигналите за тайно сканиране се активират автоматично за публични хранилища и могат да бъдат включени за частни и вътрешни хранилища, когато използвате GitHub Secret Protection. Всеки път, когато GitHub намери токен или идентификационни данни, той създава сигнал, който свързва засегнатия файл и ред, така че отговарящите могат бързо да отменят и завъртят тайната.

За много големи доставчици на услуги, GitHub се интегрира директно с партньори чрез тайно сканиране за партньори . Когато в публично хранилище или публичен npm пакет бъде открит шаблон на токен, принадлежащ на интегриран доставчик, GitHub уведомява доставчика, за да може той да маркира тези идентификационни данни като компрометирани или да ги отмени автоматично.

За да се избегне спиране на нормалната работа, GitHub ви позволява да настройвате фино колко агресивно се блокират тайните . Използвайки защита чрез push и делегирано заобикаляне, можете да решите кой може да отменя блокове, кой е освободен и кой може да преглежда заявки за заобикаляне. Този баланс поддържа вашите канали за обработка, като същевременно третира тайните като първокласен риск за сигурността.

За екипи, които искат задълбочено прилагане на всеки commit, можете да комбинирате сървърните контроли на GitHub с локални куки за предварително commit . Тези куки могат да изпълняват допълнителни секретни сканирания или проверки на правилата, преди кодът да достигне до отдалеченото устройство, като по този начин ефективно добавят втори слой защита.

Заключване на работните потоци и каналите на GitHub Actions

GitHub Actions е една от най-мощните функции на платформата и една от най-атрактивните цели за атакуващите . Работните потоци могат да изграждат, тестват, внедряват и публикуват артефакти с високо привилегировани идентификационни данни и широк мрежов достъп. Неправилните конфигурации тук са особено опасни.

Всеки работен процес „Действия“ получава настройка по подразбиране GITHUB_TOKEN които могат да имат достъп до хранилището и да извършват операции. Най-добрата практика е тези разрешения да се намалят до минимума, необходим за задачата: само за четене, където е възможно, и разрешения за запис с ограничен обхват, когато е абсолютно необходимо. Избягвайте използването на дълготрайни лични токени за достъп в работни процеси, освен ако няма алтернатива.

Друго основно правило е да закрепване на всички действия на трети страни чрез непроменлив commit SHA вместо етикети като @main or @latestПроменливите тагове могат да бъдат пренасочени по всяко време – независимо дали от компрометиран акаунт на поддържащ или от злонамерен участник – което води до изпълнение на непроверен код от всеки работен процес, който ги използва.

Публичните заявки за изтегляне заслужават допълнително внимание, защото те могат да задействат работни потоци, които изпълняват произволен код във вашата CI/CD среда.Бъдете внимателни със събития като pull_request_target, които се изпълняват с контекст на хранилище и могат да имат достъп до тайни или разрешения за запис, ако са конфигурирани неправилно. Валидирайте и дезинфекцирайте всички входни данни от работния процес и избягвайте директното излагане на стъпките за внедряване или публикуване на ненадеждни данни.

Когато работните потоци смесват чувствителни и нечувствителни операции, разделете ги . По-безопасен модел е да имате един набор от работни потоци за тестване и статичен анализ, който може да се задейства широко, и друг набор за внедряване или пускане, който може да се извика само от доверени участници или защитени клонове.

Пътната карта на GitHub: заключване на зависимостите на работния процес и сигурна екосистема

Един от най-големите структурни проблеми в днешната екосистема на действията е, че зависимостите на работния процес се разрешават по време на изпълнение и често са променливи . Работните процеси обикновено препращат към действия чрез тагове или клонове и тези препратки могат тихо да се преместят към нови коммити с течение на времето.

GitHub решава този проблем чрез заключване на зависимости на ниво работен процес., Ново dependencies: Разделът в работния процес YAML ще ви позволи да заключите както директните, така и транзитивните зависимости към специфични SHA-та на комитите, подобно на начина, по който езиците използват go.mod намлява go.sum за възпроизводими конструкции.

Със заключени зависимости, всяко изпълнение на работен процес става детерминистично и одитираемо . Можете да генерирате данни за заключване чрез GitHub CLI, да ги commit-вате заедно с работния процес и да преглеждате промените в този заключен файл в pull requests. Несъответствията в хешовете ще доведат до бърз срив на работните процеси, преди да се изпълнят каквито и да е задачи, което ще помогне за ранното откриване на неправилна намеса.

Този механизъм също така разкрива преди това скрития граф на зависимостите на съставните действия . Вместо съставните действия тихомълком да изтеглят вложени зависимости, информацията за заключване прави всички посочени действия видими и прегледни, което е от решаващо значение за оценката на риска във веригата за доставки.

От страна на публикуването, пътната карта на GitHub набляга на непроменяемите издания и засилените потоци за публикуване за действия . Чрез намаляване на зависимостта от променливи тагове и затягане на изискванията за издания, GitHub се стреми да направи по-ясно кога и как кодът навлиза в екосистемата, създавайки централни точки за прилагане за откриване и блокиране на злонамерени актуализации.

Изпълнение на работни процеси, управлявани от политики, и набори от правила

Днес много решения за сигурност на работния процес се намират в отделни YAML файлове : кои събития задействат кои задачи, кой може да стартира ръчни изпълнения, кои клонове са надеждни и т.н. В голям мащаб тази разпределена конфигурация става трудна за одит и лесна за неправилно конфигуриране.

GitHub се насочва към модел, основан на политики, изграден върху неговата рамка за набор от правила . Вместо да кодират сложна логика във всеки работен процес, организациите могат да дефинират централни политики, които регулират кой може да задейства работни процеси и кои събития могат да се изпълняват при какви условия.

Правилата за актьори ви позволяват да укажете кои принципали могат да изпълняват работни потоци . Това може да включва конкретни потребители, роли като администратори на хранилища или доверена автоматизация като GitHub Apps, Copilot или Dependabot. Всички останали са блокирани от задействане на чувствителни работни потоци, дори ако имат достъп за запис в код.

Правилата за събития ограничават типовете събития, които могат да изпълняват работни потоциНапример, бихте могли да забраните pull_request_target изцяло и само разрешава pull_request събития, като гарантират, че външните приноси винаги се изпълняват в по-ограничен контекст без тайни на хранилище или достъп за запис.

За да се направи приемането по-безопасно, правилата за изпълнение на работни потоци поддържат режим само за оценка . В този режим правилата не блокират изпълненията; вместо това те регистрират кои работни потоци биха били отказани. Екипите по сигурност и платформа могат да използват тази телеметрия, за да прецизират политиките, да идентифицират крайни случаи и да изградят увереност, преди да наложат твърди блокировки.

Тайни с ограничен обхват и подобрено управление на идентификационните данни

Традиционното определяне на обхвата на секретните данни в GitHub Actions е широко – често на ниво хранилище или организация . В комбинация с работни процеси за многократна употреба, това може да доведе до попадане на секретни данни в контексти, които никога не са били изрично одобрени или напълно разбрани.

Тайните с ограничен обхват въвеждат прецизен контрол, който свързва идентификационните данни директно с изрични контексти на изпълнение . Тайните могат да бъдат ограничени до конкретни хранилища или организации, до конкретни клонове или среди и дори обвързани с конкретни работни потоци или пътища на работния процес.

За работни потоци за многократна употреба, ограничените тайни премахват необходимостта извикващите да предават сляпо мощни идентификационни данни . Вместо това, тайните могат да бъдат прикачени директно към дефиницията на надежден работен поток за многократна употреба. Извикващите извикват работния поток, без автоматично да разпространяват собствените си тайни, което прави границите на доверие ясни и обмислени.

GitHub също така преструктурира модела на разрешения за управление на тайни . Достъпът за запис в хранилище вече няма да е достатъчен за управление на неговите тайни. Правата за управление на тайни ще се преместят в специална персонализирана роля, като същевременно ще останат достъпни за администратори на хранилища, администратори на организации и администратори на предприятия.

Това разделение между приноса на код и администрирането на идентификационни данни доближава организациите до минимални привилегии по подразбиране . Разработчиците могат да продължат да добавят код и да актуализират работните процеси, докато само по-малка група от доверени оператори могат да издават, ротират или отменят чувствителни идентификационни данни.

Осъществяване на наблюдаема и контролируема CI/CD инфраструктура

Изпълнителите на GitHub Actions са на практика критична инфраструктура: те изпълняват ненадежден код, обработват чувствителни токени и комуникират с външни услуги . В исторически план обаче видимостта върху поведението на изпълнителите и изходящия трафик е била ограничена, а контролите - минимални.

Предстоящият поток от данни за действия (Actions Data Stream) на GitHub се справя с проблема с видимостта, като предава телеметрия за изпълнение в почти реално време в платформи, които вече използвате, като Amazon S3 или Azure Event Hub/Data Explorer. Събитията се доставят на партиди с гаранции за поне веднъж и последователна схема за поддръжка на индексиране, корелация и анализ.

С тази телеметрия можете да видите работния процес и изпълнението на задачи в хранилищата, да проследявате кои действия и зависимости се използват и с течение на времето да включвате регистрационни файлове за мрежова активност и решения за политики . Това превръща CI/CD от непрозрачна кутия в наблюдаема система, подобна на производствените услуги.

От страна на контрола, GitHub въвежда вградена защитна стена за изходен трафик за сървъри, хоствани от GitHub . Днес тези сървъри обикновено се радват на неограничен изходящ мрежов достъп, което прави изтичането на данни и извличането на злоупотребени зависимости твърде лесно.

Изходната защитна стена работи извън виртуалната машина на runner-а на ниво 7, така че дори ако атакуващ получи root достъп вътре в runner-а, той не може да го заобиколи . Организациите дефинират точни изходни политики – разрешени домейни или IP диапазони, разрешени HTTP методи, TLS изисквания – и защитната стена ги прилага.

Мониторинг и прилагане на мрежови правила за бегачи

Изходящата защитна стена е проектирана с двуетапен жизнен цикъл: първо наблюдение, след това прилагане . В режим на наблюдение целият изходящ трафик се регистрира и се съпоставя с изпълнението на работния процес, задачата, стъпката и иницииращата команда, която го е задействала.

Този период на наблюдение ви помага да изградите реалистични списъци с разрешени потребители въз основа на действителните модели на трафик . Можете да видите кои регистри, API и работни процеси на услуги се свързват, да идентифицирате неочаквани дестинации и да симулирате въздействието на бъдещи ограничения, без да нарушавате компилациите.

След като се чувствате комфортно с правилата си, можете да преминете към режим на прилагане . В този момент всяка изходяща връзка, която не съответства на одобрените правила, се блокира, което драстично намалява възможностите за изтичане на данни или неоторизирано извличане на зависимости от ненадеждни регистри.

В дългосрочен план визията на GitHub е да третира runner-ите като защитени крайни точки, а не като черни кутии за еднократна употреба . Това означава преминаване към видимост на ниво процес, мониторинг на файловата система, по-богати сигнали за изпълнение и прилагане на политики почти в реално време, предоставяйки на екипите по сигурността първокласен домейн за сигурност на CI/CD, който да управляват.

Когато се комбинира с атестации на артефакти, тази история за защита на крайните точки става още по-мощна . Работните потоци могат да генерират криптографски подписани атестации за произхода на компилацията и съдържанието на SBOM, а низходящите системи – като контролерите за достъп на Kubernetes – могат да проверят тези атестации, преди да разрешат внедряване.

Разбиране на хранилищата на GitHub и техните функции за сигурност

GitHub хранилището е много повече от просто папка с код; то е домът за целия жизнен цикъл на вашия проект , включително изходния код, историята на комитите, документацията, работните процеси, конфигурацията и понякога манифестите за внедряване.

Независимо дали дадено хранилище е публично, вътрешно или частно, то трябва да се третира като чувствителен актив . Ограничете достъпа на сътрудниците, използвайте частна видимост, освен ако нямате основателна причина да не го правите, и редовно следете за секретни данни, злонамерен софтуер и неправилни конфигурации.

Наборите от правила за хранилищата предоставят мощен начин за налагане на съгласувани стандарти в различните клонове и тагове . Можете да изисквате проверки на състоянието, да налагате подписване на комити, да блокирате принудителни отправки и да прилагате единни политики за сигурност и съответствие в много хранилища, без да дублирате конфигурацията.

Съветите за сигурност на ниво хранилище позволяват на поддържащите публични проекти да координират разкриването и корекциите . Можете да обсъждате уязвимости насаме, да изпращате корекции и след това да публикувате съвети, които информират вашата общност за проблема и препоръчителните пътища за надграждане.

Атестациите за артефакти разширяват сигурността отвъд изходния код до двоичните файлове и артефактите, които публикувате . С помощта на GitHub Actions можете да генерирате атестации, които описват откъде идва артефактът (хранилище на изходния код и изпълнение на работния процес) и включват подробности за SBOM. Потребителите могат да проверят тези атестации, за да получат увереност, че артефактите не са били подправени по време на процеса на изграждане и разпространение.

Веригата за доставки на софтуер и моделът за сигурност на зависимостите на GitHub

Съвременните приложения зависят от огромни мрежи от библиотеки, рамки и инструменти на трети страни – веригата за доставки на софтуер . Уязвимостите във всяка от тези зависимости могат да изложат вашия проект и вашите потребители на сериозен риск, включително инжектиране на зловреден софтуер, кражба на данни или прекъсване на услугите.

Графиката на зависимостите на GitHub е гръбнакът на функциите за сигурност на веригата за доставки . Когато е активирана, GitHub анализира поддържаните манифестни и заключващи файлове във вашите хранилища, изграждайки графика на директните и транзитивните зависимости, заедно с техните версии и метаданни.

Графиката на зависимостите се актуализира автоматично, когато манифестите или заключващите файлове се променят в клона по подразбиране , както и когато самите зависимости в upstream се променят. За някои екосистеми допълнителни данни за зависимости могат да бъдат изпратени по време на компилация чрез GitHub Actions, осигурявайки по-пълна видимост на транзитивните пакети, открити по време на компилация.

Можете да видите тази графика от раздела „Информация“ на хранилището и дори да я експортирате като SPDX-съвместим софтуерен списък с материали (SBOM) . Експортирането на SBOM е достъпно чрез потребителския интерфейс на GitHub и REST API, което позволява интеграция с външни инструменти за съответствие и сигурност.

За екосистеми, които не са нативно поддържани от анализ на манифести, GitHub предоставя API за подаване на зависимости . Вашите собствени инструменти или мениджъри на пакети могат да изпращат информация за зависимостите в GitHub, която след това се показва в графа на зависимостите с подробности за това кой детектор я е изпратил и кога.

Преглед на зависимостите и възможности на Dependabot

Прегледът на зависимостите е предназначен да направи риска за веригата за доставки видим по време на прегледа на кода, а не след внедряването . Когато отворите заявка за изтегляне, която променя манифестите на зависимостите, изгледът за преглед на зависимостите подчертава кои зависимости са били добавени, актуализирани или премахнати и показва дати на издаване, популярност и известни данни за уязвимости.

Този контекст помага на проверяващите да решат дали дадена промяна в зависимостта е приемлива . Например, те могат да решат да избегнат добавянето на рядко използвана библиотека с скорошни предупреждения за сигурност или да ускорят сливането на промяна, която замества уязвим пакет с известна добра версия.

Dependabot е автоматизираният енджин на GitHub, който поддържа зависимостите сигурни и актуални . Той обхваща няколко свързани възможности: предупреждения, актуализации на сигурността, актуализации на версиите и предупреждения за злонамерен софтуер, всички свързани с графиката на зависимостите и базата данни за препоръки на GitHub.

Сигналите на Dependabot се появяват всеки път, когато GitHub открие уязвима зависимост във вашия проект . Тези сигнали включват връзки към засегнатите файлове, подробности за уязвимостта и информация за поправената версия. Сигналите се генерират от комбинацията на вашата графика на зависимостите и предупрежденията в базата данни с препоръки на GitHub.

Сигналите за зловреден софтуер на Dependabot се фокусират върху злонамерени пакети, а не само върху уязвимите . Когато базата данни с препоръки на GitHub маркира пакет като зловреден софтуер, Dependabot ви уведомява за засегнатите хранилища, като отново създава връзки към съответните файлове и посочва безопасни версии, ако съществуват.

Актуализации на сигурността, актуализации на версиите и непроменяеми версии

Актуализациите за сигурност на Dependabot автоматично отварят заявки за изтегляне (pull requests), за да преместят зависимостите към минималната безопасна версия, която коригира известна уязвимост . Тези актуализации се задействат от предупреждения, разчитат на графика на зависимостите и поддържат определен набор от екосистеми.

Актуализациите на версиите на Dependabot, за разлика от тях, ви помагат да сте като цяло актуални, дори когато няма конкретна уязвимост . Те изискват конфигурационен файл, изпълняват се по график, който вие определяте, и надграждат зависимостите до най-новата версия, която отговаря на конфигурираните от вас ограничения, използвайки семантично версииране, а не граф на зависимостите.

Изпълнявайки се с GitHub Actions, когато са налични, актуализациите на Dependabot могат автоматично да задействат вашите работни процеси . Това означава, че новите PR-ове на зависимости ще изпълняват вашите тестови и защитни канали, точно както всяка друга промяна, осигурявайки автоматизирани предпазни мрежи за надстройки.

За организации, изправени пред „умора“ от аларми, GitHub предлага автоматични правила за приоритет за Dependabot, както и персонализирани правила за приоритизиране . Те ви позволяват да контролирате кои аларми се игнорират, отлагат или незабавно задействат актуализации на сигурността, което ви помага да управлявате големи обеми аларми в голям мащаб.

Непроменяемите версии засилват целостта на изданията за пакетите, които публикувате . Когато са активирани, изданието и свързаният с него Git таг не могат да бъдат променяни след публикуване. Това предотвратява инжектирането на злонамерени промени от страна на атакуващи или компрометирани поддържащи в съществуващи версии, които потребителите вече използват.

Съгласуване на функции, планове и типове хранилища

Не всяка функция за сигурност на GitHub е активирана по подразбиране или е налична за всеки план, така че разбирането на матрицата е важно . Много възможности са безплатни за публични хранилища, докато частните и вътрешни хранилища може да изискват GitHub Secret Protection, GitHub Code Security или GitHub Advanced Security.

За публични хранилища, графиката на зависимостите и прегледът на зависимостите са активирани по подразбиране и не могат да бъдат деактивирани . Секретното сканиране и някои възможности за сигурност на кода, като например сканиране на код с CodeQL и Copilot Autofix, също са достъпни за публични проекти без допълнително заплащане.

Сигналите на Dependabot не се активират автоматично дори в публични хранилища . Собствениците или администраторите трябва изрично да включат сигналите на Dependabot и графиката на зависимостите за частни хранилища и могат да конфигурират настройките по подразбиране за цялата организация чрез настройките за сигурност и анализ.

Частните хранилища могат да активират същите функции, но често изискват правилните права за продукти . Например, атестации на артефакти в момента са налични за частни хранилища в GitHub Enterprise Cloud. Пакетите Secret Protection и Code Security отключват тайно сканиране за частни хранилища, защита от push-ове, първокласни функции на Dependabot и преглед на зависимостите.

Прегледът на сигурността предоставя видимост на ниво организация , позволявайки ви да виждате тенденции, хранилища с висок риск и състояние на конфигурацията във вашата организация. Това табло за управление е безценно за екипите по сигурност и платформи, които се опитват да разберат къде първо да съсредоточат усилията си за отстраняване на проблеми.

Съчетавайки всичко това, GitHub непрекъснато се развива от проста платформа за хостинг на код в цялостна, управлявана от правила среда за сигурност и автоматизация.Чрез комбиниране на строга хигиена за разработчици (2FA, чисти коммити, стриктно .gitignore (употреба) с функциите за сигурност на GitHub (Разширена сигурност, Защита на секрети, Защита на кода, Dependabot, набори от правила, атестации) и предстоящата пътна карта за действия (заключване на зависимости, секрети с ограничен обхват, политики за изпълнение, контрол на наблюдаемостта и изхода), екипите могат да работят бързо с действия на GitHub, без да дават на атакуващите лесен път до техните CI/CD тръбопроводи.