Сегодня мы с радостью объявляем о новом релизе GitLab 17.7 с новой пользовательской ролью Planner, правилами автоматического разрешения уязвимостей, списками разрешённых интеграций инстанса, пользовательским интерфейсом для ротации токенов доступа и многими другими фичами!

Это лишь несколько из более 230 улучшений, добавленных в этом релизе. Читайте дальше, чтобы узнать обо всех основных изменениях.

Мы благодарны сообществу GitLab за 138 изменений, которые вы внесли в релиз 17.7! В GitLab каждый может сделать свой вклад и мы не смогли бы это сделать без вас!

Чтобы заранее узнать, что запланировано на следующий месяц, посмотрите страницу наших будущих релизов — на ней есть видео, посвящённое релизу 17.8.

Награда MVP этого месяца присуждается Vedant Jain

Номинировать участников сообщества GitLab может каждый. Покажите свою поддержку нашим кандидатам или добавьте новую номинацию! ?

Vedant проявил себя как выдающийся участник сообщества GitLab. Он стал известен своим проактивным подходом к совместной работе, увлечённому улучшению кода и навыками сотрудничества с другими участниками сообщества. Он превосходно работает с фидбеком, учитывает его в своей работе и при необходимости обращается за помощью, чтобы гарантировать, что его работа не только будет завершёна, но и будет соответствовать стандартам GitLab.

Ему удалось внести вклад в оптимизацию процессов управления проектами с помощью абстрагированных атрибутов рабочих элементов в одном списке/доске, упорядочения метаданных в рабочих элементах и сохранения свёрнутого состояния виджетов рабочих элементов. Vedant также исправил ссылки в пользовательском интерфейсе на документацию (1 и 2), помогая команде технических писателей в их важной работе по улучшению пользовательского опыта по всему GitLab.

Amanda Rueda, старший менеджер по продукту и специалист по продуктовому планированию в GitLab, номинировала Vedant и подчеркнула его проактивное и ориентированное на сообщество мышление: «Работа Vedant не только отвечает потребностям пользователей, но и способствует созданию более стабильной и надёжной среды GitLab. Внося вклад в исправление ошибок, улучшение удобства использования GitLab и поддержку, он сыграл важную роль в повышении общего качества продукта. Его проактивный подход и работа над несколькими разноплановыми задачами одновременно воплощают основные ценности GitLab: итеративную работу, сотрудничество с клиентами и постоянное совершенствование. Это делает его выдающимся участником сообщества».

«Спасибо всем, кто помог мне довести работу над фичами до конца», — говорит Vedant. «Я очень рад, что могу приносить пользу сообществу GitLab, и с нетерпением жду дальнейшей работы».

Vedant — фронтенд-разработчик в Atlan, платформе для работы с метаданными, созданной для помощи современным дата-специалистам. Также Vedant является наставником Google Summer of Code 2024.

Мы очень благодарны Vedant за его работу, как и всему нашему сообществу разработчиков GitLab, вносящих вклад в наш опенсорсный продукт!

Основные улучшения в GitLab 17.7

Новая пользовательская роль Planner

Мы добавили новую пользовательскую роль Planner, чтобы у вас была возможность получать индивидуальный доступ к инструментам Agile-планирования: эпикам, дорожным картам и доскам Kanban, без избыточного предоставления разрешений. Это поможет вам эффективнее сотрудничать, сохраняя при этом безопасность рабочих процессов и соответствие принципу наименьших привилегий.

Документация по новой роли и оригинальный тикет.

Настройка списка интеграций, которые разрешено использовать в текущем инстансе

Администраторы инстансов теперь могут использовать настраиваемый список интеграций, которые разрешено включать в конкретном инстансе GitLab. Если список пустой, в данном инстансе не разрешены никакие интеграции. После настройки списка новые интеграции GitLab по умолчанию не включаются в список разрешённых.

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

Документация по списку разрешённых интеграций и оригинальный тикет.

Новый метод сопоставления пользователей со внесёнными ими изменениями при прямом переносе

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

• Сопоставлять существующих пользователей в целевом инстансе с проектами и внесёнными изменениями после завершения импорта. Любые импортируемые проектные роли и изменения сначала сопоставляются с пользователями по умолчанию. Все изменения также отображаются как принадлежащие пользователям по умолчанию, пока вы не переназначите их в целевом инстансе.
• Сопоставлять проектные роли пользователей и изменения для пользователей с разными email-адресами в исходном и целевом инстансе.

Когда вы сопоставляете пользователей со внесённым изменением в целевом инстансе, они могут принять или отклонить это назначение.

Узнать больше об этой фиче можно в статье про упрощённую миграцию с сопоставлением пользователей и внесённых изменений. Оставить фидбек можно в комментарии к тикету 502565.

Документация по сопоставлению пользователей и внесённых изменений и оригинальный эпик.

Автоматическое разрешение уязвимостей, которые не были найдены при повторном сканировании

[Инструменты сканирования безопасности] GitLab (https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools) помогают выявлять известные уязвимости и потенциальные слабые места в коде вашего приложения. Сканирование фича-веток выявляет новые слабые места или уязвимости, которые можно устранить перед мержем. Уязвимости, которые уже есть в ветке вашего проекта по умолчанию, после исправления их в ветке фичи будут отмечены как более не воспроизводимые при следующем запуске сканирования ветки по умолчанию. Вам может быть полезно знать, какие уязвимости более не обнаруживаются при сканировании, однако для их разрешения каждую уязвимость необходимо вручную пометить как решённую. При наличии большого числа уязвимостей это может занять много времени, даже при использовании нового фильтра активности и массового изменения статуса уязвимостей.

Мы представляем новый тип политики управления уязвимостями (Vulnerability Management policy) для пользователей, которые хотят, чтобы уязвимости автоматически разрешались (помечались как Resolved), когда они больше не обнаруживаются при автоматическом сканировании. Вы можете настроить политику с новой опцией Auto-resolve (автоматическое разрешение) и применить её к соответствующим проектам. Вы даже можете настроить автоматическое разрешение только для уязвимостей определённой степени опасности или обнаруженные определёнными инструментами сканирования безопасности. После настройки, при следующем сканировании ветки проекта по умолчанию, любые существующие уязвимости, которые больше не обнаруживаются, будут помечены как разрешённые. Данное действие обновляет запись об уязвимости, добавляя примечание об активности, его временную метку и конвейер, в котором была определена уязвимость для устранения.

Документация по правилам управления уязвимостями и оригинальный эпик.

Пользовательский интерфейс для ротации токенов доступа проектов, групп и пользователей

Раньше для ротации токенов доступа проектов, групп и пользователей приходилось использовать API. Теперь это возможно делать через графический интерфейс.

Спасибо shangsuru за эту фичу!

Документация по ротации токенов доступа и оригинальный тикет.

Отслеживание использования компонентов CI/CD в нескольких проектах

Командам DevOps часто необходимо отслеживать, как используются их компоненты CI/CD в конвейерах, чтобы лучше управлять ими и оптимизировать их. Без этого сложно определить использование устаревших компонентов и темпы внедрения, а также поддерживать их жизненные циклы.

Чтобы решить эту проблему, мы добавили новый запрос GraphQL, который позволяет командам DevOps просматривать список проектов, в конвейерах которых используется компонент организации. Это позволит командам DevOps повышать производительность и принимать более обоснованные решения.

Документация по использованию компонентов CI/CD и оригинальный тикет.

Новый обработчик заданий небольшого размера для Linux Arm, доступный для всех подписок

Мы рады представить новый маленький обработчик заданий для GitLab.com, размещённый на архитектуре Linux Arm и доступный для всех уровней подписки. Он имеет архитектуру Arm с двумя vCPU и полноценную интеграцию с GitLab CI/CD. Вы можете использовать его, чтобы создавать и тестировать приложения нативно на архитектуре Arm.

Мы стремимся обеспечивать самую высокую скорость сборки CI/CD и с нетерпением ждём, что вы сможете добиться ещё более коротких циклов фидбека и увеличите скорость поставки программного обеспечения.

Документация по обработчиками и оригинальный тикет.

Другие улучшения в GitLab 17.7

Выбор текстового редактора по умолчанию

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

Это обновление позволит сделать рабочие процессы более удобными для всех, так как интерфейс редактора будет соответствовать индивидуальным предпочтениям пользователей или стандартами команды. Это улучшение — часть нашей работы по улучшению кастомизации и удобства GitLab для всех пользователей.

Документация по установке текстового редактора по умолчанию и оригинальный тикет.

Новая команда /help в GitLab Duo Chat

Откройте для себя все самые крутые фичи GitLab Duo Chat! Введите /help в сообщениях чата и узнайте всё, что он может для вас сделать.

Попробуйте эту фичу и оцените, как GitLab Duo Chat может сделать вашу работу более удобной и эффективной.

Документация по командам GitLab Duo Chat и оригинальный тикет.

Установка пространства имён и пути к ресурсам Flux из задания CI/CD

Чтобы использовать панель для Kubernetes, вам нужно выбрать агент для подключения Kubernetes из настроек окружения, а также опционально настроить пространство имён и ресурс Flux для отслеживания статуса согласования. В GitLab 17.6 мы добавили поддержку выбора агента с помощью конфигурации CI/CD. Однако для настройки пространства имён и ресурса Flux по-прежнему требовалось использовать пользовательский интерфейс или выполнять вызов API. В 17.7 можно полностью настроить панель, используя синтаксис CI/CD с атрибутами environment.kubernetes.namespace и environment.kubernetes.flux_resource_path.

Документация о панели информации Kubernetes и оригинальный тикет.

Эффективная приоритизация рисков с помощью KEV

В GitLab 17.7 мы добавили поддержку каталога известных эксплуатируемых уязвимостей (KEV). Каталог KEV поддерживается CISA и содержит списки уязвимостей, которые были использованы злоумышленниками в реальных условиях. Можно использовать KEV для определения приоритетов для результатов сканирования и оценки воздействия, которое уязвимость может оказать на ваше окружение.

Эти данные входят в общую аналитику и доступны её пользователям через GraphQL. Ведётся запланированная работа по поддержке отображения этих данных в пользовательском интерфейсе GitLab.

Документация по оценке вероятности использования уязвимостей и оригинальный эпик.

Расширенное представление потока кода для продвинутого SAST

Просмотр потока кода (Code Flow view) для продвинутого SAST теперь доступен везде, где отображаются уязвимости, включая:

• Отчёт об уязвимостях

  
  

• Виджет безопасности мерж-реквеста.

  
  

• Отчёт о безопасности конвейера

  
  

• Просмотр изменений в мерж-реквесте

  
  

Новые представления включены на GitLab.com. В GitLab с самостоятельным управлением новые представления включены по умолчанию начиная с GitLab 17.7 (просмотр изменений мерж-реквеста) и GitLab 17.6 (все остальные представления). Дополнительные сведения о поддерживаемых версиях и переключаемых фичах смотрите в разделе о доступности фич для потока кода (Code Flow view).

Чтобы узнать больше о продвинутом SAST, смотрите статью в блоге анонсов.

Документация по представлению потока кода и оригинальный эпик.

Дополнительные уведомления об истечении срока действия токенов

Раньше уведомления об истечении срока действия токена отправлялись по email только за семь дней до истечения срока действия. Теперь такие уведомления также отправляются за 30 и 60 дней. Увеличенная частота и диапазон дат уведомлений позволяют пользователям быть осведомлённее о токенах, срок действия которых может скоро истечь.

Документация по токенам и оригинальный тикет.

Улучшения навигации и удобства использования для центра соответствия

Мы продолжаем улучшать работу центра соответствия требованиям как для групп, так и для проектов.

В GitLab 17.7 мы добавили два ключевых улучшения:

• Теперь пользователи могут выполнять фильтрацию по группам на вкладке Проекты (Projects) центра соответствия. Это даёт пользователям ещё одну возможность фильтровать и искать нужный проект, а также фреймворк соответствия требованиям, связанную с этим проектом.

  
  

• В центре соответствия проекта теперь есть вкладка Фреймворки (Frameworks), которая позволяет пользователям искать фреймворки соответствия, прикреплённые к этому конкретному проекту.

  
  

Обратите внимание, что добавление или редактирование фреймворков по-прежнему выполняется для групп, а не для проектов.

Документация по фреймворкам соответствия требованиям и оригинальные тикеты.

Поддержка эмодзи из Unicode 15.1 ??‍??‍?

В предыдущих версиях GitLab поддержка эмодзи была ограничена старым стандартом Unicode, из-за чего некоторые новые эмодзи были недоступны.

В GitLab 17.7 появилась поддержка стандарта Unicode 15.1, включающего последние дополнения к эмодзи. Например, мы добавили новые символы вроде тираннозавра ?, лайма ?‍? и феникса ?‍?, позволяющие вам лучше выразить себя или своё отношение.

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

Документация по эмодзи и оригинальный тикет.

Поддержка Kubernetes 1.31

В этом релизе добавлена ​​полная поддержка версии Kubernetes 1.31, выпущенной в августе 2024 года. Если вы развёртываете свои приложения на Kubernetes, теперь можно обновить свои подключённые кластеры до последней версии и пользоваться всеми её фичами.

В документации можно узнать больше о наших правилах поддержки Kubernetes и других поддерживаемых версиях Kubernetes.

Документация по поддерживаемым версиям Kubernetes и оригинальный тикет.

Установка environment.action: access и prepare сбрасывает таймер auto_stop_in

Раньше при использовании заданий action: prepare, action: verify и action: access вместе с настройкой auto_stop_in таймер не сбрасывался. Начиная с версии 18.0, задания action: prepare и action: access будут сбрасывать таймер, а action: verify оставит его без изменений.

Сейчас вы можете перейти к новой реализации, включив флаг переключаемой фичи prevent_blocking_non_deployment_jobs.

Несколько изменений, ломающих обратную совместимость, предназначены для того, чтобы различать поведения значений environment.action: prepare | verify | access. Ключевое слово environment.action: access останется наиболее близким к его текущему поведению, за исключением сброса таймера.

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

• тикет 437132

  
  

• тикет 437133

  
  

• тикет 437142

  
  

Документация по настройке auto_stop_in в CI/CD и оригинальный тикет.

Включение защиты от пуша секретных ключей в ваших группах с помощью API

В этом релизе вы теперь можете включить защиту от пуша секретных ключей для всех проектов в вашей группе с помощью REST API и GraphQL API. Это позволяет эффективно включать такую защиту сразу для всей группы, а не для каждого проекта в отдельности. События аудита регистрируются каждый раз, когда эта защита включается или отключается.

Документация по настройке безопасности на уровне группы и оригинальные тикеты.

Улучшена точность обнаружения для продвинутого SAST

Мы обновили продвинутый SAST для более точного обнаружения следующих классов уязвимостей:

• C#: внедрение команд ОС и SQL-инъекция

  
  

• Go: обход каталога

  
  

• Java: внедрение кода, внедрение конца строки (CRLF) в заголовки или логи, подделка межсайтовых запросов (CSRF), неправильная проверка сертификата, небезопасная десериализация, небезопасное использование рефлексии и внедрение внешней сущности XML (XXE)

  
  

• JavaScript: внедрение кода

  
  

Мы также улучшили обнаружение источников пользовательского ввода для C# (ASP.NET) и Java (JSF, HttpServlet) и обновили уровни опасности для обеспечения согласованности.

Чтобы узнать, какие типы уязвимостей обнаруживает продвинутый SAST для каждого языка, смотрите покрытие для продвинутого SAST. Чтобы использовать это улучшенное перекрёстное сканирование файлов и функций, включите продвинутый SAST. Если вы уже включили продвинутый SAST, новые правила активируются автоматически.

Документация по продвинутому SAST и оригинальный эпик.

Токены доступа к группам и проектам в хранилище учётных данных

Токены доступа к группам и проектам теперь видны в хранилище учётных данных на GitLab.com. Ранее были видны только личные токены доступа и SSH-ключи. Дополнительные типы токенов в хранилище позволяют получить более полное представление об учётных данных в группе.

Документация по хранилищу учётных данных и оригинальный тикет.

Новая конечная точка API для получения списка корпоративных пользователей

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

Документация по получению списка корпоративных пользователей и оригинальный тикет.

Новое поле описания для токенов доступа

При создании личного, проектного, группового или деперсонализированного (для действий администратора от имени пользователя) токена доступа теперь можно добавить описание этого токена. Это помогает предоставить дополнительный контекст о токене, например, где и как он используется.

Документация по созданию личного токена доступа и оригинальный тикет.

Удаление базовой роли Owner из кастомных ролей

Базовая роль Owner больше недоступна при создании кастомной роли, поскольку она не добавляет никаких разрешений. Это изменение не повлияет на существующие кастомные роли с базовой ролью Owner.

Документация по созданию кастомных ролей и оригинальный тикет.

Экспериментальные фичи

Определение приоритета уязвимостей SCA

Эта экспериментальная фича — ещё один шаг к тому, чтобы помочь пользователям определять приоритетность уязвимостей, выявленных в ходе сканирования зависимостей или сканирования контейнеров. Пользователи могут включить этот компонент CI/CD в свой файл .gitlab-ci.yml, чтобы создать отчёт о приоритетности уязвимостей, найденных в проекте. Отчёт будет выведен на выходе конвейера.

Компонент запрашивает API GitLab GraphQL, получает данные об уязвимостях и расставляет приоритеты следующим образом:

1. Уязвимости с известными эксплойтами (KEV) имеют наивысший приоритет.

   
   

2. Уязвимости с высокими оценками EPSS.

   
   

3. Уязвимости с высокой степенью опасности.

   
   

Отображаются только обнаруженные и подтверждённые уязвимости. В настоящее время компонент использует данные EPSS и KEV для определения приоритетов уязвимостей. Данные EPSS и KEV находятся только в тех CVE, которые собираются с помощью сканирования зависимостей и контейнеров. Чтобы узнать больше, смотрите документацию по фиче определителя приоритета уязвимостей.

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

Кастомная роль администратора в GitLab с самостоятельным управлением

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

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