Smart App Control в Windows 11 теперь можно выключать без переустановки ОС

Smart App Control в Windows 11 теперь можно выключать без переустановки ОС

Smart App Control в Windows 11 теперь можно выключать без переустановки ОС

Microsoft наконец-то сделала шаг навстречу пользователям Windows 11 и ослабила один из самых жёстких защитных механизмов системы. Начиная со сборки Windows 11 Insider Preview Build 26220.7070, Smart App Control теперь можно включать и выключать в любой момент — без обязательной «чистой» переустановки системы. Обновление уже начали получать участники Dev- и Beta-каналов.

Переключатель появился по привычному пути: «Безопасность Windows» → «Управление приложениями и браузером» → Smart App Control.

При включении функция по-прежнему блокирует недоверенные и потенциально опасные приложения, но теперь решение не становится фатальным.

Раньше Smart App Control работал по принципу «один шанс на всю жизнь системы». Если пользователь отключал его хотя бы один раз, Windows навсегда блокировала возможность включить защиту обратно. Единственным выходом оставалась полная переустановка или сброс Windows 11. В итоге пользователям приходилось выбирать: либо терпеть сломанные легитимные приложения, либо отказаться от Smart App Control навсегда.

 

Smart App Control задумывался как «привратник» Windows 11. В отличие от классического антивируса, он не проверяет программы постфактум, а пытается остановить их ещё до запуска. Для этого используются сервисы app intelligence Microsoft и механизмы проверки целостности кода. Всё неизвестное, неподписанное или подозрительное просто не запускается. В теории — отличная защита от зловредов, PUA и атак 0-day.

На практике же функция регулярно мешала нормальной работе. И, похоже, в Microsoft это всё-таки признали. Новый апдейт не меняет логику блокировок, но избавляет пользователей от пожизненного «наказания» за одно неверное решение.

До настоящего момента у Smart App Control был крайне жёсткий жизненный цикл. Он работал только после чистой установки Windows 11 или полного сброса системы. При обновлении с более старых версий Windows функция по умолчанию оставалась отключённой.

После установки Smart App Control переходил в режим оценки. Примерно неделю он молча наблюдал за тем, как пользователь работает с устройством: какие приложения запускает, какие бинарники использует, насколько его поведение укладывается в модель «безопасного пользователя». На этом этапе ничего не блокировалось.

Если Windows решала, что пользователь подходит под строгий контроль, Smart App Control автоматически включался в режим принудительного исполнения. С этого момента начинались реальные ограничения: неизвестные или неподписанные приложения просто не запускались. Кнопки «Запустить всё равно», исключений или белых списков не существовало.

Самое неприятное — если пользователь вручную отключал Smart App Control хотя бы один раз, система навсегда считала это решение окончательным. Windows даже не предупреждала, что откат невозможен. Особенно сильно от этого страдали разработчики, геймеры, стримеры и продвинутые пользователи, которые часто используют нестандартный или часто обновляемый софт. На Reddit регулярно появлялись жалобы на блокировку вполне легитимных программ.

 

В сборке 26220.7070 Microsoft убрала это ограничение. Теперь Smart App Control можно свободно включать и отключать без переустановки системы. Изменение распространяется постепенно и пока доступно только в Dev- и Beta-каналах.

Рынку DevSecOps не хватает специалистов, а зарплаты идут вверх

На российском рынке безопасной разработки становится всё заметнее перекос между спросом и предложением. По данным совместного анализа HH.ru и ГК «Солар», специалистов в этой области сейчас требуется примерно в три раза больше, чем реально есть на рынке.

Аналитики отмечают, что в 2025 году вакансии по безопасной разработке составили 4,8% от общего числа предложений в сфере ИБ, тогда как резюме таких специалистов — только 1,5%. Иными словами, бизнесу нужны DevSecOps- и AppSec-специалисты, но найти их всё сложнее.

Проблема, как считают эксперты, не только в кадровом голоде как таковом. Речь уже идёт о более глубоком дисбалансе: рынок хочет специалистов нового типа, а система подготовки кадров не успевает за этим запросом. В результате компаниям всё чаще приходится «выращивать» таких сотрудников внутри — переучивать разработчиков, тестировщиков и других технических специалистов под задачи безопасной разработки.

На этом фоне ожидаемо ускоряется и рост зарплат. По итогам 2025 года начинающим специалистам по безопасной разработке с опытом от года до трёх лет предлагали от 107 тыс. до 140 тыс. рублей. Специалисты среднего уровня могли рассчитывать уже на 193–260 тыс. рублей, а опытные профессионалы — на 330–420 тыс. рублей.

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

Расходы бизнеса на такие команды тоже быстро растут. По оценке HR-специалистов «Солара», годовой фонд оплаты труда команды безопасной разработки даже в относительно компактной конфигурации начинается примерно от 9,3 млн рублей. А более сильные и опытные составы уже требуют 25–26 млн рублей в год и выше.

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

По оценке «Солара», использование специализированных LLM-моделей в закрытом контуре может сократить годовой ФОТ AppSec-команд на 20–50% — в зависимости от масштаба разработки. Но это не отменяет главного: окончательное решение всё равно должно оставаться за инженером, а не за моделью.

В целом рынок движется к довольно понятной точке. DevSecOps и AppSec перестают быть чем-то факультативным или «для крупных компаний». Безопасность всё чаще встраивают прямо в процесс разработки, потому что исправлять уязвимости на ранних этапах заметно дешевле, чем разбираться с последствиями уже после запуска.

По приведённым оценкам, стоимость устранения уязвимости может вырасти в 10 раз на поздних этапах разработки, в 640 раз — на этапе запуска приложения и в 1000 раз, если проблема уже привела к ИБ-инциденту в работающем продукте.

На этом фоне растёт и спрос на специалистов, которые умеют работать не только с классическими ИБ-задачами, но и с инструментами автоматизации анализа кода — SAST и DAST, а также понимают саму разработку. Всё более ценными становятся инженеры с опытом в Python, Go, Java, а не только с администраторским или инфраструктурным бэкграундом.

RSS: Новости на портале Anti-Malware.ru