Вышел релиз GitLab 14.4 с запуском DAST-сканирований по расписанию и встроенным отслеживанием ошибок

Мы рады представить вам релиз GitLab 14.4 с запуском DAST-сканирований по расписанию, интегрированным в GitLab отслеживанием ошибок без использования отдельного инстанса Sentry, просмотром удалённых GitLab-репозиториев в Visual Studio Code, графиком динамики внедрения DevOps, GitLab Operator в общем доступе и многим другим!

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

Приглашаем на наши встречи.

MVP этого месяца — Ethan Reesor

Ehtan подключился к работе над расширением GitLab Workflow для VS Code и предложил свою помощь в реализации поддержки удалённых репозиториев для проектов, размещённых на GitLab. Это была непростая работа, которая потребовала не одного, двух, трёх или даже четырёх, а целых пяти мерж-реквестов для реализации этой фичи.

Также Ethan активно участвовал в работе как над тикетами, так и над другими мерж-реквестами в GitLab Workflow, помогая как кодом, так и ответами на вопросы и проблемы пользователей. Ethan даже исправил найденную пользователем ошибку в удалённых репозиториях после завершения работы над ними, чтобы эта фича работала хорошо для всех.

Спасибо Ethan за всё, что он сделал для поддержки расширения GitLab для VS Code!

Основные фичи релиза GitLab 14.4

Запуск DAST-сканирований по расписанию

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure

Динамическое тестирование безопасности приложений (Dynamic Application Security Testing, DAST) в GitLab теперь поддерживает запуск сканирований по расписанию. Ранее DAST-сканирование по требованию можно было запустить только вручную, что ограничивало область использования таких сканирований только случаями, когда сканирование требуется запустить немедленно. С помощью нового планировщика вы можете настроить сканирование DAST на однократный запуск в определённое время или на регулярной основе. Если добавление DAST в конвейеры (в русской локализации GitLab «сборочные линии») не подходит для вашей организации, или если правила безопасности или соответствия требованиям в вашей области предписывают, чтобы сканирование проводилось по расписанию, это нововведение предоставляет простой способ создать запланированное сканирование для удовлетворения ваших потребностей.

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

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

Просмотр удалённых GitLab-репозиториев в Visual Studio Code

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

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

Версия 3.33.0 расширения GitLab Workflow предоставляет возможность открыть удалённый репозиторий. Откройте командную панель и используйте команду GitLab: Open Remote Repository, чтобы найти и затем открыть нужный проект.

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

Спасибо Ethan Reesor за потрясающую работу и множество внесённых мерж-реквестов, которые потребовались для добавления этой фичи!

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

GitLab Operator вышел в общий доступ

(self-managed: FREE, PREMIUM, ULTIMATE) Доступность

Мы рады объявить о выходе в общий доступ GitLab Operator с возможностью запуска продакшен инстансов GitLab на платформах Kubernetes, включая Red Hat OpenShift. GitLab Operator также автоматизирует операции второго дня: обновление компонентов, перенастройку приложений и автомасштабирование. Дополнительную информацию вы можете найти в документации по установке GitLab Operator.

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

График динамики внедрения DevOps

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage

В GitLab 14.4 мы добавили новый график динамики внедрения DevOps на уровне группы. Этот график показывает, как группы используют DevOps-фичи с течением времени, и может дать представление о том, как быстро группы внедряют дополнительные процессы DevOps. График разделён по направлениям Dev, Sec и Ops.

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

Встроенное в GitLab отслеживание ошибок

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor

До версии 14.4 вы могли подключить отслеживание ошибок в GitLab с помощью Sentry, предоставив конечную точку для бэкенда Sentry — либо самостоятельно развёрнутого, либо в их облачном сервисе. С релизом Gitlab 14.4 у вас появляется доступ к совместимому с Sentry бэкенду, уже подключённому к вашему инстансу GitLab. Вы сможете быстро проверять свои приложения и просматривать ошибки непосредственно в GitLab без использования отдельного инстанса Sentry.

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

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

Использование SAML nickname и username assertions на GitLab.com

(SaaS: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Ранее имена пользователей в assertion-атрибутах SAML на GitLab.com определялись на основе адреса электронной почты пользователя. Теперь если ответ SAML включает атрибут username или nickname, для определения будет использоваться имя пользователя GitLab. Это позволяет более свободно задавать имена пользователей при использовании поставщика учётных данных.

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

Сортировка для аналитики цикла разработки на уровне проекта

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Аналитика цикла разработки (Value Stream Analytics) для проектов стала ещё лучше. Теперь вы можете сортировать элементы рабочего процесса на каждой стадии по времени или названию. Мы также добавили пагинацию, чтобы облегчить поиск и отображение интересующих вас тикетов (в русской локализации GitLab «обсуждения»).

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

Навигация по требованиям теперь в разделе тикетов

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Plan

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

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

Переход к Web IDE одним нажатием клавиши

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Теперь пользоваться преимуществами мощной Web IDE и вносить изменения в проекты с помощью вашего браузера стало ещё проще. Просто нажмите клавишу . (точка) на клавиатуре, чтобы открыть Web IDE, в которой будет загружен текущий контекст, и начинайте редактировать нужный файл. Что просматривать файлы репозитория, что делать ревью мерж-реквеста (в русской локализации GitLab «запрос на слияние») — теперь можно приступить к работе, не отрывая рук от клавиатуры.

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

Ограничение числа обработчиков заданий в группе или проекте

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

В GitLab 13.12 мы представили первую версию этой фичи, добавив ограничение числа обработчиков заданий, зарегистрированных в группе или проекте. В версии 14.4 эта фича стала полностью доступной и на GitLab.com, и для отдельных инстансов. Она ограничивает число зарегистрированных обработчиков заданий — теперь максимум 1000. Для администраторов инстансов с самостоятельным управлением это означает, что вы можете вводить это ограничение на уровне группы и проекта. Это поможет снизить административную нагрузку от того, что команды регистрируют новые обработчики заданий, не удаляя неактивные.

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

Создание записей об уязвимостях напрямую через API

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure

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

Мы решили избавиться от этого ограничения, добавив новые свойства GraphQL, используемые при создании объектов типа «уязвимость». Это позволит вам программно добавлять информацию об уязвимостях из внешних источников напрямую в проекты. Вместе с уже существующими инструментами GraphQL для управления уязвимостями это открывает много новых возможностей автоматизации. Например, вы сможете настроить синхронизацию с внешней программой поиска багов или добавлять найденные уязвимости из инструментов безопасности, которые могли не подходить для заданий конвейера. Всё это позволяет получить более полное представление об уязвимостях проекта.

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

SAST-анализатор Semgrep для Go

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure

В GitLab 13.12 мы выпустили анализатор Semgrep для Javascript, TypeScript и Python. Сегодня мы добавляем в анализатор Semgrep поддержку проектов, написанных на языке Go. Начиная с версии 14.4 мы обновляем наш шаблон CI SAST.gitlab-ci.yml для автоматического запуска этого нового анализатора вместе с уже существующим анализатором для Go — GoSec. В одном из будущих релизов мы полностью отключим GoSec, но пока что он будет работать вместе с Semgrep. Мы провели работу по дедупликации результатов, так что вы не должны заметить разницу.

Если вы используете поставляемый GitLab шаблон SAST.gitlab-ci.yml, вам не потребуется ничего делать, чтобы начать использовать анализатор Semgrep для Go. Однако, если вы переопределили этот шаблон по умолчанию, или вы сами управляете конфигурацией SAST CI, вам следует обновить вашу CI-конфигурацию.

Мы с нетерпением ждём этого перехода и рады предоставить вам быстрое и более полное покрытие статическим тестированием безопасности приложений (Static Application Security Testing, SAST). Мы продолжим добавлять в анализатор Semgrep новые правила поиска уязвимостей, а также покрытие для других языков. В тикете для обратной связи вы можете поделиться своим опытом работы с новым анализатором или задать вопросы.

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

Режимы обработки для групп ресурсов

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release

Создание группы ресурсов в задании CI/CD позволяет предотвратить одновременное выполнение одного и того же задания, когда один и тот же конвейер работает параллельно. Такое может произойти, например, если вы делаете пуш нескольких коммитов в очень короткий промежуток времени. Запуск нескольких скриптов развёртывания в одной и той же инфраструктуре может нанести вред вашему инстансу, а в худшем случае — оставить его в повреждённом состоянии. По умолчанию для группы ресурсов установлен режим обработки unordered (неупорядоченный). В этом режиме задание запускается по мере готовности.

В GitLab 14.4 мы добавили два новых режима обработки, которые будут полезны для запуска заданий в определённом порядке: oldest_first и newest_first. В режиме oldest_first система будет запускать задания в порядке FIFO («первым пришёл — первым ушёл»), а в режиме newest_first — в порядке LIFO («последним пришёл — первым ушёл»).

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

Сортировка таблицы внедрения DevOps

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage

Таблица, показывающая уровень внедрения DevOps, стала ещё лучше! Теперь вы можете сортировать группы и подгруппы в таблице DevOps Adoption по имени столбца, что упрощает поиск интересующей вас группы.

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

Фильтрация меток, ограничивающих область действия, с помощью символов подстановки

(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan

Теперь вы можете фильтровать метки, ограничивающие область действия (scoped labels), с помощью символов подстановки. Это поможет быстро находить тикеты, эпики (в русской локализации GitLab «цели») или мерж-реквесты, которые имеют один и тот же ключ из набора меток с ограниченной областью действия. Вы также можете использовать оператор != (не), чтобы отфильтровать элементы, которые не включают метки из набора меток с ограниченной областью действия. Чтобы фильтровать с помощью символов подстановки, просто добавьте * после ввода ключа метки (например, label::*).

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

Пользовательское описание коммита для пакетного предложения изменений

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Предложение изменений прямо в мерж-реквесте ускоряет и упрощает ревью кода: можно быстро предлагать и применять изменения одним нажатием кнопки. В GitLab 13.9 мы сделали этот процесс удобнее, предоставив пользователям возможность добавлять описания коммитов для предлагаемых изменений, чтобы улучшить рабочие процессы, где такие описания нужны. Однако это нельзя было использовать для пакетных предложений — пользователям приходилось либо применять предложения по одному, либо локально применять squash ко всем коммитам перед мержем.

Теперь вы можете задавать своё описание коммита при применении пакетных предложений. Это позволяет авторам и соавторам принимать предложения и следовать рекомендациям по описаниям коммитов для проектов. Это также уменьшает количество коммитов — все предложения объединяются в один коммит с нужным описанием. Если пользователь не указал описание коммита, у такого коммита-предложения будет описание по умолчанию.

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

Уведомления в Slack о новых уязвимостях

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Create

Интеграция Slack в GitLab теперь позволяет создавать уведомления при обнаружении новой уязвимости. Это гарантирует, что нужные члены команды узнают обо всём вовремя и обратят достаточно внимания на новые уязвимости.

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

Повышение безопасности использования CI_JOB_TOKEN для ботов и не только

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify

Переменная CI/CD CI_JOB_TOKEN делает вызовы API в заданиях CI/CD интуитивно более понятными, поскольку обеспечивает расширенную автоматизацию. Например, эту переменную можно использовать с проектами-ботами, которые запускают конвейеры в других проектах. Этот токен недолговечен, но мы постарались сделать его использование ещё более безопасным, добавив настройку, позволяющую вам ограничить проекты, к которым можно получить доступ с помощью токена задания CI вашего проекта. Доступ к другим проектам через API с этим токеном будет запрещён. Это даёт вам дополнительный контроль, к каким проектам у вашего бота будет доступ, и дополнительный уровень безопасности при использовании переменной CI/CD CI_JOB_TOKEN.

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

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

Правила очистки для прокси зависимостей

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package

Вы можете использовать прокси зависимостей GitLab для проксирования и кэширования образов контейнеров из Docker Hub для более быстрой и надёжной сборки. Проблема в том, что со временем ваша команда может добавить в кэш слишком много элементов, что может привести к увеличению затрат на хранение.

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

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

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

Отключили автоматическое решение проблем при обнаружении секретных ключей в мерж-реквесте

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure

Текущая реализация обнаружения секретных ключей (Secret Detection) автоматически устраняет обнаруженные проблемы и помечает их как исправленные. Это происходит при каждом сканировании на ключи, которое выполняется путём сравнения между выполнениями конвейера. С учётом сканирования ключей по Git-истории, введённого в GitLab 13.0, мы не хотим автоматически устранять обнаруженные результаты, потому что это может скрыть оставшиеся уязвимости с опубликованными ключами, при том, что они всё ещё остаются в истории Git. Это изменение в поведении сделает удобнее сканирование ключей по всей Git-истории, а также обеспечит более понятные записи для возможных аудитов при обычном обнаружении секретных ключей и упорядочит управление уязвимостями при обнаружении ключей с помощью других наших сканеров безопасности.

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

Обновления анализаторов SAST

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure

Статическое тестирование безопасности приложений (SAST) в GitLab включает в себя множество анализаторов безопасности, активно управляемых, поддерживаемых и обновляемых командой статического анализа GitLab. Ниже представлены обновления анализаторов, выпущенные в релизе 14.4. В этих обновлениях было расширено покрытие и добавлены прочие улучшения, а также исправлены ошибки.

• Semgrep обновили до версии 0.69.1 (мерж-реквест, список изменений). Было отменено изменение, исключавшее минифицированные файлы из сканирования.

• Flawfinder обновили до версии 2.14.5 (мерж-реквест, список изменений). Добавлено 2 новых правила обнаружения.

• MobSF обновили до версии 2.13.2 (мерж-реквест, список изменений). Пакеты ОС Linux обновлены до последних версий.

• pmd-apex обновили до версии 6.3.9 (мерж-реквест, список изменений).

Если вы используете поставляемый GitLab шаблон (SAST.gitlab-ci.yml), то вам не нужно ничего делать, чтобы получить эти обновления. Однако если вы переопределяете его или используете свой собственный шаблон CI, вам потребуется обновить ваши CI-конфигурации. Если вы хотите использовать определённую версию любого анализатора, теперь вы можете закрепить минорную версию анализатора. Закрепление одной из предыдущих версий отменит автоматические обновления анализатора, и вам потребуется вручную менять версию анализатора в шаблоне CI/CD.

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

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

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

У нас также есть галерея UI Polish для отслеживания важных обновлений наших интерфейсов. Эти обновления, хоть часто и небольшие, делают интерфейсы заметно удобнее.

В GitLab 14.4 мы поработали над тикетами, проектами, майлстоунами (в русской локализации GitLab «этапы») и многим другим! Мы особо выделяем следующие изменения в GitLab 14.4:

• Улучшенная обработка ошибок подключения с реестром контейнеров.

• Настройки прокси зависимостей теперь среди остальных настроек.

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

• Переключатель уровня инстанса/проекта для выбора нужной конечной точки при настройке пакета в реестре npm.

• Добавили параметр «60 дней» в правила очистки образов контейнеров.

• В коммитах теперь можно различать автора и того, кто отправил коммит.

• Улучшение комментариев в мобильной версии.

• Добавили часовой пояс во всплывающее окно профиля пользователя GitLab.

Посмотрите все улучшения интерфейса в GitLab 14.4.

---

Полный текст релиза и инструкции по обновлению/установке вы можете найти в оригинальном англоязычном посте GitLab 14.4 released with Scheduled DAST scans and Integrated error tracking.

Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.