VEX и CSAF: доказателства за уязвимости, годни за одит

Съобщението в 07:40, което превръща SBOM в въпрос за управителния съвет

В 07:40 във вторник сутрин в началото на 2026 г. Аня, директор по информационна сигурност (CISO) на бързо растяща FinTech платформа, вижда критично съобщение от доставчик, получено във формат CSAF. Уязвимост за отдалечено изпълнение на код е открита в широко използвана open-source библиотека. Нейният опис на софтуерните компоненти (SBOM) потвърждава, че библиотеката е вградена във водещото приложение за обработване на плащания, две вътрешни услуги и компонент за анализи, възложен на външен изпълнител.

До 08:10 телефонът ѝ не спира да звъни. Инженерният екип иска да знае дали уязвимата функция е достижима. Екипът по съответствието иска да знае дали това засяга ISO/IEC 27001:2022, NIS2 или DORA. Правният отдел пита дали Cyber Resilience Act може да изисква комуникация с клиенти или с органи. Член на управителния съвет, току-що обучен относно отчетността на ръководството по NIS2, задава въпроса, който всички си задават:

Засегнати ли сме?

Първият отговор на инженерния екип е технически коректен: пакетът съществува, но уязвимата функция може да не се извиква в продукционна среда. През 2026 г. този отговор не е достатъчен.

Управителният съвет иска доказателства. Клиентите искат ясен отговор. Екипът по снабдяване иска да знае дали доставчикът е изпълнил договорните си задължения за оповестяване. Длъжностното лице по защита на данните (DPO) иска да знае дали лични данни могат да бъдат изложени на риск. Одитор по ISO 27001 няма да приеме „разработчикът каза така“ като съхранено доказателство. Одитор по DORA ще очаква уязвимостта да бъде свързана с ИКТ активи, критични функции и зависимости от трети страни.

Тук VEX и CSAF престават да бъдат технически формати и се превръщат в инфраструктура за управление.

CSAF, Common Security Advisory Framework, структурира съобщенията за уязвимости така, че хора и машини да могат да обработват засегнати продукти, версии, указания за ремедиация, препратки и информация за статус. VEX, Vulnerability Exploitability eXchange, предоставя слоя за вземане на решение. Той казва на заинтересованите страни дали известна уязвимост действително е експлоатируема в конкретен продукт, услуга или среда.

Практическите VEX резултати за статус са ясни: affected, not affected, fixed и under investigation. Управлението зад тях не е просто. Всеки статус изисква доказателства, собственик, обосновка, одобрение и тригер за преглед.

Пропускът в съответствието вече не е липсата на SBOM. Много организации вече имат SBOM. Пропускът е в доказването как всяко съобщение за уязвимост е било триажирано, кой е одобрил решението за статуса, какви доказателства са подкрепили заключение „not affected“, как е приоритизирана ремедиацията, когато продуктът е „affected“, и как организацията е запазила тази проследимост за одитори, регулатори, клиенти и ръководство.

Clarysec разглежда VEX и CSAF като част от операционния модел на СУИС. В Zenith Blueprint: 30-стъпкова пътна карта за одитори това попада във фазите за управление на риска, сигурност на доставчиците, технологични контролни мерки и доказателства. В Zenith Controls: ръководство за кръстосано съответствие същата тема свързва контролите по ISO/IEC 27001:2022 със сигурността на ИКТ веригата на доставки, управлението на уязвимостите, обработването на доказателства, NIS2, DORA, GDPR и очакванията на NIST.

Защо SBOM създава сигнали, а VEX създава доказателства

SBOM е списък със съставки. Той показва какво се съдържа в даден продукт или услуга. Когато CVE се появи в една от тези съставки, SBOM показва, че може да сте засегнати.

Този сигнал е ценен, но не е заключение.

Зряла софтуерна среда може да генерира хиляди SBOM съвпадения с уязвимости. Много от тях са реални рискове. Много не са експлоатируеми, защото уязвимият код не се доставя, не се импортира, не е достижим, не е конфигуриран, не е изложен на недоверен вход или е смекчен чрез компенсиращи контроли. Без формален процес за документиране на разследването екипите обикновено попадат в един от два неблагоприятни модела.

Първият е прегаряне при триаж. Инженерите преследват всяко съвпадение с уязвимост с еднаква спешност, дори когато компонентът е зависимост само при компилация, неактивен път в кода или вътрешна функционалност, защитена чрез многостепенна защита.

Вторият е недокументирано приемане на риска. Екипите затварят билети с кратки коментари като „неприложимо“ или „фалшиво положителен резултат“. Това може да изглежда ефективно, но за одитор е неконтролирано решение. За регулатор може да изглежда като неуправлявана уязвимост.

VEX и CSAF решават това, като превръщат шума от уязвимости в структурирани, годни за одит доказателства за уязвимости.

Защитим процес за управление на VEX и CSAF отговаря на пет въпроса:

1. Получихме ли или идентифицирахме ли съобщението?
2. Съпоставихме ли го с продукти, активи, доставчици, клиенти и потоци от лични данни?
3. Определихме ли статуса на уязвимостта по дефинирани критерии?
4. Документирахме ли решението, доказателствата, собственика, одобрението и тригера за преглед?
5. Извършихме ли ремедиация, оповестяване, мониторинг или съхраняване на доказателства въз основа на риска?

Разликата между „not affected“ и „игнорирано“ е в доказателствата.

VEX статус „not affected“ следва да бъде подкрепен с обосновка, например че уязвимият компонент не присъства, уязвимата версия не е внедрена, уязвимият път в кода не се изпълнява, уязвимата конфигурация е деактивирана или компенсиращ контрол предотвратява експлоатацията. „Under investigation“ трябва да има ограничено във времето последващо действие, а не да се превръща в гробище в backlog. „Fixed“ трябва да сочи към корекция, мярка за смекчаване, актуализация на версия, резултат от тест и запис за внедряване. „Affected“ трябва да влезе в третиране на риска, планиране на ремедиацията, уведомяване на доставчик, комуникация с клиенти и, когато е приложимо, работни потоци за оценка на инцидент или нарушение.

Моделът на Clarysec за управление на решенията за VEX статус

Всяко CSAF съобщение и всяка VEX декларация следва да се третират като контролиран запис в рамките на СУИС, а не като изолиран инженерен артефакт. Работният поток може да се намира в GRC платформа, инструмент за управление на уязвимостите, система за билети, работен поток за контрол на изходния код или работна книга на Clarysec за доказателства. Важното е статусът, доказателствата, одобрението и третирането на риска да останат свързани.

Тази таблица изглежда проста, но променя контролната среда. Декларация „not affected“ се превръща в мини решение за риск за конкретен продукт и среда. Статус „fixed“ свързва управлението на уязвимостите с управлението на промените и тестването. Статус „affected“ задейства третиране, ескалация и възможно оповестяване. Статус „under investigation“ дава на ръководството видим, ограничен във времето риск.

Zenith Blueprint затвърждава този подход в Step 13 относно планирането на третиране на риска и Декларацията за приложимост. Той обяснява, че решенията за контроли следва да бъдат обосновани чрез третиране на риска, правни или договорни изисквания, релевантност на обхвата и организационен контекст:

„В листа SoA отбележете всеки контрол като ‘Yes’ (приложим) или ‘No’ (неприложим). Предоставете Justification/Notes.“

За VEX „not affected“ следва същата дисциплина. Това не е неформално затваряне на билет. Това е обосновано решение, което трябва да издържи на преглед.

Step 19 от Zenith Blueprint разглежда техническото управление на уязвимостите:

„Бъдете информирани за нови пропуски в сигурността (чрез предупреждения от доставчици, CVE потоци и др.) за вашия софтуер и хардуер. Оценявайте кои са релевантни (използваме ли този софтуер? колко критичен е пропускът?) и своевременно прилагайте корекции или мерки за смекчаване.“

CSAF подпомага получаването на структурирани съобщения. SBOM подпомага определянето на наличието на компоненти. VEX подпомага документирането на експлоатируемостта и статуса. СУИС управлява решението.

Доказателства по политики преди пристигането на критичното съобщение

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

За МСП Политика за управление на уязвимости и корекции - SME установява задължението за мониторинг:

„Наблюдава системите за уязвимости и налични корекции чрез предупреждения от доставчици, съобщения от разузнаване за заплахи и уведомления от операционната система“

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

Същата политика за МСП задава очаквания за готовност за одит:

„Поддържайте точни записи за приложени корекции, нерешени въпроси и изключения, за да осигурите готовност за одит“

От Цели, клауза 3.4 на политиката, тук VEX се превръща в нещо повече от технически файл. Ако екип не прилага корекция, защото продуктът е „not affected“, това изключение изисква доказателства, одобрение и проследимост.

За корпоративни среди Политика за управление на уязвимости и корекции е изрична:

„Наблюдавайте съобщения за заплахи (напр. CVE, CISA KEV, бюлетини от доставчици) и ескалирайте критични уязвимости.“

От Роли и отговорности, клауза 4.5.1 на политиката, тази клауза подкрепя структуриран канал за приемане на CSAF, CVE, бюлетини от доставчици и разузнаване за експлойти. Тя също изисква ескалация, когато VEX статус е „affected“ или „under investigation“ за критичен продукт.

Корпоративната политика също посочва:

„Всички критични и високорискови уязвимости трябва да бъдат записани в Регистъра на риска на ISMS и наблюдавани до ремедиация или до покриване с одобрено изключение.“

Тази клауза, от Изисквания за управление, клауза 5.3 на политиката, е опорната точка за съответствие. VEX декларация „not affected“ за критичен CVE е защитима само когато се третира като одобрено изключение с доказателства. VEX декларация „fixed“ затваря цикъла само когато ремедиацията е проверена.

Оценяването на риска също изисква контекст. Същата политика се позовава на:

„Оценка на риска (въз основа на CVSS, критичност на актива, разузнаване за заплахи)“

От Третиране на риска и изключения, клауза 7.2.2 на политиката, това подкрепя комбиниран модел за триаж. Само CVSS не е достатъчен. Уязвимост със средна степен на сериозност, която се експлоатира активно в критичен компонент за идентичност, може да е по-спешна от проблем с критичен CVSS в недостижим код.

Политиките за приложения и сигурна разработка разширяват същата дисциплина към инженерните екипи и доставчиците. Политика за изискванията за сигурност на приложенията - SME изисква екипите да проследяват:

„известни уязвимости и статус на ремедиацията.“

От Изисквания за внедряване на политиката, клауза 6.4.2.3 на политиката, това се съпоставя ясно с VEX статусите. Същата политика изисква споразуменията да:

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

От Изисквания за управление, клауза 5.3.2 на политиката, това се превръща в практическа клауза за доставчици: предоставяйте своевременни съобщения, идентифицирайте засегнатите версии, издавайте VEX статус, когато е възможно, дефинирайте срокове за ремедиация и подпомагайте оповестяването към клиенти.

За корпоративна сигурна разработка Политика за сигурна разработка очаква:

„Сканиране за известни уязвимости (CVE, OSS Index и др.)“

От Изисквания за управление, клауза 5.4.3 на политиката, това дава на инженерните екипи дефиниран механизъм за съпоставяне на съобщения към компоненти и задействане на VEX анализ.

Когато уязвимост се превърне в инцидент или потенциален правен въпрос, дисциплината при доказателствата става съществена. Политика за събиране на доказателства и форензика - SME посочва:

„За всеки инцидент трябва да се поддържа прост журнал на веригата на съхранение (напр. Excel файл или шаблонен документ).“

От Изисквания за управление, клауза 5.3.1 на политиката, това е границата между рутинен VEX триаж и обработване на доказателства на ниво инцидент. Ако се подозира експлоатация, журналите, записите за съобщения, бележките от анализа, комуникациите и форензичните артефакти изискват проследимост.

Съпоставяне на VEX и CSAF с ISO 27001, NIS2, DORA, GDPR и CRA

Най-силните VEX програми не са самостоятелни инженерни проекти за сигурност. Те са съпоставени с контролната система, която организацията вече използва.

Съгласно ISO/IEC 27001:2022 СУИС трябва да отчита заинтересованите страни, правните и договорните задължения, интерфейсите и зависимостите с други организации. Тази логика на обхвата е съществена за VEX, защото съобщенията от доставчици, ангажиментите към клиенти, open-source компонентите и външно възложените услуги влияят върху решенията за уязвимости.

Най-релевантните контроли от Annex A включват 5.19 Информационна сигурност във взаимоотношенията с доставчици, 5.20 Адресиране на информационната сигурност в споразуменията с доставчици, 5.21 Управление на информационната сигурност във веригата на доставки на ИКТ, 5.22 Мониторинг, преглед и управление на промените в услугите на доставчиците, 5.28 Събиране на доказателства и 8.8 Управление на технически уязвимости. Контролите за сигурна разработка 8.25 до 8.29 също са релевантни, когато организацията изгражда софтуер или цифрови продукти.

NIS2 увеличава управленския натиск. Article 21 изисква подходящи технически, оперативни и организационни мерки, включително анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурно придобиване, разработка и поддръжка, обработване и оповестяване на уязвимости, ефективност на контролите, киберхигиена, криптография, сигурност в областта на човешките ресурси, контрол на достъпа, управление на активите и автентикация. Article 20 изисква управленските органи да одобряват и надзирават мерките за управление на риска за киберсигурността. Това прави VEX показателите подходящи за докладване към управителния съвет.

DORA се прилага от 17 януари 2025 г. за финансовите субекти в обхват. Той изисква рамка за управление на ИКТ риска, идентификация и класификация на ИКТ активи, уязвимости, зависимости и ИКТ услуги от трети страни, управление на инциденти, тестване на устойчивостта, управление на риска, свързан с трети страни, и надзор от ръководството. За финансовите субекти VEX записите са особено полезни, когато съобщение от доставчик трябва да бъде свързано с критични или важни функции, договорни задължения и класификация на инциденти.

GDPR се включва, когато експлоатацията може да засегне лични данни. Уязвим приложно-програмен интерфейс (API), библиотека или услуга, които могат да изложат клиентски записи, изискват оценка спрямо критерии за поверителност, цялостност, наличност и уведомяване за нарушение. VEX заключение „not affected“ може да подкрепи решение да не се уведомява, но само ако организацията може да покаже защо не е настъпило нарушение на сигурността на личните данни.

Cyber Resilience Act добавя управление на продуктите. С поетапното влизане в сила на задълженията по CRA производителите и другите икономически оператори се нуждаят от повторяеми процеси за обработване на уязвимости, актуализации за сигурност, координирано оповестяване и доказателства. CSAF може да структурира съобщенията. VEX може да уточни кои продукти и версии са affected, fixed или not affected.

Какво добавя ръководството на Clarysec за кръстосано съответствие

Zenith Controls е ценно, защото съпоставя техническата работа с одиторските очаквания и припокриващите се рамки. За VEX и CSAF най-важни са три области: сигурност на ИКТ веригата на доставки, техническо управление на уязвимостите и събиране на доказателства.

За сигурността на ИКТ веригата на доставки Zenith Controls идентифицира контрол 5.21 от ISO/IEC 27002:2022 като „Управление на информационната сигурност във веригата на доставки на ИКТ“. То обяснява, че 5.21 разширява контролите за взаимоотношения с доставчици 5.19 и 5.20 към ИКТ-специфични рискове, включително несигурни софтуерни компоненти и библиотеки от трети страни или open-source библиотеки. Свързва се със сигурно инженерство, сигурно програмиране, тестване на сигурността, контрол на достъпа, събиране на доказателства, жизнен цикъл на сигурна разработка и външна разработка.

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

За техническото управление на уязвимостите Zenith Controls идентифицира контрол 8.8 като „Управление на технически уязвимости“. То класифицира контрола като превантивен, подкрепящ поверителност, цялостност и наличност, и свързан с управление на заплахи и уязвимости. Също отбелязва, че управлението на уязвимостите се свързва със защита от зловреден софтуер, управление на конфигурацията, управление на промените, разузнаване за заплахи и мониторинг.

Особено полезен пасаж от Zenith Controls за управление на VEX е:

„Ефективното управление на уязвимостите приоритизира въз основа на реални заплахи. Разузнаването за заплахи информира кои уязвимости се експлоатират активно и насочва приоритизацията на корекциите.“

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

За доказателствата Zenith Controls идентифицира контрол 5.28, „Събиране на доказателства“, като коригиращ и свързан с откриване и реагиране. То свързва 5.28 с реагиране при инциденти, регистриране, мониторинг и докладване на събития. Също така съпоставя обработването на доказателства с ISO/IEC 27037:2012 за идентификация, събиране, придобиване и съхраняване на цифрови доказателства.

Когато уязвимостта е само теоретична, рутинните VEX записи може да са достатъчни. Когато се подозира експлоатация, организацията трябва да премине към обработване на доказателства за инцидент. Журналите, комуникациите с доставчици, уведомленията към клиенти, записите за корекции и форензичните артефакти изискват цялостност, съхраняване и проследимост.

Практически VEX пакет с доказателства от предупреждение до приключване

Да се върнем към FinTech платформата на Аня. CSAF съобщение пристига за критична уязвимост в lib-common-utils, която се появява в SBOM за платежния шлюз. Дисциплинираната реакция би създала един пакет с доказателства, а не разпръснати Slack съобщения и екранни снимки.

Стъпка 1: Създайте запис за приемане на съобщението

Отворете случай за уязвимост в инструмента за проследяване на доказателства на СУИС. Прикачете CSAF съобщението, CVE препратката, бюлетина от доставчика, SBOM съвпадението и списъка със засегнати активи. Определете собственик на уязвимостта и собственик на бизнес системата. Свържете платежната услуга с въздействие върху клиенти, лични данни, финансова обработка и оперативна критичност.

Основа в политиката: Политика за управление на уязвимости и корекции изисква мониторинг на съобщенията и ескалация на критични уязвимости. Основа по ISO: Annex A контрол 8.8. Основа по NIS2: обработване на уязвимости и сигурна поддръжка. Основа по DORA: идентифициране на ИКТ уязвимости и готовност за инциденти.

Стъпка 2: Задайте предварителен статус under investigation

Първоначалният статус често трябва да бъде „under investigation“, особено за критични съобщения. Задайте краен срок за решение, например 24 часа за външно изложени или критични услуги. Запишете временни контроли, като засилен мониторинг, временни ограничения на функционалности или WAF правила. Това предотвратява изчезването на критично съобщение в неуправляван backlog.

Стъпка 3: Извършете анализ на експлоатируемостта

Инженерният екип трябва да отговори на практически въпроси:

• Присъства ли уязвимата версия в продукционна среда?
• Импортира ли се, извиква ли се или достижима ли е уязвимата функция?
• Активирана ли е уязвимата конфигурация?
• Изложен ли е компонентът на недоверен вход?
• Изисква ли се автентикация, преди уязвимият път да може да бъде достигнат?
• Ефективни ли са компенсиращите контроли?
• Има ли активна експлоатация или достоверно разузнаване за заплахи?
• Може ли експлоатацията да засегне лични данни, финансови транзакции или наличност на услугата?

В случая на Аня статичният анализ потвърждава, че компонентът присъства, но уязвимата функция не се извиква от платежния шлюз. В продукционна среда не съществува път за изпълнение. Екипът подготвя VEX декларация „not affected“ с подкрепящи доказателства.

Ако анализът беше показал, че автентикирана администраторска задача може да достигне уязвимата функция, правилният статус щеше да бъде „affected“, а не „not affected“. След това екипът би създал План за третиране на риска, отворил би билет за промяна, приложил би корекция или мярка за смекчаване и би актуализирал статуса на „fixed“ само след проверка.

Стъпка 4: Свържете случая с Регистъра на риска и записа за доставчика

Критичните и високорисковите случаи следва да бъдат въведени в Регистъра на риска на СУИС, освен ако не са затворени чрез одобрено изключение с доказателства. Съобщенията от доставчици следва също да се свързват с регистъра на доставчиците, договорните задължения и записите от мониторинга.

Това подкрепя Zenith Blueprint Step 23, който инструктира организациите да съставят списък на доставчиците, да ги класифицират според достъп и оперативен контрол, да включат очакванията за сигурност в договорите и да дефинират процедури за мониторинг на промени при доставчици.

Стъпка 5: Валидирайте корекцията или одобрете изключението

За „fixed“ прикачете версията с корекция, записа за промяна, резултата от CI/CD пайплайна, сканирането на зависимости, digest на контейнерен образ, доказателствата за внедряване и регресионния тест. За „not affected“ прикачете анализ на пътя в кода, доказателства за конфигурация, доказателства за версия, доказателства за компенсиращ контрол и одобрение.

Ако клиентите използват self-hosted версии или уязвимостта може да засегне външни потребители, координирайте комуникацията. Политика за координирано оповестяване на уязвимости предоставя модела:

„Когато потвърдена уязвимост може да засегне клиенти или потребители на услуги, екипът „Комуникации“, под ръководството на VRT, трябва да подготви съобщение за сигурност. Съобщението трябва да включва преглед на проблема, без да разкрива подробности за експлойта, засегнатите продукти или версии, указания за смекчаване или инструкции за изтегляне на корекция, както и информация за контакт за поддръжка.“

От Изисквания за внедряване, клауза 6.8 на политиката, това се съпоставя пряко с дисциплината за публикуване на CSAF.

Стъпка 6: Съхранете доказателствата, ако се подозира експлоатация

Ако журналите показват опити за експлоатация, преминете от обработване на уязвимост към реагиране при инциденти и събиране на доказателства. Започнете журнал на веригата на съхранение, съхранете журналите, запишете SIEM заявките, експортирайте релевантните събития, направете снимка на засегнатите системи, ако е необходимо, и документирайте кой е обработвал всеки артефакт. Свържете случая на инцидента с VEX записа.

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

Одиторите не тестват управлението на VEX и CSAF по един и същи начин. Един пакет с доказателства следва да удовлетворява няколко гледни точки.

Zenith Controls включва насоки за одитна методология, които съответстват на тази таблица. За сигурността на ИКТ веригата на доставки одитори, използващи ISO/IEC 19011 и ISO/IEC 27007, ще проверяват политики за снабдяване, RFP шаблони и процеси за управление на доставчици, за да потвърдят ИКТ-специфични изисквания за сигурност. Те ще извадково проверяват договори за клаузи относно сигурна разработка, оповестяване на уязвимости и автентичност на софтуера.

За техническото управление на уязвимостите одиторите преглеждат политиката за управление на уязвимости, честотата на сканиране, покритието на активите, приоритизацията въз основа на риска, сроковете за ремедиация и отговорностите. За събирането на доказателства те тестват дали веригата на съхранение, сигурното съхранение и запазването са били спазени при реални инциденти.

Затова управлението на VEX никога не трябва да приключва със самия етикет на статуса. Етикетът е резюмето. Доказателствената следа е контролът.

Показатели за ръководството, които правят VEX подходящ за управителния съвет

ISO/IEC 27001:2022 изисква оценка на изпълнението, вътрешен одит и преглед от ръководството. NIS2 изисква надзор от ръководството. DORA изисква управление на ИКТ риска. VEX и CSAF създават показатели, които превеждат инженерната работа във видимост на риска за изпълнителното ръководство.

Полезни показатели за преглед от ръководството включват:

• Брой критични CSAF съобщения, получени през това тримесечие
• Процент, съпоставен с компоненти в SBOM
• Брой и възраст на VEX статусите по affected, not affected, fixed и under investigation
• Просрочени случаи „under investigation“
• Съобщения от доставчици без достатъчни данни за засегнати версии
• Критични уязвимости, приети като одобрени изключения
• Време от приемането на съобщението до VEX решение
• Време от решение affected до ремедиация
• Брой случаи с потенциално въздействие върху лични данни
• Брой издадени съобщения към клиенти

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

Чести модели на провал, които трябва да се премахнат

Първият провал е третирането на SBOM съвпадение като анализ на експлоатируемостта. Съвпадението на компонент е сигнал, не заключение.

Вторият провал е използването на „not affected“ без обосновка. Одиторите ще попитат защо. Недостижим ли беше пътят в кода? Беше ли деактивирана уязвимата функционалност? Беше ли версията различна? Използваше ли се компонентът само при компилация? Беше ли заключението одобрено от продуктовата сигурност?

Третият провал е оставянето на „under investigation“ отворен без край. Този статус е полезен само със собственик, срок и временни контроли.

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

Петият провал е игнорирането на личните данни и комуникацията с клиенти. Уязвимост, която може да изложи лични данни, изисква оценка по GDPR. Потвърдена продуктова уязвимост, която може да засегне клиенти, изисква дисциплина за координирано оповестяване. Зависимост във финансова услуга може да изисква анализ на инцидент по DORA.

Шестият провал е слабото съхраняване на доказателства. Zenith Blueprint предупреждава в Step 23, контрол 5.28, че доказателствата често се пренебрегват:

„това, което можете да докажете, е също толкова важно, колкото и това, което действително се е случило“

Това изречение обобщава реалността през 2026 г. Екипите по сигурността не само отстраняват уязвимости. Те доказват, че решенията са били своевременни, риск-базирани и контролирани.

Следващи стъпки за доказателства за уязвимости, годни за одит

Ако вашата организация вече има SBOM, следващата стъпка на зрялост не е още една инвентарна таблица. Тя е управление на статуса на уязвимостите, съобщенията от доставчици и доказателствата за оповестяване.

Започнете с четири действия:

1. Добавете приемане на CSAF и VEX към процедурата си за управление на уязвимости.
2. Дефинирайте критерии за одобрение за affected, not affected, fixed и under investigation.
3. Свържете VEX записите с вашия Регистър на риска на СУИС, регистър на доставчиците, инвентар на активите, SBOM хранилище и процес за инциденти.
4. Тествайте процеса с едно скорошно критично съобщение и създайте пакет с доказателства, готов за одит.

Clarysec може да ви помогне да внедрите това бързо чрез Zenith Blueprint, Zenith Controls и съответния набор от политики, включително Политика за управление на уязвимости и корекции, Политика за управление на уязвимости и корекции - SME, Политика за изискванията за сигурност на приложенията - SME, Политика за сигурна разработка, Политика за събиране на доказателства и форензика - SME и Политика за координирано оповестяване на уязвимости.

Печелившият въпрос през 2026 г. не е „Имаме ли SBOM?“ Той е „Можем ли да докажем, за всяко сериозно съобщение, точно как сме определили статуса на уязвимостта, третирали сме риска и сме комуникирали резултата?“

Запазете оценка с Clarysec или поискайте съответния набор от политики, за да превърнете VEX и CSAF в доказателства за уязвимости, готови за одит, преди следващото критично съобщение да достигне до вашия управителен съвет.