Orthos Security — безопасность приложений для продуктовых команд.
Работаем с командами от 3 до 30 разработчиков, у которых нет своего безопасника. Приходят с конкретным поводом: анкета по ИБ от крупного клиента, требования банка или платёжного сервиса перед интеграцией, вопросы технического эксперта инвестора перед сделкой, письмо Роскомнадзора, выход на корпоративных заказчиков.
Что умеем: строим процесс безопасной разработки, делаем архитектурные ревью и пентесты веб-приложений и API, проходим проверки по 152-ФЗ и требованиям ФСТЭК. Работали в контурах без доступа в интернет.
Что здесь будет:
— разборы того, что ломается в продуктовых приложениях, и что с этим делать в понедельник;
— как отвечать на анкеты заказчиков, требования партнёров и запросы регулятора;
— что делать с безопасностью, когда в команде шесть разработчиков и нет бюджета на отдел ИБ.
Чего здесь не будет: новостей из ленты, пересказов чужих статей, списков «топ-10 уязвимостей», рекламы чужих продуктов.
Одна заметка в неделю. В каждой — один вывод, который можно применить сразу.
Семь услуг с описанием, что входит и что не входит, порядок работы и кейсы:
https://orthos-sec.ru/?utm_source=telegram&utm_medium=channel&utm_campaign=pinned
Контакты:
Telegram — @orthos_sec
Почта — orthos.security@yandex.ru
Сайт — orthos-sec.ru
Чтобы ответ был по делу, напишите сразу три вещи: что за продукт и какой стек, что случилось, к какому сроку нужно. Отвечаем в течение рабочего дня.
Работаем с командами от 3 до 30 разработчиков, у которых нет своего безопасника. Приходят с конкретным поводом: анкета по ИБ от крупного клиента, требования банка или платёжного сервиса перед интеграцией, вопросы технического эксперта инвестора перед сделкой, письмо Роскомнадзора, выход на корпоративных заказчиков.
Что умеем: строим процесс безопасной разработки, делаем архитектурные ревью и пентесты веб-приложений и API, проходим проверки по 152-ФЗ и требованиям ФСТЭК. Работали в контурах без доступа в интернет.
Что здесь будет:
— разборы того, что ломается в продуктовых приложениях, и что с этим делать в понедельник;
— как отвечать на анкеты заказчиков, требования партнёров и запросы регулятора;
— что делать с безопасностью, когда в команде шесть разработчиков и нет бюджета на отдел ИБ.
Чего здесь не будет: новостей из ленты, пересказов чужих статей, списков «топ-10 уязвимостей», рекламы чужих продуктов.
Одна заметка в неделю. В каждой — один вывод, который можно применить сразу.
Семь услуг с описанием, что входит и что не входит, порядок работы и кейсы:
https://orthos-sec.ru/?utm_source=telegram&utm_medium=channel&utm_campaign=pinned
Контакты:
Telegram — @orthos_sec
Почта — orthos.security@yandex.ru
Сайт — orthos-sec.ru
Чтобы ответ был по делу, напишите сразу три вещи: что за продукт и какой стек, что случилось, к какому сроку нужно. Отвечаем в течение рабочего дня.
Orthos
Orthos: безопасность приложений для продуктовых команд
Аудит, ревью архитектуры и кода, тестирование на проникновение, проверки в CI/CD, подготовка к 152-ФЗ. Для команд от 3 до 30 разработчиков, у которых нет своего безопасника.
Orthos Security pinned «Orthos Security — безопасность приложений для продуктовых команд. Работаем с командами от 3 до 30 разработчиков, у которых нет своего безопасника. Приходят с конкретным поводом: анкета по ИБ от крупного клиента, требования банка или платёжного сервиса перед…»
Патч в GitLab не закрывает инцидент
10 сентября GitLab выпустил патчи 19.3.2, 19.2.6 и 19.1.8. Среди закрытого CVE-2026-85706 с оценкой 10.0 из 10: обход пути в API коммитов позволял без всякой аутентификации прочитать произвольный файл на сервере. Затронуты версии с 18.7 по 19.3.1, на следующий день CISA внесла уязвимость в каталог активно эксплуатируемых со сроком устранения 14 сентября.
Касается это тех, кто держит GitLab у себя: gitlab.com пропатчен централизованно, self-hosted инстанс обновляет только его владелец. Если инстанс смотрел в интернет и не обновлён после 10 сентября, разумно исходить из того, что файлы уже прочитали. С диска читается gitlab-secrets.json с ключами шифрования и конфиги с паролем к базе, а это разворачивается в содержимое базы: переменные CI, токены раннеров, ключи интеграций.
Обновление закрывает вход, но не отменяет того, что успели унести до него. Патч и ротация секретов это два разных действия, и второе обычно пропускают: система работает, алерт закрыт, задача снята.
Что сделать на этой неделе: обновиться, а потом отозвать и перевыпустить то, что инстанс хранил. Начните с секретов, которые дают доступ в прод: деплой-ключи, токены раннеров, ключи к реестру образов и облаку, пароли сервисных учёток в CI-переменных.
Патч: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/
Каталог CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
10 сентября GitLab выпустил патчи 19.3.2, 19.2.6 и 19.1.8. Среди закрытого CVE-2026-85706 с оценкой 10.0 из 10: обход пути в API коммитов позволял без всякой аутентификации прочитать произвольный файл на сервере. Затронуты версии с 18.7 по 19.3.1, на следующий день CISA внесла уязвимость в каталог активно эксплуатируемых со сроком устранения 14 сентября.
Касается это тех, кто держит GitLab у себя: gitlab.com пропатчен централизованно, self-hosted инстанс обновляет только его владелец. Если инстанс смотрел в интернет и не обновлён после 10 сентября, разумно исходить из того, что файлы уже прочитали. С диска читается gitlab-secrets.json с ключами шифрования и конфиги с паролем к базе, а это разворачивается в содержимое базы: переменные CI, токены раннеров, ключи интеграций.
Обновление закрывает вход, но не отменяет того, что успели унести до него. Патч и ротация секретов это два разных действия, и второе обычно пропускают: система работает, алерт закрыт, задача снята.
Что сделать на этой неделе: обновиться, а потом отозвать и перевыпустить то, что инстанс хранил. Начните с секретов, которые дают доступ в прод: деплой-ключи, токены раннеров, ключи к реестру образов и облаку, пароли сервисных учёток в CI-переменных.
Патч: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/
Каталог CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
GitLab Docs
GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 | GitLab Docs
Learn more about GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 for GitLab Community Edition (CE) and Enterprise Edition (EE).
В Jenkins запись в репозиторий открывает сервер сборки
16 сентября Jenkins выпустил адвайзори: в Script Security Plugin закрыли восемь уязвимостей, шесть из них позволяли обойти песочницу для sandbox-скриптов и Pipeline и выполнить код в JVM контроллера. Затронуты версии до 1415.v9a_f9b_3a_c253d включительно, исправлено в 1422.v06869826dd9b_. На 27 сентября в каталоге активно эксплуатируемых CISA этих уязвимостей нет.
Касается это тех, кто держит инстанс Jenkins у себя. По адвайзори, атакующему нужно право заводить и запускать sandbox-скрипты. Звучит как узкая роль, но Jenkinsfile из репозитория исполняется как раз в песочнице, так что это право есть у каждого, кто может запушить его в ветку, которую собирает Jenkins. А на контроллере лежат ключи деплоя, токены к репозиториям и переменные окружения всех проектов.
Песочница нужна ровно для того, чтобы запись в репозиторий не означала доступ к серверу сборки. Пока плагин не обновлён, эта граница не работает, и запись в любой собираемый репозиторий стоит считать доступом ко всем секретам Jenkins.
Что сделать командам на этой неделе: обновить Script Security через «Управление Jenkins», «Плагины», «Доступные обновления», а потом проверить, у кого есть запись в репозитории, которые собирает Jenkins, и убрать её у тех, кому она не нужна.
Адвайзори: https://www.jenkins.io/security/advisory/2026-09-16/
Каталог CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
16 сентября Jenkins выпустил адвайзори: в Script Security Plugin закрыли восемь уязвимостей, шесть из них позволяли обойти песочницу для sandbox-скриптов и Pipeline и выполнить код в JVM контроллера. Затронуты версии до 1415.v9a_f9b_3a_c253d включительно, исправлено в 1422.v06869826dd9b_. На 27 сентября в каталоге активно эксплуатируемых CISA этих уязвимостей нет.
Касается это тех, кто держит инстанс Jenkins у себя. По адвайзори, атакующему нужно право заводить и запускать sandbox-скрипты. Звучит как узкая роль, но Jenkinsfile из репозитория исполняется как раз в песочнице, так что это право есть у каждого, кто может запушить его в ветку, которую собирает Jenkins. А на контроллере лежат ключи деплоя, токены к репозиториям и переменные окружения всех проектов.
Песочница нужна ровно для того, чтобы запись в репозиторий не означала доступ к серверу сборки. Пока плагин не обновлён, эта граница не работает, и запись в любой собираемый репозиторий стоит считать доступом ко всем секретам Jenkins.
Что сделать командам на этой неделе: обновить Script Security через «Управление Jenkins», «Плагины», «Доступные обновления», а потом проверить, у кого есть запись в репозитории, которые собирает Jenkins, и убрать её у тех, кому она не нужна.
Адвайзори: https://www.jenkins.io/security/advisory/2026-09-16/
Каталог CISA KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Jenkins Security Advisory 2026-09-16
Jenkins – an open source automation server which enables developers around the world to reliably build, test, and deploy their software