Блог

Я работаю в корпоративной среде разработки, которая не склонна к риску, где руководство часто боится перемен. Я проиллюстрировал, как может работать решение Jenkins для нашей команды разработчиков, и выделил несколько успешных примеров, когда помогло пилотное внедрение, но теперь пришло время получить его одобрение для более широкой аудитории и более постоянным способом, и были подняты некоторые проблемы безопасности.

Прежде всего, опасения до сих пор были сосредоточены на том факте, что инструмент с открытым исходным кодом и плагины с открытым исходным кодом созданы участниками сообщества, поэтому руководство обеспокоено тем, что кто-то может вставить вредоносный код, который останется незамеченным нами при обновлении. Мое мнение таково, что если так много других мест могут заставить Jenkins работать, мы, вероятно, тоже сможем, но это не обязательно является очень убедительным аргументом для нашей команды тестирования безопасности.

Мой вопрос в том, может ли кто-нибудь рассказать мне, как они защитили свои собственные реализации Jenkins или какие конкретные возможности Jenkins («песочница» и т.д.) Существуют для предотвращения выполнения вредоносного кода в наших системах?

Использование компонентов сторонних производителей в вашем программном обеспечении или вашей инфраструктуре всегда сопряжено с рисками. Следует отметить одну очень важную вещь: открытый исходный код не менее безопасен, чем закрытый исходный код. Хотя, вероятно, любой может внести свой вклад в проект с открытым исходным кодом, в большинстве случаев проводится проверка, прежде чем он действительно попадет в проект. Конечно, уязвимость может проскользнуть, но чем это отличается от компании-разработчика программного обеспечения с большим количеством разработчиков? Уязвимость может проскользнуть и там, и, исходя из опыта многих из нас, это довольно часто происходит. 🙂 И в случае с закрытым исходным кодом у вас даже нет возможностей разнообразного сообщества, чтобы обнаружить такие недостатки безопасности, лучшее, на что вы можете положиться, — это сторонние тесты на проникновение или сканирование кода, оба из которых пропускают многие проблемы.

В случае такого хорошо зарекомендовавшего себя проекта, как Jenkins, вы можете быть почти уверены, что его безопасность тщательно проверяется, возможно, больше, чем любой коммерческий инструмент с закрытым исходным кодом, который у вас может быть в настоящее время.

Однако, как и в случае с любым сторонним компонентом, вам следует проявлять должную осмотрительность. Регулярно просматривайте онлайн-базы данных уязвимостей, такие как NVD, для поиска проблем безопасности. Устанавливайте обновления по мере их выхода, чтобы снизить риск. Вы должны сделать это и для компонентов с закрытым исходным кодом.

Что касается того, как защитить установку Jenkins, ответ здесь, я думаю, не в том формате, но на их веб-сайте есть целый набор страниц, посвященных этой теме.

Сказав все это и рассмотрев прошлые уязвимости в Jenkins, их довольно много. Вам (и вашему отделу безопасности) решать, как именно вы хотели бы развернуть Jenkins, и являются ли эти прошлые уязвимости достаточно серьезными, чтобы вы считали, что весь инструмент не подходит для вашей среды, учитывая способ, которым вы хотите его развернуть. Опять же, это тот же процесс, которому вы следовали бы и с инструментом с закрытым исходным кодом.