Лемос от GitLab: ИИ и автоматизация — ключ к DevSecOps

Лемос от GitLab: ИИ и автоматизация — ключ к DevSecOps

30 августа 2023 г.
Директор по информационной безопасности GitLab Джош Лемос о защите CI/CD программного обеспечения с помощью инструментов генеративного искусственного интеллекта и о том, как автоматизация обеспечивает непрерывную безопасность в цепочке поставок разработки программного обеспечения.

GitLab, как и его конкурент GitHub, родился в результате проекта Git с открытым исходным кодом и до сих пор остается компанией с открытым ядром (т. е. компанией, которая коммерциализирует программное обеспечение с открытым исходным кодом, в которое каждый может внести свой вклад). С момента своего запуска в 2011 году в качестве платформы для совместного использования кода с открытым исходным кодом количество ее программного пакета DevOps выросло до более чем 30 миллионов пользователей. По данным компании, в мае 2023 года компания запустила новые возможности искусственного интеллекта на своей платформе DevSecOps с GitLab 16, включая около 60 новых функций и улучшений.

На конференции Black Hat 2023 в этом месяце Джош Лемос, директор по информационной безопасности GitLab, рассказал TechRepublic о DevSecOps и о том, как компания внедряет функции безопасности в свою платформу, а также о том, как искусственный интеллект ускоряет непрерывную интеграцию и упрощает смещение безопасности влево. . Лемос объясняет, что GitLab уходит корнями в управление исходным кодом, непрерывную интеграцию и конвейеры; литейное производство, если хотите, по созданию программного обеспечения.

Перейти к:

    Обеспечение безопасности цепочки сборки в любом масштабе Атаки на цепочки поставок: меньше о выкупе, больше о настойчивости Набор инструментов искусственного интеллекта GitLab: от генерации кода до предложений на естественном языке Сдвиг влево: своевременная обратная связь для разработчиков.

Обеспечение безопасности цепочки сборки в любом масштабе

Карл Гринберг: Можете ли вы рассказать о своей роли в GitLab?

Джош Лемос: Во-первых, когда безопасность была включена в DevOps и весь жизненный цикл кода, это дало нам возможность включить безопасность на более ранних этапах цепочки сборки. Как директор по информационной безопасности я, по сути, выполняю мета-роль, помогая компаниям обеспечить безопасность их конвейеров сборки. Так что я не только помогаю GitLab и делаю то, что я бы сделал для любой компании в качестве директора по информационной безопасности, с точки зрения обеспечения безопасности нашего собственного программного обеспечения, я также делаю это в масштабе для тысяч компаний.

SEE: Каковы последствия генеративного искусственного интеллекта для кибербезопасности? На Black Hat обсуждают эксперты (TechRepublic)

Карл Гринберг: Чем GitLab отличается, скажем, от GitHub в этой экосистеме репозиториев?

Джош Лемос: По сути, эта экосистема представляет собой дуополию. GitHub больше ориентирован на управление исходным кодом и этапы сборки; GitLab сосредоточился на DevSecOps или всей цепочке сборки, поэтому инфраструктура, как код и непрерывная интеграция — весь цикл вплоть до производства.

Атаки на цепочки поставок: меньше о выкупе, больше о настойчивости

Карл Гринберг: Когда вы смотрите на цепочки убийств злоумышленников в этом цикле, атаки, которые DevSecOps стремится предотвратить — например, атаки на цепочки поставок с использованием Log4j — речь идет не о каком-то финансово мотивированном злоумышленнике, требующем выкупа, не так ли?

Джош Лемос: Конечно, это был бы один из результатов, но программы-вымогатели — это довольно конечная цель. Я думаю, что с точки зрения злоумышленника более интересно выяснить, как сохранять молчание, оставаясь незамеченным в течение длительного периода времени. В конечном итоге цель [злоумышленников] — либо скомпрометировать данные, либо получить информацию о компании, правительстве или любой организации по разным причинам; это может быть финансово мотивировано, политически мотивировано или мотивировано компрометацией интеллектуальной собственности.

Карл Гринберг: Или, когда я думаю о постоянном присутствии злоумышленника в сети, я полагаю, что это делают брокеры доступа.

Джош Лемос: Как правило, злоумышленники не хотят уничтожать свой доступ, поэтому да, они хотят хранить эти записи постоянства как можно дольше. Итак, возвращаясь к первому вопросу, моя цель во всем этом — создать среду, в которой компании смогут эффективно защищать свои конвейеры сборки, ограничивать доступ к своим секретам и использовать облачную безопасность и средства контроля безопасности CI/CD в масштабе.

СМОТРИТЕ: Обзор инструмента GitLab CI/CD (TechRepublic)

Набор инструментов искусственного интеллекта GitLab: от генерации кода до предложений на естественном языке

Карл Гринберг: GitHub добился большого успеха с внедрением Copilot. Каковы инновации GitLab в области генеративного искусственного интеллекта?

Джош Лемос: У нас есть более дюжины функций искусственного интеллекта, некоторые из которых предназначены для таких вещей, как генерация кода, что является очевидным вариантом использования; наша версия Copilot, например, — GitLab Duo. У нас есть и другие функции ИИ, которые очень полезны с точки зрения внесения предлагаемых изменений и рецензентов проектов: мы можем посмотреть, кто внес свой вклад в проект, кто, возможно, захочет просмотреть это изменение, а затем дать эти рекомендации с помощью ИИ. Таким образом, все эти инструменты автоматизируют обеспечение безопасности в разработке, и разработчикам не приходится замедляться и искать ошибки.

СМОТРИТЕ: Отчет GitLab о DevSecOps: как ИИ меняет роли разработчиков (TechRepublic)

Карл Гринберг: Но, очевидно, вы хотите сделать это как можно раньше, потому что к тому времени, когда это выйдет в свет, это будет дорого, и вы столкнетесь с проблемой воздействия — живой уязвимостью.

Джош Лемос: Да, это сдвиг влево с точки зрения ужесточения цикла обратной связи на ранних этапах процесса, когда разработчик приступает к фиксации кода, пока они все еще думают об этом фрагменте кода. И они получат обратную связь относительно выявления проблемы и ее устранения в рамках своего процесса и на нашей платформе, поэтому им не придется обращаться к внешнему инструменту. Кроме того, благодаря такому тесному циклу обратной связи им не нужно ждать, пока программное обеспечение будет запущено в производство, а затем выявлять проблему, когда она возникает во время сборки.

Сдвиг влево: своевременная обратная связь для разработчиков.

Карл Гринберг: Какие ключевые проблемы безопасности в процессе разработки программного обеспечения требуют какого-то решения безопасности, помимо тех инструментов, о которых вы говорили?

Джош Лемос: В целом, я думаю, что большая часть смещения левой терминологии на самом деле связана с обеспечением безопасности конвейера программного обеспечения независимо от количества задействованных разработчиков. Мы можем сделать это, предоставляя хорошие, действенные и содержательные отзывы разработчикам, работающим в процессе сборки и разработки. Мы хотим, чтобы эта часть была максимально автоматизирована, чтобы мы могли начать использовать наши команды безопасности для выполнения более глубокой работы по проектированию и архитектуре на более ранних этапах процесса, еще до того, как дело дойдет до той части, где они создают и фиксируют. код.

Карл Гринберг: Мы говорим исключительно об инструментах, основанных на машинном обучении и искусственном интеллекте?

Джош Лемос: Существует множество инструментов и возможностей. Некоторые из них являются традиционными инструментами статического анализа кода; некоторые из них представляют собой сканирование контейнеров, которое ищет известные CVE (распространенные уязвимости и уязвимости) и пакеты. Итак, существует смесь ИИ и не-ИИ. Но есть огромные возможности для автоматизации. И будь то автоматизация искусственного интеллекта или традиционное программное обеспечение, автоматизация типа безопасности CI/CD, они могут снизить уровень ручной работы и усилий, что позволяет вам переключить вашу команду на другие проблемы, которые пока невозможно автоматизировать. И я думаю, что это большое движение в командах безопасности: как мы можем сначала перейти к автоматизации, чтобы мы могли масштабироваться и достичь скорости, которую мы должны соблюдать как компания, и скорости, которую нам нужно достичь с нашими инженерными командами?


Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE