Apple ввела лимит на обращения в свою программу bug bounty и добавила 30-дневную паузу для тех, кто упирается в потолок заявок. Причина не в внезапной скупости, а в банальной перегрузке: поток AI-репортов стал настолько плотным, что ревью-команды начали тратить время не на действительно опасные находки, а на их массовые, часто однотипные вариации. Для русскоязычных команд это сигнал без лишней драмы: если генеративные инструменты ускоряют поиск багов, то triage, фильтрация и приоритезация теперь становятся отдельной инженерной задачей.
Как пишет Engadget, Financial Times подтвердила, что Apple ограничила число отправок через портал безопасности, а после достижения лимита включается 30-дневный период ожидания. Если исследователь считает, что у него есть основания отправить больше отчетов, пройти дальше можно только по отдельному запросу. Из самой конструкции видно, что компания не закрывает программу и не отсекает сильных участников наглухо. Она скорее убирает эффект конвейера, когда один отправитель может за короткое время засыпать систему десятками находок подряд и занять собой заметную долю внимания команды, которая должна разбирать все это вручную.
Повод очень в духе 2026 года. AI-инструменты научились быстро вылавливать небольшие программные огрехи, повторяющиеся паттерны и просто подозрительные места в коде. Но находить и оформлять их теперь можно быстрее, чем проверять, воспроизводить и ранжировать по реальному риску. Из-за этого очередь на разбор раздувается, а среди валидных, но мелких багов легко теряются более сложные отчеты от людей, которые принесли не еще одну формальную проблему, а действительно опасную цепочку уязвимостей. Для безопасности это неприятная арифметика: объем входящих растет, а пропускная способность ревью не растет с той же скоростью.
Apple здесь не первая. Ранее в 2026 году Google уже пересмотрела собственную bounty-механику и дала понять, что большие выплаты должны получать не мелкие дефекты, которые генеративный помощник находит пачками, а трудные, дорогие в исследовании проблемы. Это важный разворот для всей отрасли. Несколько лет рынок жил в логике чем больше отчетов, тем лучше: любая находка считалась вкладом, а масштабирование выглядело почти безусловным плюсом. Теперь акцент смещается на обратное. Ценность все меньше измеряется валовым числом заявок и все больше редкостью бага, сложностью воспроизведения, качеством доказательной базы и тем, какой реальный ущерб он может нанести продукту.
Для независимых исследователей это меняет правила игры. Когда программа bug bounty начинает ограничивать входящий поток, выигрывает не тот, кто быстрее автоматизировал поиск мелочи, а тот, кто умеет показать контекст: как воспроизвести баг, почему он важен, чем он отличается от дубликата и где проходит граница между теоретическим дефектом и эксплуатируемой проблемой. Иначе говоря, эпоха скриншотов с AI-подсказками и десятка почти одинаковых репортов становится менее выгодной. Для сильных специалистов это, скорее, хорошая новость: шум снижается, а цена качественной ручной работы, аккуратного описания и глубокого анализа заметно растет.
Для продуктовых команд и AppSec-руководителей история Apple полезна как готовый кейс, даже если собственной публичной программы у них нет. Любая программа bug bounty или просто открытый канал для security-репортов теперь рискует упереться не в отсутствие находок, а в операционную математику triage. Если машинный поиск удешевляет генерацию сигналов, компании нужны лимиты на частоту отправки, дедупликация, минимальные требования к качеству описания и внятная модель приоритета. Иначе безопасность превращается в странный офисный квест: инженеры все время заняты разбором входящих, но реальный риск для продукта снижается не так быстро, как растет очередь тикетов.
Главный вопрос теперь не в том, сможет ли AI находить больше багов, а в том, кто научится лучше отделять полезный сигнал от автоматизированного мусора. Похоже, следующая эволюция программ вознаграждения пойдет не только в сторону поиска уязвимостей, но и в сторону репутационных баллов, более жесткой модерации и повышенных требований к доказательству ущерба. Если этот сценарий сработает, программа bug bounty останется рабочим инструментом, но станет заметно менее гостеприимной для массовых полуавтоматических отправок и заметно более требовательной к качеству исследовательской работы.