Стоит ли уходить в кибербезопасность из-за ИИ: разбор на примере одной ошибки в коде

Код проходит тесты. Демо работает. А потом один клиент открывает счёт другого.

Разрыв между «работает» и «заслуживает доверия» — на нём и держится спрос на людей, которые умеют проверять системы. Отсюда мысли про смену профессии: может, уйти в кибербезопасность, пока ИИ не забрал всё остальное? Вопрос только в том, спасательная это шлюпка или просто заметная проблема, которую удобно принять за гарантированную работу.

Сначала посмотрите на этот эндпоинт

Пример вымышленный и намеренно упрощённый. Считаем, что middleware уже положил проверенного пользователя в req.user.

app.get('/api/invoices/:id', requireLogin, async (req, res) => {
  const invoice = await db.invoice.findUnique({
    where: { id: req.params.id }
  });

  if (!invoice) return res.sendStatus(404);
  return res.json(invoice);
});

Разработчик может показать всё, что нужно для приёмки: анонимные запросы отклоняются, существующий счёт возвращается, несуществующий отдаёт 404.

Вы бы это одобрили?

Незаданный вопрос звучит так: этот счёт принадлежит тому, кто вошёл в систему? Проверка логина подтверждает личность. Права читать любой объект по id она не даёт. Классическая ошибка уровня объекта — IDOR, broken object level authorization, кому как удобнее.

Как выглядит правило, которое закрывает дыру

Для приложения, где счёт принадлежит конкретному аккаунту, запрос может проверять оба условия сразу:

const invoice = await db.invoice.findFirst({
  where: {
    id: req.params.id,
    ownerId: req.user.id
  }
});

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

Что именно проверяет тест, а что нет

Спрашивать нужно дважды: открывает ли Алиса свой счёт — и откроет ли она счёт Боба. Плюс отдельная строка проверки: какие поля сервис вообще отдаёт в ответе.

Ассистент такую ошибку находит. Он же предложит исправление и тесты. Пример не доказывает, что человек сильнее ИИ, — он показывает, какой вопрос кто-то обязан встроить в процесс разработки, чтобы зелёные тесты что-то значили.

Спрос растёт, вход всё равно узкий

Причина смотреть в эту сторону есть, и она измеримая. Бюро трудовой статистики США прогнозирует рост занятости для аналитиков информационной безопасности на 29% с 2024 по 2034 год (Occupational Outlook Handbook).

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

Есть и вторая половина картины, куда менее приятная. Исследование рабочей силы ISC2 за 2025 год описывает ограничения бюджетов, заморозку найма и сокращения — одновременно с нехваткой навыков. Там же говорится, что ИИ меняет набор компетенций, которые нужны практикам.

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

Работа внутри шлюпки тоже меняется

Команды безопасности пользуются софтом, и часть их рутины ИИ уже подбирает: суммировать логи, объяснять незнакомый код, готовить черновики тестов и отчётов на вычитку человеку. Переход в безопасность не отменяет необходимости адаптироваться к автоматизации.

Куда полезнее, на мой взгляд, учиться проверять утверждения о системах:

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

Эти вопросы работают независимо от того, кто писал код — человек, ассистент или оба по очереди.

Попробуйте работу до того, как поверите в карьерную историю

Если вы разработчик и думаете про AppSec, начните с одной небольшой проверки, а не с годового плана переобучения.

1. Возьмите стенд с намеренно уязвимым кодом и понятными границами дозволенного.
2. Воспроизведите один сбой авторизации с двумя вымышленными аккаунтами.
3. Опишите ожидаемое поведение и наблюдаемое.
4. Внесите исправление.
5. Проверьте и запрещённый доступ, и легитимный.
6. Попросите другого человека воспроизвести проблему по вашему отчёту.

Заодно заметьте, какие части процесса вам нравятся. В работе много аккуратной документации, тупиковых версий и проверки собственных допущений. Момент находки — только начало: дальше нужно объяснить, что произошло, и доказать, что починка держится.

Такой опыт не скажет, готовы ли вы к найму. Но он даёт более полезную точку отсчёта, чем обещание «профессии, которую ИИ не заменит». Из бесплатных площадок с понятной структурой давно известна Web Security Academy от PortSwigger.

Где я стою

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

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

Шлюпка — не профессия и не диплом. Это набор вопросов, которые кто-то должен задавать снова и снова: а чей это счёт, а какие поля вернулись, а что мы на самом деле проверили. Спрос на людей, готовых доводить такой вопрос до доказательства, выглядит устойчивее, чем спрос на слово «AI-proof» в описании курса.