Инжектирането на променливи на средата в процеса на изграждане е standard практика в съвременното CI/CD pipelineЕкипите инжектират променливи на средата в процеса на изграждане, за да предават тайни, токени и конфигурация по време на изпълнение в компилациите без твърдо кодиране на стойности. На пръв поглед това изглежда като прост и безопасен модел.
На практика обаче това често се превръща в един от най-подценяваните рискове във веригата за доставки на софтуер.
Защото след като екипите инжектират променливи на средата в процеса на изграждане, тези стойности престават да бъдат изолирани. Те стават достъпни за всичко, което се изпълнява вътре в този процес. pipelineСкриптове за изграждане, инструменти на CLI, действия на трети страни и дори зависимости могат да ги четат.
Тук нещата започват да се разпадат.
В това ръководство ще разгледаме как екипите инжектират променливи на средата в процеса на изграждане в реалния живот. pipelineкъде всъщност се случват течове и как да се осигури процесът на изграждане, без да се забавя разработката.
Какво означава да се инжектират променливи на средата в процеса на изграждане
В основата си, инжектирането на променливи на средата означава предаване на стойности в pipeline по време на изпълнение, така че задачите да имат достъп до тях по време на изпълнение.
Тези стойности обикновено включват API ключове, идентификационни данни за база данни, токени или специфична за средата конфигурация. Вместо да ги съхраняват директно в код, CI/CD Системата ги зарежда динамично, когато започне изграждането.
Това решава истински проблем. Поддържа кода чист, избягва дублирането и позволява същото... pipeline да работи в среди за подготовка, тестване и производство.
Този модел обаче се основава на предположение, което вече не е валидно: че средата за изграждане е контролирана и предвидима.
Модерен дизайн pipelineне са нито едното, нито другото. Те включват множество стъпки, външни интеграции и зависимости, които изпълняват кода динамично. В резултат на това, след като променлива бъде инжектирана, тя вече не е просто конфигурация. Тя става част от контекста на изпълнение.
Където променливите на средата изтичат в процеса на изграждане
Повечето изтичания на информация не се случват, защото някой изрично разкрива тайна. Те се случват, защото pipelineсе държат по начини, които разработчиците не очакват напълно.
Например, разработчик може да активира подробно регистриране, за да отстрани грешки в неуспешна компилация. CLI инструмент може да отпечата променливи на средата като част от своя изход. Зависимост може да осъществява достъп до променливи на процеса безшумно като част от своето изпълнение.
Нито едно от тези действия не изглежда подозрително само по себе си. Заедно обаче те създават множество пътища за течове.
Тайните могат да се окажат в:
- изгражда лог файлове, които се съхраняват и индексират
- изход за дебъгване, споделен между екипите
- действия на CI на трети страни, които изпълняват външен код
- зависимости, които се изпълняват по време на инсталиране или изпълнение
- временни артефакти, генерирани по време на изграждането
След като дадена тайна се появи в лог файловете, тя рядко остава затворена. Логовете се копират, съхраняват и поддържат в множество системи. В този момент разкриването се простира далеч отвъд оригинала. pipeline.
Ето защо течовете на променливи на средата често се откриват късно и след като щетите вече са нанесени.
Защо екипите инжектират променливи на средата в процеса на изграждане
Въпреки тези рискове, екипите разчитат в голяма степен на инжектиране на променливи в средата. И с основание.
Това позволява pipelineза да остане гъвкав. Един работен процес може да се адаптира към различни среди, да се удостоверява спрямо множество услуги и да променя поведението динамично, без да се променя кодът.
В бързо развиващите се DevOps среди тази гъвкавост е от съществено значение. Гъвкавостта обаче винаги идва с компромиси. Колкото по-динамична е pipeline Колкото повече става, толкова по-трудно е да се контролира какво се случва вътре в него. Всяка допълнителна стъпка, интеграция или зависимост увеличава броя на местата, където може да се осъществи достъп до чувствителни данни.
В резултат на това, инжектирането на променливи на средата се променя от детайл на конфигурацията към проблем със сигурността.
Често срещани рискове при инжектиране на променливи на средата в процеса на изграждане
Рисковете не са теоретични. Те се проявяват в действителност. pipelineвсеки ден.
Тайни, изтичащи в дневниците
Дървените трупи са едни от най-честите източници на експозицияФлаговете за отстраняване на грешки, инструментите на командния ред (CLI) и трасирането на стека често разкриват чувствителни стойности, без разработчиците да забележат.
Веднъж изложени на показ, тези стойности се разпространяват бързо в различните системи.
Прекалено разрешителен достъп
Много pipelineизлага всички променливи на всички задачи. Това създава ненужен риск.
Ако една стъпка бъде компрометирана, тя може да получи достъп до идентификационни данни, от които всъщност не се нуждае.
Зависимост и злоупотреба с действия
Модерен дизайн pipelineразчитат в голяма степен на инструменти и интеграции на трети страни. Тези компоненти работят в същата среда като вашите тайни.
Ако някой от тях се държи злонамерено, той може да осъществява достъп до инжектираните променливи безшумно.
Според OWASPАтаките срещу веригата за доставки често използват надеждни компоненти в процеса на изграждане. Променливите на средата често стават най-лесната цел.
Резервни тайни в кода
Когато компилациите се провалят поради липсващи променливи, екипите понякога добавят резервни стойности, за да запазят pipelineработи.
С течение на времето тези стойности стават commitизползвани или разположени, създавайки дългосрочно излагане.
Най-добри практики за сигурно инжектиране на променливи на средата в процеса на изграждане
| категория | Най-добра практика | Защо има значение |
|---|---|---|
| Съхранение на тайни | Използвайте трезор или мениджър на CI тайни | Предотвратява излагането в кода |
| Контрол на достъпа | Ограничаване на достъпа за всяка задача | Намалява повърхността на атака |
| Влизане | Маскиране на чувствителни стойности | Предотвратява течове |
| Обхват и живот | Използвайте краткосрочни идентификационни данни | Ограничава радиуса на взрива |
| Утвърждаване | Неуспешни компилации, ако липсват променливи | Избягва опасни резервни варианти |
Защо много CI/CD Инструменти за сигурност Miss Env Var Течове
Повечето инструменти за сигурност се фокусират върху сканирането на код или зависимости след завършване на компилацията.
Въпреки това, по време на изпълнение се случват изтичания на променливи на средата.
A pipeline може да инжектира тайни данни правилно и въпреки това да ги разкрива чрез лог файлове или поведение по време на изпълнение. Докато скенер открие проблема, тайната може вече да е компрометирана.
Това създава пропаст между откриването и превенцията.
Екипите се нуждаят от контроли, които действат, докато pipeline работи, а не след като приключи.
Как препоръчваме осигуряване на инжектиране на променливи в средата
На практика ефективната защита се свежда до няколко последователни принципа.
Пазете тайните извън pipelineИнжектирайте ги само по време на изпълнение. Ограничете достъпа до минималния необходим обхват. Използвайте краткосрочни идентификационни данни, когато е възможно.
В същото време наблюдавайте как pipelineдостъп до чувствителни стойности. Неочакваните модели на достъп често показват риск, преди течът да стане видим.
Този подход измества сигурността от реактивно откриване към проактивен контрол.
Как Xygeni помага за защитата CI/CD Тайна инжекция
Вместо да разчита само на сканиране след изграждане, Xygeni анализира как pipelineИзползват променливи на средата, докато се изпълняват. Това включва как тайните се преместват между задачите, как стъпките за изграждане имат достъп до тях и как зависимостите взаимодействат със средата за изпълнение.
Например, Xygeni може да открие кога pipeline излага променливите твърде широко, когато дадена стъпка рискува да отпечата чувствителни стойности в лог файлове или когато зависимост се опитва неочаквано да получи достъп до идентификационни данни.
По същото време, guardrails прилагат политиката директно в pipelineЕкипите могат да блокират опасни компилации, да ограничат секретния достъп до конкретни задачи и да предотвратят рискови конфигурации, преди те да достигнат до продукция.
Защото това се случва в рамките на CI/CD работния процес, разработчиците не е необходимо да променят начина си на работа. Сигурността става част от pipeline, а не отделна стъпка.
В резултат на това екипите получават видимост върху това как се използват тайните, контролират как те се разкриват и намаляват риска от изтичане на информация, без да забавят доставката.
Заключителни мисли
Това обаче въвежда и слой риск, който често остава незабелязан.
Предизвикателството не е дали да се използват променливи на средата, а как да се контролира тяхната експозиция по време на изпълнение.
В съвременните DevOps среди, предотвратяването на течове по време на процеса на изграждане е много по-важно от откриването им впоследствие.
