Индустрията прекара първите месеци след разкриването на Mythos от Anthropic на 7 април, фокусирайки се върху обема. Колко нови CVE уязвимости би добавил Mythos към и без това претоварения процес? Колко бързо потокът от открития, задвижвани от изкуствен интелект (ИИ), ще затрупа възможностите за триаж? Колко време ще отнеме на атакуващите да превърнат в оръжие разкритията на Mythos в широк мащаб? Тези въпроси бяха и остават валидни. Въпреки това всички те спират дотук, без да разгледат единствената метрика, която определя дали някоя от тези уязвимости действително води до пробив: прозорецът на излагане на риск.

Прозорецът на излагане на риск — разликата между момента, в който една уязвимост стане експлоатируема, и момента, в който вашият екип я отстрани — е времето, с което разполага един киберпрестъпник, за да нанесе реални щети. По настоящем този прозорец е оставен твърде широко отворен. През 2025 г. средното време за проникване при киберпрестъпления (breakout time) спадна до 29 минути. Дори PCI DSS — най-строгата рамка за съответствие в индустрията — позволява 30 дни за отстраняване на критична уязвимост. Това е разлика от 1000 към 1 между скоростта, с която се движат атакуващите, и скоростта, с която се очаква да реагират организациите. А каква е причината този прозорец да остава отворен? Мобилизацията — собствеността, отстраняването на уязвимости и организационната сложност, която забавя времето за реакция и повишава риска.

В тази статия ще разгледам защо прозорецът на излагане на риск сега е най-важната метрика, какво го държи отворен и как откритията, задвижвани от ИИ, принуждават проактивните екипи за сигурност да възприемат метриките, базирани на скорост, които екипите на SOC (Security Operations Center) използват от години.

Mythos не създаде прозореца на излагане на риск. Той просто го разшири.

Моделът за управление на уязвимостите вече показваше пукнатини, преди Mythos да се появи на сцената. 48 185 CVE бяха разкрити през 2025 г. — ръст от 22% спрямо 2024 г. Повечето екипи за сигурност вече се удавяха в натрупаните си задачи за коригиране на уязвимости. А настоящите прогнози са, че 66 000 нови CVE ще бъдат вписани през 2026 г. Често всяко едно от тези CVE попада в един и същ процес за отстраняване — обект на ръчни одобрения, фрагментирана собственост и прозорци за промяна, които се движат с темпото на корпоративните ИТ отдели, а не с темпото на атакуващите.

Рамката CTEM на Gartner дефинира пет етапа: определяне на обхвата, откриване, приоритизиране, валидиране и мобилизация. Първите три етапа вече се изпълняват с машинна скорост. Валидирането — потвърждаването, че вашите контроли действително спират реални заплахи — се подобри благодарение на автоматизираното тестване на пътищата за атака от платформите. Въпреки това мобилизацията все още се движи с организационна скорост.

Последните промени в политиките признават това несъответствие. По-конкретно, BOD 26-04 на CISA измества федералните агенции от подход, приоритизиращ първо CVSS резултата, към инсталиране на корекции за сигурност на базата на експлоатируемост и контекст на активите (което е точно това, което CTEM изисква от самото начало). Но тази директива все още адресира само кои уязвимости да се коригират първо. Тя не решава въпроса колко бързо организациите могат да се мобилизират, за да изпълнят корекцията. Което означава, че тя все още оставя прозореца на излагане на риск широко отворен.

Защо мобилизацията е мястото, където програмите се провалят

Разликата между това да знаеш коя уязвимост да коригираш и действителното ѝ коригиране е проблем на мобилизацията. Екипът по сигурността идентифицира излагането на риск, а различен екип — такъв със собствени приоритети, собствени прозорци за промяна и собствени вериги за одобрение — трябва да я отстрани. Това прехвърляне на задачи е слабото място на повечето CTEM програми. Корпоративните процеси за отстраняване на проблеми са изградени за поток, който се движи с човешка скорост, но всеки етап преди мобилизацията вече не е такъв.

Според скорошни проучвания, отстраняването на високорискови и критични уязвимости в приложения отнема средно 55 дни, а близо половината от корпоративните уязвимости остават некоригирани след цяла година. Повечето организации все още не приоритизират отстраняването на уязвимости въз основа на експлоатируемост и бизнес въздействие във всеки случай. А остарелите системи, OT средите и производствената инфраструктура могат да имат сериозно бизнес отражение, ако излязат офлайн — така че корекциите обикновено изчакват. Освен това, при рискове, свързани с идентичността, като прекомерни привилегии и кеширани идентификационни данни, дори няма корекция за сигурност, която да се приложи. Много констатации просто попадат в опашката, без да има конкретен екип, отговорен за разрешаването им.

Основното е, че прозорецът на излагане на риск остава отворен, тъй като задвижването на организационната машина между "коригирайте това" и "коригирано" отнема седмици или месеци, докато на атакуващите са нужни само минути. Което повдига въпроса: колко дълго проактивните екипи за сигурност могат да продължат да измерват успеха по различен часовник от този на атакуващите?

Проактивните екипи вече работят по реактивни графици

Организациите за сигурност традиционно се разделят на два оперативни режима. SOC екипите — реактивната страна — проследяват времето на престой на атакуващия в мрежата (dwell time), средното време за реакция и скоростта на ограничаване на заплахата. Тяхната работа е да ограничат щетите от заплахи, които вече са вътре в средата. Екипите за управление на уязвимости (VM), екипите за облачна сигурност и екипите за мрежова сигурност — проактивната страна — проследяват степента на инсталиране на корекции за сигурност по нива на критичност или времето за отстраняване на неправилни конфигурации. Тяхната задача е да намалят излагането на риск преди пристигането на атакуващия.

Въпросът е, че откриването на заплахи, задвижвано от ИИ, на практика поставя и двата екипа пред един и същ хронометър.

Когато уязвимостите преминават от разкриване към превръщане в оръжие за часове, а времето за проникване се измерва в минути, тримесечното темпо за обновяване...