Как войти и развиваться в AppSec

Что такое AppSec и почему на одного кандидата три вакансии

AppSec (Application Security), то есть безопасность приложений, сейчас дефицитная роль в ИБ.

Рынок сезонный: летом вакансий меньше, к осени больше, а зимой компании активно переманивают людей друг у друга. Джунам сложнее, часть простых задач теперь закрывает AI.

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

Опыт разработки скорее плюс: в AppSec приходят либо безопасники, которые разобрались в разработке, либо разработчики, которые заинтересовались безопасностью.

Безопасная разработка на карте кибербезопасности

Кибербезопасность состоит из направлений со своей экспертизой.

Пентестеры из Red Team работают внутри крупных компаний или в консалтинге, а аналитики SOC в Blue Team не только разбирают инциденты, но и настраивают правила. AppSec пересекается с Red Team и требует понимать работу разработчиков, а инфраструктурная безопасность занимается ещё и внедрением средств защиты информации.

Внутри AppSec тоже несколько треков. В инженерию и обвязку разработки ведёт DevSecOps, в глубину продукта ведёт продуктовая безопасность, в атаку ведёт offensive-направление, в управление ведёт GRC.

Кто такой AppSec-инженер и чем он отличается от DevSecOps и AppSec BP

Раньше отдел ИБ жил отдельно от разработчиков, и договориться о процессах и инструментах было трудно. Специалисты по безопасной разработке постепенно встроились в процессы, так AppSec и сложился как дисциплина с общим языком.

AppSec-инженер работает с инструментами и техническими задачами: триажит уязвимости, заводит баги, работает с bug bounty, дописывает правила для WAF, Semgrep, SAST и DAST. Он редко привязан к одному проекту: сегодня платёжный шлюз, завтра лендинг, послезавтра внутренний сервис.

AppSec BP, бизнес-партнёр, закреплён за бизнес-линией: коммерческими, операционными или клиентскими продуктами. Он говорит с бизнесом на языке рисков и может объяснить заказчику, что фичу не стоит выкатывать, потому что потенциальный ущерб перекроет всю пользу от неё.

DevSecOps отвечает за безопасность в обвязке разработки. В одних компаниях это человек, который пишет YAML-скрипты и встраивает инструменты в пайплайны. В других от него ждут экспертизы в безопасности Kubernetes, Docker и Vault глубже, чем у самого AppSec.

DevSecOps: как встроить SAST, DAST и SCA в CI/CD

DevSecOps сейчас самый востребованный трек безопасной разработки, и его часто пишут в резюме люди, которые им не являются. Так же когда-то админы начали называть себя DevOps, пару раз запустив Docker.

SAST проверяет код без запуска, DAST атакует работающее приложение запросами, а SCA показывает, из каких сторонних компонентов собрано приложение и есть ли в их версиях известные уязвимости. Security gate блокирует сборку, если на этапе тестирования нашлась критическая уязвимость, и код не уходит в прод.

Из CI/CD кроме GitLab и Jenkins реже встречается TeamCity, из SAST ещё PT Application Inspector и open source Semgrep, из DAST ZAP.

Нужен ли отдельный DevSecOps, если безопасную разработку строят с нуля? Оцени объём задач. Если DevOps и AppSec справляются, отдельный человек не нужен. Но если в стеке Kubernetes или HashiCorp Vault, скорее всего ни DevOps, ни AppSec не умеют готовить их безопасно.

Фаззинг: что это и кто его внедряет

При фаззинге (fuzzing) приложению подают данные, которых оно не ждёт: странные Unicode-символы, текст на хинди вместо кириллицы, огромные строки. Пример: в одной из оболочек Android в поле пароля на экране блокировки можно было копировать и вставлять текст, пока строка не дорастала примерно до 4000 символов. После этого подсистема аутентификации падала, и телефон разблокировался. Сам фаззинг ближе к AppSec, потому что ломает логику приложения, а инфраструктура для запуска фаззера ближе к DevSecOps.

Вакансии AppSec: что требуют работодатели

В вакансиях AppSec на hh.ru набор задач почти везде похож:

• оценка архитектуры на ранних этапах: кроме use cases разбирают abuse cases, то есть как злоумышленник может сломать логику;
• оценка рисков с точки зрения бизнеса: сколько стоит исправление и сколько денег может забрать уязвимость;
• реагирование на инциденты: AppSec знает продукт и помогает быстрее найти решение;
• отчёты bug bounty, пентесты в своей зоне, правила WAF и виртуальный патчинг.

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

Код нужно уметь читать на популярных языках. Писать на всех не обязательно, но если анализатор подсветил кусок кода, ты должен понять, уязвим ли он. Дальше идут архитектура веб- и мобильных приложений, OAuth 2.0, OpenID Connect, JWT, CSP, защита API, PKI. OAuth спрашивают практически во всех крупных компаниях. Из инструментов встречаются secret scanning, который ищет в коде пароли, токены и ключи, и ASOC-платформы. Главная open source платформа DefectDojo плохо держит нагрузку, зато легко разворачивается и склеивает дубли одной уязвимости из разных сканеров. CWE Top 25 в вакансиях пишут, но на собеседованиях его почти не спрашивают.

Ищут не безопасника, а инженера безопасности, встроенного в разработку. Он видит Secure SDLC как систему из людей, процессов и инструментов и держит баланс между безопасностью и скоростью.

Хороший AppSec всегда смотрит на time to market. Кроме критических случаев, он не будет сильно вставлять палки в колёса разработчикам, чтобы их фичи катились слишком долго.

Иван Афанасьев

Навыки по уровням: от OWASP Top 10 и STRIDE до языка рисков

Чем больше базы знаешь, тем лучше продаёшь себя на рынке.

В базе важно понимать разницу между уязвимостью, угрозой и риском, знать модель STRIDE (подмена личности, подмена данных, отказ от авторства, раскрытие информации, отказ в обслуживании, повышение привилегий) и разницу между монолитом, SOA и микросервисами: на ней сыплются многие. С контейнерами частый сценарий, когда чувствительные данные остались в слое Docker-образа, а образ выложили в публичное хранилище.

На продвинутом уровне проектируют так, чтобы безопасность не стала бутылочным горлышком, а навыки пентеста нужны, чтобы повторять находки из bug bounty. Soft skills здесь база: AppSec общается со всеми участниками разработки и должен не срываться и доносить ценность безопасности.

Карьера в AppSec: переход из пентеста и куда расти

Веб-пентест (тестирование на проникновение веб-приложений) и AppSec уровня middle+ сильно пересекаются по задачам, но специфика разная. Пентестер живёт проектами и часто работает методом чёрного ящика, ничего не зная о системе. У AppSec намного больше контекста: исходный код, понимание инфраструктуры.

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

Куда расти из AppSec-инженера:

• архитектор безопасности, если хочется процессов, а не триажа и правил;
• продуктовая безопасность, часто это лид AppSec и DevSecOps;
• offensive с уклоном в AppSec, когда в отчёте можно указать, какой код поправить, а оттуда в Red Team;
• исследователь безопасности: research в России жив у вендоров, например в Positive Technologies и BI.ZONE.

Как стать AppSec-инженером: собеседование и обучение

На собеседовании в AppSec смотрят, сталкивался ли человек с практическими кейсами, и это всегда видно. Техническая база обязательна: если знаешь про XSS, но не знаешь, на чём основан DOM-based XSS, в компанию с вебом скорее всего не возьмут. Зазубренное без понимания тоже заметно. Бывает и наоборот: опытные люди недооценивают и занижают свой опыт, так что рассказывать о себе тоже нужно уметь.

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

Иван Афанасьев

Если что-то делал только в учебном режиме, лучше сразу так и сказать. От джуна это слышать не страшно.

Материалов много, при дисциплине можно учиться самому, в том числе с помощью LLM. Не стесняйся задавать глупые вопросы. Где тренироваться:

• уязвимые учебные приложения вроде OWASP Juice Shop;
• свой GitLab: если с верификацией на gitlab.com проблемы, его можно поднять у себя и собрать учебный пайплайн.

Целься в T-shaped профиль: в ширину понимать процессы разработки, инфраструктуры и безопасности, в глубину знать AppSec.

AI в безопасности приложений: триаж, SCA и LLM-агенты

Разработчиков становится меньше, а операторов больших языковых моделей (LLM) больше. Для безопасности приложений появляются новые риски: галлюцинации моделей, промпт-инъекции, злоупотребление AI-агентами. Например, агент тянет код с GitHub, а внутри лежат вредоносные инструкции.

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

Иван Афанасьев

Рабочий подход: использовать сильную сторону LLM, умение собирать контекст.

Модель может связать уже найденные уязвимости и выдать их в сжатом виде. Пример со SCA. У компонента есть CVE с оценкой CVSS 8 из 10, скажем за DOM-based XSS. Но в контексте компании проэксплуатировать её невозможно, скорее молния ударит в дата-центр. LLM может собрать этот контекст, проверить достижимость уязвимого кода и привязать находку к твоей ситуации. Результат зависит от того, как подготовлены скиллы для модели.

Ещё одно направление для исследований: сравнение LLM-агентов с классическим DAST-фаззингом по итерациям и расходу токенов. Условно, фаззеру может понадобиться 100 000 итераций, а агенту несколько сотен или тысяч. Для магистерской сначала стоит определиться, что исследуешь: защиту самой модели или защиту с помощью модели.