Материал подготовлен Дмитрием Дружиным
Начать тему тестирования безопасности приложений стоит с того факта, что абсолютно безопасных систем в индустрии не бывает. Все системы подвержены возникновению уязвимостей и, чем больше система, тем выше шанс, что она будет атакована
Бизнес может какое-то время пренебрегать обеспечением должной степени защищённости своих систем, но столкнувшись с крупной атакой единожды, менеджмент быстро понимает важность обеспечения безопасности и иногда может даже перебарщивать с требованиями по защищённости
Наша задача, как разработчиков, хорошо понимать, как нас могут взломать и что нам говорят безопасники. Мы должны уметь работать с автоматическими тестами безопасности и уметь проводить такие тесты вручную (иногда такие навыки особенно полезны, например, в стартапах)
О чём мы сегодня поговорим:
То есть, к концу лекции вы поймёте, как мыслят хакеры и безопасники, а так же научитесь тестировать и автоматизировать тестирование безопасности своих приложений
У любого взлома есть мотивация
Существуют хактивисты, чьи мотивы нематериальны, но чаще всего атаки происходят ради денег. White hat хакеры зарабатывают на проведении пентестов для защиты от black hat хакеров — тут всё предельно ясно. Но на чём зарабатывают black hat хакеры:
Этим сценариям подвержены не только частные лица, но и компании. И вот на примере самых крупных взломов (чаще всего, взломов компаний), можно вывести 7 ступеней эксплуатации, по которым хакер постепенно проникает в систему
Давайте поставим себя на место хакера: вот мы захотели взломать какую-нибудь систему.
Для начала нужно произвести хотя бы примерную опись её компонентов, и, в идеале, разобраться в том, как они внутри устроены и сконфигурированы. Для этого мы проводим разведку и постепенно строим полную карту поверхности атаки.
От качества разведки зависит 70% успеха пентеста. Существуют атаки, успешно проводимые сразу на этапе сканирования (например, успешный вход по слитым учётные данным или через перебор слабого пароля)
Чем раньше вы понимаете, что видит внешний мир — тем легче защититься
site: — поиск внутри домена или зоны (site:example.com).inurl: — слова в URL.intitle: — слова в заголовке страницы.filetype: — конкретный тип файла (pdf, xls, docx).intext: — слова в теле страницы.cache: — посмотреть кэшированную версию.“exact phrase” — точная фраза в кавычках.OR, AND, и т.д.WHOIS/RDAP, DNS history: Passive DNS/PassiveTotaltheHarvester, Amass, Subfinder/Sublist3r — автоматический поиск поддоменов/информацииcrt.sh — нахождение поддоменов через сертификатыShodan, Censys — инвентаризация устройств и сервисов, построение карты инфраструктурыWayback Machine, Common Crawl — история сайтаGitHub/GitLab/Bitbucket — поиск утёкших ключей/конфигов (truffleHog для автоматизации поиска)dig, в том числе, для попытки передачи зоны (AXFR)S3Scanner, cloud_enum — поиск открытых бакетовwget или curl с низкой скоростью)sslscan, sslyze — проверка конфигурации TLSSubdomain bruteforce с низкой частотой запросов (Amass в passive режиме)nmap, masscan — сканирование по портамBurp Suite (active scan), OWASP ZAP, Nikto — веб-сканерыNuclei — шаблонный высокоскоростной сканер уязвимостей (web, network, misconfig, CVE)Nessus, OpenVAS — уязвимости хостов, сетей и сервисов (полный аудит)Hydra — brute-forceMetasploit — эксплуатация (в авторизованных тестах)Postman, Burp Suite + extender), SQLmap — для тестов инъекцийСredential stuffing/harvesterHMACCSP) и Subresource Integrity (SRI)production, staging, dev — не публиковать staging или dev в публичной зоне!.env) или в Secret Manager, но не в коде. Добавить .env, .env.local, .env.* и любые файлы с секретами в .gitignore, чтобы исключить попадание в репозиторий. Внедрить в CI использование git-secrets и truffleHogCORS и открытые API — разрешать запросы только с доверенных доменовWAF для публичных веб-приложений, rate limiting, bot protectionDependabot или renovate и регулярные обновленияSSLv3, TLS1.0/1.1), обеспечить PFS и сильные шифрыCSP, HSTS, X-Frame-Options, X-Content-Type-OptionsHttpOnly, Secure, SameSite=strict/ladjusteddirectory listing, убрать debug endpoints (например: /debug, /admin) из публичного доступаAdmin:Admin!)AXFR) для внешних запросов — настроить ACL по конкретным IPS3/Blob контейнеры: приватность по умолчанию, политика доступа по принципу наименьших привилегийfirewall и security groupsSIEM), настроить alert по аномалиям (необычные сканы, большое количество 404/500)CI runners и service accountsМы выяснили, как готовится поверхность для проведения атаки и сейчас мы можем переходить к самой атаке. В этом нам поможет топ уязвимостей от OWASP (Open Worldwide Application Security Project).
OWASP Top 10 — это список из 10 наиболее распространённых и опасных категорий уязвимостей. Он основан на глобальной статистике реальных инцидентов и составлен комитетом из сотен экспертов по кибербезопасности. Именно поэтому, в практически любой вакансии ИБ-специалиста, и, тем более, пентестера, можно встретить требование к знанию этого рейтинга.
Рейтинг обновляется каждые 4 года, актуальная версия вышла в 21 году и сейчас ещё готовится версия 25 года, так что мы рассмотрим именно OWASP Top-10 2021
В этот рейтинг вошли такие категории уязвимостей, как:
Приложение не реализует или неправильно реализует проверки прав доступа — пользователи/клиенты получают доступ к данным/функциям, которые им не положены
Часто приводит к краже данных, эскалации прав (например, обычный пользователь становится админом) и массовым утечкам. Broken access control регулярно встречается в полевых исследованиях и занимает верхнюю строчку Top10
Как протестировать:
IDOR (Insecure Direct Object Reference): изменяя параметр ?user_id=123ID, UUID, GUID, параметры в URLBurp Intruder, Authorize, AutoRepeaterffuf или gobuster для поиска скрытых эндпоинтовUnit и Integration тесты по тестовым сценариям авторизацииJWT, ролей/прав (RBAC/ABAC)Как исправлять:
Идеи для Demo:
Неправильное или вовсе отсутствующее шифрование данных ведёт к раскрытию конфиденциальной информации. Основные проблемы, это: слабые алгоритмы, хранение паролей в открытом виде, отсутствие TLS, неправильная конфигурация криптографических библиотек
Утечка персональных и платёжных данных влечёт юридические и финансовые риски. Часто причиной утечек является хранение секретов в коде или слабые/устаревшие алгоритмы шифрования
Есть два типа шифрования:
SHA, AES, DESRSA, TLS, Diffie-HellmanКак протестировать:
HTTPS, HSTScookie-флаги (Secure, HttpOnly, SameSite)bcrypt, argon2 а не md5/sha1)testssl.sh, OWASP ZAP passive scangit-secrets, truffleHog) на предмет утекших ключейКак исправлять:
testssl.sh)argon2 / bcrypt / scrypt) + saltVault / Cloud secret manager, проводить ротацию ключейИдеи для Demo:
md5() для паролей → быстро объяснить почему не годится.Приложение подставляет неподготовленные (негарантированные) данные в команды или запросы — это позволяет выполнять чужой код/запросы (SQLi, command injection, XPATH, LDAP и т.д.)
SQLi долгое время был источником крупных утечек. Инъекции легко автоматизируются и дают прямой доступ к базе данных или всей системе целиком
Как протестировать:
sqlmap, Burp Repeater, ручная проверкаXSStrike, sqlmap для автоматизации SQLi, Burp Suite для тестированияКак исправлять:
Идеи для Demo:
' OR '1'='1» SQLi в Juice Shopsqlmap для демонстрации разрушительного потенциала.Проблема на уровне проектирования: отсутствуют или неэффективны защитные меры (модель угроз, secure by design). Это не просто баг в коде — это отсутствующие или неверно подобранные меры обеспечения безопасности
Новая категория в 2021 году. Подчеркивает, что многие уязвимости — следствие решений на архитектурном уровне (не реализованы требования безопасности, неправильная модель доверия). Например, пользователь может оформить возврат без списания, или случайно изменить статус заказа без авторизации
Никакой сканер не найдёт такие уязвимости — здесь решает ручная работа и понимание бизнес-процессов
Как протестировать:
Burp Repeater, PostmanКак исправлять:
Secure SDLC: threat modeling на ранних этапах, security gates в архитектурном ревьюrate limit) ещё на этапе дизайнаИдеи для Demo:
Неправильно настроенные серверы, облачные ресурсы, лишние доступы в поде (debug endpoints, directory listing), default credentials и пр. — всё это даёт лёгкий путь атакующим
Частый источник проникновений: включённые debug-консоли, оставленные публичными бакеты, открытые админ-панели
Nuclei с шаблонами Misconfiguration — мощный инструмент для быстрой проверки
Как протестировать:
Nuclei, Nikto, WappalyzerX-Frame-Options, Content-Security-Policy, X-Content-Type-Options)Как исправлять:
Идеи для Demo:
server: Apache/2.4.XX + directory listing → загрузка файловМногие компании падают не из-за новых 0day, а из-за старых библиотек
Классический пример — Equifax (Apache Struts CVE → крупная утечка данных) — демонстрация того, как unpatched компонент приводит к катастрофе
Проверяйте версии и changelogs, используйте Retire.js для front-end, Nuclei для CVE-шаблонов, и обязательно внедряйте автоматические dependency-сканеры в pipeline
Как протестировать:
Retire.js, Dependency-Track, Nuclei -t cves/Snyk, Dependabot, OWASP Dependency-CheckКак исправлять:
Идеи для Demo:
npm audit / pipdeptree → показать уязвимые зависимости.Этот пункт про все проблемы с реализацией логина/регистрации/session management: слабые пароли, отсутствие MFA, плохая ротация токенов, утечки session ID, predictable tokens
Credential stuffing, brute force, session fixation приводят к захвату аккаунтов. Частая причина — слабые контрольные механизмы на login endpoints Проверяйте, можно ли подобрать пароль, обойти механизм MFA, использовать токен после logout
Burp Intruder и Hydra позволяют быстро тестировать устойчивость к брутфорсу
Как протестировать:
Burp Intruder, ZAP Active Scan или Hydra для теста защиты от брутфорсаКак исправлять:
OAuth2/OIDC)Идеи для Demo:
Код, библиотеки, обновления или CI/CD процессы не защищены (не подписываются/не проверяются), что позволяет внедрять в поставку вредоносный код (supply-chain attacks)
Атаки на цепочку поставки (подмена пакета, взлом CI) могут внедрить бэкдор ещё до деплоя — их очень трудно обнаружить. OWASP выделяет insecure CI/CD и непроверенные внешние источники как риск
Проверяйте, откуда приложение получает зависимости и обновления
Верифицируйте подписи и checksums — особенно для загружаемых бинарников!
Как протестировать:
Как исправлять:
Идеи для Demo:
Недостаточное логирование/мониторинг мешают обнаружить или расследовать инцидент — если не видно входящих атак, поздно реагировать
Многие инциденты приводят к распространению из-за того, что атака не обнаружена вовремя — поэтому логирование и корелляция событий критичны!
Что это: отсутствие/недостаточность логов и алертов → позднее обнаружение инцидентов
Как протестировать:
Как исправлять:
Идеи для Demo:
Уязвимость, когда приложение запрашивает ресурс по URL, который контролирует пользователь, и не фильтрует/валидирует этот URL — это позволяет серверу отправлять запросы к внутренним ресурсам (metadata service, internal APIs), обходя сетевые границы
Классический крупный инцидент — Capital One (2019): SSRF в комбинации с конфигурацией позволил извлечь IAM-креды из IMDS и получить доступ к S3-бакетам. Это яркий пример опасности SSRF в облаке
Для blind-случаев используйте interact.sh или Burp Collaborator для отслеживания внешних запросов
Как протестировать:
Burp Collaborator, interact.sh, ngrokURL, JSON, XMLКак исправлять:
Идеи для Demo:
http://169.254.169.254/latest/meta-data → показать, почему это опасноВот ваш боевой набор web-пентестера:
Burp Suite — король перехвата и анализа, ffuf и wfuzz помогают найти скрытые директории и API, Nuclei автоматизирует шаблонные уязвимости, sqlmap — классика для SQLi
Сегодня desktop-клиенты часто взаимодействуют с API, работают с токенами и обрабатывают чувствительные данные. Поэтому для безопасника важно понимать, как их анализировать, декомпилировать и тестировать с точки зрения уязвимостей и архитектуры
Сегодня desktop-клиенты бывают разных типов: классические native-приложения, Java-программы, .NET-продукты, и всё чаще — Electron и гибридные клиенты, использующие HTML/JS внутри оболочки Chromium
Это важно, потому что от технологии зависит подход к пентесту и инструменты анализа
Основные этапы:
Методология desktop-пентеста во многом похожа на web, но глубже уходит в уровень ОС
Начинаем с разведки и анализа исполняемых файлов, затем проверяем взаимодействие с сетью и системными ресурсами, после чего тестируем защиту данных и логическую устойчивость
sigcheck, strings, exiftool, diecDependency Walker, dnSpy, ILSpyНа этапе разведки нужно собрать максимум информации: кто издатель, какие технологии и зависимости используются, куда складываются данные, есть ли цифровая подпись
Подписывайте свои программы: подпись гарантирует подлинность и в глазах пользователей неподписанные бинарники и сторонние DLL — часто признак уязвимости
IDA, Ghidra, dnSpy, JADXIDA, GhidradnSpyJADXСтатический анализ — это взгляд внутрь приложения без его запуска.
Находим хардкодные пароли, API-токены, приватные ключи и проверяем, где происходит аутентификация и авторизация
Иногда достаточно одной строки вроде Authorization: Basic Zm9vOmJhcg==, чтобы получить полный доступ
Demo: полный реверс через dnSpy
Procmon, Process Explorer, x64dbg, Frida, WiresharkДинамический анализ показывает, что программа делает на самом деле
Procmon и Process Explorer отслеживают обращения к файлам, реестру и DLL
Frida позволяет внедряться в процесс и перехватывать функции — например, CreateFileA или CryptDecrypt
Так можно увидеть, где хранятся ключи, токены или конфиги
SQLite, JSON, XML, Registry, .config файлыDB Browser, grep, binwalk, CyberChefМногие приложения хранят пароли “в шифре”, но на деле — это base64
Проверяйте локальные базы (часто SQLite), файлы .config или XML с токенами
DB Browser и CyberChef помогают быстро увидеть, что на самом деле лежит внутри
Burp, mitmproxy)Часто desktop-клиенты — это просто оболочка над web-API
Перехватывайте трафик Burp’ом или mitmproxy, смотрите на токены, заголовки и авторизацию.
Можно ли повторно использовать токен без входа?
Можно ли сымитировать запрос к API без клиента? — это классический случай Broken Access Control
IDA, Ghidra, dnSpy, jadxProcmon, Process Explorer, FridaBurp Suite, mitmproxy, WiresharkHxD, x64dbg, binwalkgrep, CyberChef, stringsВсё это можно комбинировать в зависимости от технологии приложения
Частые проблемы desktop-приложений: пароли и токены в plaintext, подмена обновлений, инъекции в параметрах запуска или путях файлов, и уязвимые механизмы IPC
Особенно опасны десериализационные баги в .NET и Java
Важно помнить, что каждая запущенная программа имеет свой процесс в системе с правами доступа пользователя, от которго этот процесс запущен: запустив уязвимую программу от администратора — мы даём потенциальному хакеру админский доступ к своей машине
Главная цель мобильного пентеста — оценить, насколько приложение защищает пользовательские данные и взаимодействует с сервером
Мы проверяем не только сетевой слой, но и то, что происходит на устройстве — где хранятся токены, логи, кэш и прочее
Технологии:
Java/Kotlin, Swift/ObjC), кросс-платформа (React Native, Flutter), Progressive Web Application (JS)REST / GraphQL / gRPC APISharedPreferences, Keychain, SQLite, файлыSandbox, разрешения, подписи, SELinuxМобильное приложение — это не изолированное ПО
Оно зависит от бэкенда, хранилища и системы безопасности самой ОС
Поэтому mobile-пентест всегда сочетает анализ приложения, API и инфраструктуры
Методология mobile-пентеста почти та же, что у web и desktop
Сначала делаем разведку, затем статический и динамический анализ, тестируем API, и — если нужно — проводим runtime-манипуляции для обхода защит
aapt dump badging, apktool, exiftool)jarsigner -verify, apksigner)На этапе Recon извлекаем APK/IPA и получаем базовую информацию: package name, версии, разрешения
Проверяем, есть ли экспортированные компоненты — Activity, Service или ContentProvider, доступные без авторизации
Это часто даёт вектор для атаки
Demo: анализ через FlutterShark
apktool, jadx, MobSFAndroidManifest.xml)Статический анализ показывает, что внутри приложения
apktool и jadx позволяют декомпилировать .dex файлы и искать ключи, токены, URL и настройки логирования
Особое внимание — на AndroidManifest.xml: там указаны разрешения, интенты и экспортируемые компоненты
Frida, Objection, MobSF Dynamic, WiresharkFrida и Objection позволяют внедрять хуки в функции, чтобы перехватывать токены, отключать SSL pinning, анализировать API-вызовы
MobSF может автоматически запускать приложение в песочнице и собирать логи
Burp, mitmproxy, ZAP)Frida scripts, Objection, Xposed, MagiskTrustUserCerts)replay-атакrate-limit и brute-forceПочти каждое мобильное приложение — это клиент к API
Поэтому важно перехватывать и анализировать сетевой трафик
Если включён SSL pinning, используйте Frida-скрипты для обхода
Дальше — стандартные web-техники: проверяем авторизацию, replay, rate-limit, csrf-токены
SharedPreferences / Keychain / NSUserDefaultsSQLite, Realm, JSON-файлыadb pull, sqlite3, MobSF, FridaХранение данных — частая проблема
Проверяйте, не лежат ли токены или пароли в SharedPreferences или SQLite без шифрования
Используйте adb pull для выгрузки данных, sqlite3 — для анализа.
MobSF автоматически находит insecure storage
ProGuard, DexGuard)jadx, grep, strings)Если приложение не защищено обфускацией — можно прочитать бизнес-логику прямо из кода
Проверьте, включён ли ProGuard/DexGuard, и нет ли читаемых API-ключей
Также проверьте контроль целостности — если можно модифицировать APK, то можно внедрить произвольный код
Hook функций в рантаймеSSL Pinning и Root DetectionFrida, Objection, Xposed, MagiskFrida и Objection — это стандарт для runtime-тестирования
Можно хукать функции, например checkRoot(), verifyCertificate(), getToken()
Это позволяет обходить защиту и анализировать внутреннюю логику приложения.
Objection делает это проще: он даёт готовые команды вроде objection explore или objection bypass sslpinning
frida-ios-dump, class-dump, MobSFKeychain и plist-файловFrida, LibHooker)Swift, ObjC Runtime HooksНа iOS доступ к файловой системе ограничен, но после jailbreak можно проводить глубокий анализ
Извлекаем IPA, анализируем структуры и ключи
class-dump и frida-ios-dump позволяют исследовать классы и методы.
В iOS часто встречаются проблемы с Keychain и сохранением сессий
apktool, jadx, class-dump, HopperFrida, Objection, Xposed, CycriptMobSF, Drozer, QARK, AndroBugsBurp, mitmproxy, ZAPadb, sqlite3, plistutilЭто основной набор инструментов для мобильного пентеста
MobSF закрывает 70% рутины: автоматический анализ APK/IPA, SAST и DAST отчёты
Frida и Objection — для runtime, Burp — для сетевого уровня
certificate pinningСамые частые уязвимости — это хардкод ключей, insecure storage и слабая авторизация API
Многие мобильные приложения доверяют клиенту — а это ошибка
Нужно всегда проверять авторизацию на серверной стороне
OWASP Mobile Top-10 — отличный ориентир для аудита
Каждый пункт отражает типичную ошибку мобильных разработчиков: от плохого использования API до хранения ключей в коде
Раньше пентест проводили раз в год — после релиза
Сегодня, когда релизы выходят каждую неделю, такой подход не работает
Безопасность должна быть частью DevOps-процесса
Мы говорим о том, как автоматизировать SAST, DAST и пентест-паттерны в CI/CD, чтобы выявлять проблемы ещё до продакшена
DevSecOps — это не просто инструменты, а сдвиг мышления
Безопасность перестаёт быть барьером на финальном этапе и становится встроенной функцией процесса сборки и доставки
Идея проста: тестируй безопасность на каждом коммите, а не раз в квартал
Модель уровней помогает выстроить непрерывный pipeline
SAST ловит уязвимости в коде, DAST — в работающем приложении, а пентест завершает цикл, проверяя всё глазами человека
SonarQube, Semgrep, Bandit, CodeQL, CheckmarxSAST — это фундамент автоматизированного пентеста
Он позволяет находить ошибки в коде до сборки
Например, Semgrep или Bandit можно подключить к GitHub Actions: каждый PR анализируется, и в код-ревью прилетают замечания по безопасности
Код (слайд):
name: Security Scan
on: [push, pull_request]
jobs:
semgrep:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: returntocorp/semgrep-action@v1
with:
config: "p/owasp-top-ten"
Пример элементарной интеграции Semgrep
При каждом пуше код проверяется по правилам OWASP Top-10
Такой шаг добавляет меньше минуты к билду, но ловит десятки типовых ошибок
OWASP ZAP, Burp Suite Pro, Arachni, NiktoDAST работает уже на развернутом стенде — он тестирует приложение “снаружи”.
OWASP ZAP или Burp Suite API позволяют автоматизировать фаззинг и сканирование.
DAST идеально подходит для nightly job — когда билд уже прошёл и можно протестировать staging
Код (слайд):
zap-baseline.py -t https://staging.example.com -r zap-report.html -J zap.json
zap-baseline.py — это быстрый способ автоматического теста без GUI.
Он проверяет типовые уязвимости и генерирует отчёт в HTML/JSON.
Можно встроить в Jenkins или GitLab Runner, и отчёты будут собираться при каждом деплое
HTTP, DNS, SSL, файловые тестыCI/CD, cron, API мониторингNuclei — must-have инструмент для автоматизации пентеста
Он работает по шаблонам, которые обновляются сообществом
Можно писать свои: например, проверку уязвимого пути или эксплойта конкретного продукта
Отлично интегрируется в CI и легко масштабируется
Код (слайд):
id: test-xss
info:
name: Reflected XSS
severity: medium
requests:
- method: GET
path:
- "{{BaseURL}}/?q=<script>alert(1)</script>"
matchers:
- type: word
words: ["<script>alert(1)</script>"]
Это простейший пример шаблона для XSS
Nuclei запустит GET-запрос и проверит, отражается ли payload
Так можно быстро собирать кастомные проверки под конкретное приложение
burp --scan --url https://target.comBurp Suite можно использовать без интерфейса — через REST API
В CI это удобно: вы можете автоматически запускать активный скан после деплоя и сохранять отчёт
Для продвинутых сценариев можно использовать Burp BChecks — настраиваемые тесты на JavaScript
staging/prod окруженийVault, AWS Secrets Manager)Безопасный CI/CD должен быть изолирован
DAST-сервер не должен сканировать продакшн, а только staging
Секреты для API или токенов хранятся в Vault, а все результаты логируются для аудита
Terraform / Ansible lintingtfsec, checkov, kicsOPA)ISO 27001Современные DevSecOps-практики включают инфраструктуру как код
Если вы описываете всё в Terraform — можно автоматически проверять шаблоны на небезопасные конфигурации: открытые порты, доступы S3, слабые шифры
Инструменты вроде tfsec и checkov помогают это автоматизировать
После внедрения автоматизации можно построить постоянный мониторинг
Например, каждую ночь запускать Nuclei и ZAP на staging, а отчёты отправлять в Slack
Так вы получаете continuous pentest — без участия человека!
Ни один автоматизированный сканер не заменит ручного пентестера, но автоматизация освобождает время — вы фокусируетесь на сложных цепочках атак, а машины проверяют рутину. Именно так достигается баланс между скоростью и глубиной
Диаграмма (слайд)
[Commit] → [SAST + SCA] → [Build] → [Deploy to staging] → [DAST/Nuclei scan] → [Manual Pentest] → [Report → Fix → Redeploy]
Вот как выглядит идеальный pipeline безопасности
На каждом этапе добавлен свой уровень защиты: статический, динамический и ручной
Результаты фиксируются в CI и отправляются в баг-трекер
Так формируется цикл “Find → Fix → Verify → Improve”
Автоматизация безопасности не должна быть громоздкой
Начните с малого — интегрируйте один инструмент, потом добавляйте другие
Главное — сделать безопасность частью процесса, а не препятствием для релиза