Сигурността на контейнерите има позната слабост. Екипите откриват уязвимости, но превръщането на тези находки в по-нисък риск е много по-трудно. Стандартният образ на контейнер може да включва пакети на операционната система, инструменти за разработка, помощни програми за отстраняване на грешки и библиотеки, които приложението никога не използва. Всеки ненужен компонент може да разшири повърхността за атаки и да добави уязвимости, които трябва да бъдат проучени, коригирани или обяснени по време на одит.
Да вземем образ на NGINX, който още при изтеглянето съдържа 274 категоризирани уязвимости. Сканирането прави тези находки видими, но списъкът с тях не показва на екипа кои компоненти натоварването действително изпълнява. Той не предлага и безопасен начин за премахването им. Истинската възможност в областта на сигурността не е просто да се отбелязват повече проблеми, а да се намали това, което се доставя в образа, без да се нарушава работата на приложението.
Години наред екипите подхождат към този проблем ръчно. Разработчиците разглеждат образите и преценяват кои пакети, библиотеки или инструменти изглеждат ненужни. Този подход трудно се мащабира, трудно се възпроизвежда, когато хората сменят ролите си, и е рисков, когато образът стигне до продукция. Компонент, който изглежда неизползван при статичен преглед, може да е необходим при натоварване, при необичайна транзакция или в рядко изпълнявана част от приложението. Ако образът се счупи след пускането, цената на прекъсването може да надхвърли ползата от премахването на няколко пакета.
От сканиране за уязвимости към доказателства от изпълнението
Решението е да се замени налучкването с укрепване, основано на поведението. Водещият принцип е прост: инсталираното не е непременно изпълняваното. Статичният анализ и спецификацията на софтуерните компоненти (SBOM) описват какво присъства в образа. Наблюдението по време на изпълнение добавя различна перспектива, като показва кои компоненти действително се използват, когато натоварването работи.
Тази разлика е основата на спецификацията на компонентите по време на изпълнение (RBOM). RBOM записва софтуерните компоненти, наблюдавани в употреба от инструментиран контейнер. Разгледана заедно със SBOM, тя помага на екипите да различават пълния опис на инсталираните компоненти от подмножеството, видяно при изпълнение. И двата изгледа са важни. SBOM е полезна за инвентаризация и нужди от съответствие, а RBOM помага за вземането на решения за укрепване въз основа на наблюдавано поведение.
Как да укрепите образите на контейнери в три стъпки
Повторяемият процес на укрепване има три етапа – профилиране, укрепване и валидиране:
Първо, профилирайте натоварването при представителни условия. Това означава да се излезе отвъд простия тест на „щастливия път“ и да се включат функционални тестове, трафик от тестова среда, използване в продукция където е уместно, тестове за натоварване и стрес, както и фъзинг. Целта е да се получи достоверна база за това какво зарежда приложението, кои изпълними файлове стартира, какви конфигурации използва и какви мрежови заявки прави. Качеството на тази база пряко определя качеството на получения образ.
Второ, използвайте базата, за да насочите премахването. Картата на пътищата на изпълнение дава доказателства за решението кои компоненти не са били наблюдавани по време на профилирането. Екипите могат да изберат интензивността на премахване според услугата и нейния рисков профил. Стандартният подход премахва компонентите, които не са наблюдавани при изпълнение, по-консервативният се фокусира върху неизползваните пакети с известни уязвимости, а по-агресивният може да подхожда на вътрешни услуги с по-нисък риск, които понасят по-обширно съкращаване. Важен е и изричен списък за запазване или изключения, който позволява на екипите да запазят компоненти, когато има основателна причина за това.
Трето, валидирайте укрепения образ, преди да го пуснете напред. Изпълнете отново функционалните и интеграционните тестове, сравнете резултатите с оригиналния образ и запазете оригинала като възможност за връщане назад. Валидирането трябва да бъде бариера преди пускане, а не по избор последна проверка. Ако укрепеният образ не издържи, той не бива да продължава, докато причината не бъде разбрана и отстранена. Резултатите от валидирането трябва да захранват и следващата база за профилиране, така че процесът да се подобрява с времето.
Потенциалните ползи от повторяем процес на укрепване могат да бъдат значителни. Премахването на ненужни компоненти може да намали както експозицията, така и оперативните разходи, без промяна в изходния код или логиката на приложението.
Автоматизиране на укрепването на контейнери в CI/CD
Автоматизацията прави процеса повторяем в голям мащаб. Профилирането, заснемането на пътищата на изпълнение, повторното генериране на образа, валидирането и откриването на отклонения могат да се интегрират в CI/CD системи като GitHub Actions, GitLab CI или Jenkins. Когато нов билд започне да използва компонент, който не е бил наблюдаван преди, или използван досега компонент изчезне, конвейерът може да отбележи промяната за преглед. Табло на ниво парк от образи може да показва кои образи са укрепени, какво остава и какви решения са взети.
Автоматизацията обаче не бива да премахва човешката отговорност. Екипите по сигурността и разработката все още трябва да избират интензивността на премахване, да управляват изключенията, да разследват неуспешното валидиране и да одобряват пускания, чувствителни към съответствие. Малко вероятно е една предварителна настройка да подхожда на всяка услуга. Външно изложена услуга може да изисква по-консервативен и подлежащ на одит подход, докато вътрешна услуга може да позволява по-агресивно съкращаване. Контекстът и одобрението остават съществени.
Укрепването на контейнери не е еднократно почистване. Образите се променят, докато пакетите и зависимостите се развиват, така че базата и процесът на валидиране трябва да се повтарят при всеки съответен билд. Организациите могат да започнат, като изберат една услуга, измерят образа ѝ преди и след укрепването и потвърдят, че необходимата функционалност е запазена. По-важният извод е, че сигурността се подобрява, когато екипите намаляват ненужния софтуер чрез стъпки, основани на доказателства и непрекъснато валидирани. Това е много по-смислен подход от простото натрупване на доклади за уязвимости. Сигурните образи трябва да съдържат това, от което натоварването се нуждае, и не повече от онова, което процесът може безопасно да обоснове.