В момента има много шум около изкуствения интелект и киберсигурността. Това, което е наистина важно, е много по-просто, макар и често да се губи в цялата глъч. Откриването на уязвимости става все по-бързо и в значително по-голям мащаб, докато защитниците все още трябва да преценяват кои констатации наистина изискват техни действия.

През първата половина на 2026 г. бяха публикувани внушителните 35 853 CVE, което е с около 49% повече спрямо предходната година. Въпреки това само 495 са каталогизирани като експлоатирани в реални условия през същия период, а 116 вече са били обект на атака в деня, в който са станали публично известни. Междувременно данните на Anthropic показват, че моделите от клас Mythos са разкрили 26 153 потенциални уязвимости в софтуер с отворен код, като само за 421 от тях са инсталирани корекции за сигурност в оригиналния проект.

Този малък експлоатиран поднабор е изключително важен момент. Той показва на защитниците, че третирането на всяка уязвимост с висока (High) или критична (Critical) CVSS оценка като извънредна ситуация е не само невъзможно, но всъщност е погрешен модел. Критичната задача пред екипите по сигурност е да решат кои експозиции, за кои активи, изискват незабавни действия, особено след като броят на констатациите нараства, а времевият прозорец между разкриването и експлоатацията намалява.

Само CVSS оценката не може да ви каже какво е важно във вашата среда

Една и съща CVE уязвимост може да засегне стотици активи, но въздействието редко е еднакво при всички тях. Някои инстанции са недостъпни. Други се намират зад контроли за сигурност, които прекъсват техниките, необходими за експлоатация. Трети са експонирани в критични за бизнеса системи, където превенцията се проваля, а откриването никога не се задейства.

CVSS ви дава обща базова оценка на сериозността. Тя не може да ви даде контекста, който определя въздействието върху вашата организация.

Ето защо защитниците се нуждаят от доказателства от собствената си среда, за да разберат дали експозицията наистина може да бъде експлоатирана, кои активи засяга и дали тези активи са достъпни и важни за бизнеса. С нарастването на обема от уязвимости тази разлика става все по-важна.

Само автоматизираното пентестване не може да валидира всяка експозиция

След като преминете отвъд оценките за сериозност, автоматизираното пентестване предоставя едни от най-силните доказателства, които можете да съберете. То може да изпълнява реални експлойти, да докаже, че дадена експозиция е възможно да бъде експлоатирана във вашата среда, да свърже уязвимости, идентификационни данни и неправилни конфигурации в пътища на атака и да покаже докъде всъщност би могъл да стигне даден атакуващ във вашата мрежа.

Въпреки това покритието на практика остава ограничено. Изследване на Omdia установи, че макар 95% от организациите да определят пентестването като топ или висок приоритет, едва 32% от тяхната средна повърхност за атака се тества всяка година. Подходите, базирани на AI агенти и автоматизация, могат да разширят това покритие, но те не премахват всяко ограничение при експлоатацията в реална среда.

При експлоатация, базирана на CVE, все пак трябва да съществува работещ експлойт, а целта трябва да бъде безопасна за тестване. За наскоро разкрити CVE може все още да няма работещ експлойт, докато при критични за бизнеса, ограничени и изолирани (air-gapped) активи тестването с реални експлойти просто може да е невъзможно. Тези експозиции все пак се нуждаят от заключение относно възможността за експлоатация, дори когато автоматизираният пентест няма какво да изпълни безопасно.

Това е празнината, която автоматизираното пентестване не може да затвори самостоятелно. То е задължителна част от валидирането, но не може да валидира всяка експозиция.

Всички за една. Една за всички експозиции.

Тук отделните елементи се свързват.

  • Валидирането на възможността за експлоатация (Exploitability validation) определя дали дадена експозиция всъщност може да бъде експлоатирана във вашата среда, включително CVE без работещ експлойт и активи, до които експлоатацията в реално време не може да достигне безопасно.
  • Валидирането на контролите за сигурност (Security control validation) тества дали вашите контроли за превенция и откриване наистина блокират, откриват или пропускат атаката.
  • Пентестването с AI агенти (Agentic pentesting) безопасно изпълнява реални експлойти и свързва експозиции, за да покаже докъде може да стигне атакуващ във вашата специфична среда.

Тези методи отговарят на различни въпроси при различни условия на експозиция. Готовността за Mythos изисква и трите способности, обединени в една платформа с една и съща цел: валидиране на експозициите във вашата уникална среда. Това не означава, че винаги трябва да използвате и трите метода срещу всяка експозиция. Целта е да прилагате всеки метод там, където той пасва най-добре, и да позволите доказателствата да допринасят за един и същ процес на вземане на решения.

Тези три ключови елемента стават още по-мощни, когато работят като една обща програма. Дадена констатация може да задейства стъпката за валидиране, от която наистина се нуждае, новите доказателства могат да променят приоритета за отстраняване на уязвимостите, а корекциите могат да бъдат валидирани отново, вместо да изчезват в затворен тикет. Това поддържа връзката между възможността за експлоатация, ефективността на контролите и доказателствата за пътя на атаката, вместо да ги оставя да потъват в отделни работни процеси.

Натам сочи и изследователският доклад на Gartner® от май: към валидирани пътища на атака, реакция, базирана на информирани решения, и намаляване на експозицията – всичко интегрирано в оперативните работни процеси.

Това е и работният модел зад нашия Validation Summit ’26.

Какво виждат експертите по сигурност и как водещите предприятия прилагат валидирането на практика

На 14 и 15 октомври Picus Security ще организира The Validation Summit ’26, за да събере независима гледна точка за настъпилите промени, нашия подход към валидирането и уроците от лидери в сигурността, които вече са го приложили на практика.

Mikko Hyppönen ще открие събитието с беседа защо тази промяна се различава от предишните. Техническият директор (CTO) на Picus, Volkan Ertürk, след това ще разясни как трябва да изглежда валидирането на сигурността, когато атакуващите задвижват атаките си с AI, и защо валидирането на възможността за експлоатация, валидирането на контролите за сигурност и пентестването с AI агенти работят по-добре заедно, отколкото самостоятелно. След това екипът на Picus ще демонстрира работния процес по валидиране на живо с наскоро разкрита уязвимост. Процесът започва при липса на корекция за сигурност и работещ експлойт, преминава през валидиране преди да съществува PoC, тества експлойта спрямо работещите контроли веднага щом се появи такъв, и след това валидира отново след прилагане на отстраняването.

След това лидери по сигурността от Chanel, Atlassian и NFL ще разгледат как изглежда това в реални корпоративни среди: как зрелите екипи по сигурност адаптират своите програми за валидиране, какво са променили и постигнатите успехи и провали по пътя.

Два часа. Един план за валидиране. Присъединете се към нас за Picus Validation Summit ’26.

Забележка: Тази статия е написана от Sila Ozeren Hacioglu, инженер по изследвания на сигурността в Picus Security.