Какво разкрива пощенската кутия за оповестяване на уязвимости на един разработчик относно въпроса, който Европейският акт за киберустойчивост (CRA) е напът да зададе на всеки доставчик на софтуер.

Автор: Shane Warden, главен архитект в ActiveState

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

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

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

Две или три от тези 95 се оказаха реални. Това е нисък процент и нямаше значение, защото все пак трябваше да прегледаме всички 95, за да открием онези две или три действителни уязвимости. След това дойде вторият имейл: платете 100 000 долара или докладът ще бъде публикуван публично с медиен отзвук от мащаба на Heartbleed.

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

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

На 11 септември 2026 г. ситуация, близка до описаната, престава да бъде проблем само на доброволците и става правен въпрос за огромен брой компании.

Тогава влизат в сила задълженията за докладване съгласно Европейския акт за киберустойчивост (EU Cyber Resilience Act): всеки производител на продукт с дигитални елементи, продаван в ЕС, трябва да уведоми ENISA в рамките на 24 часа след като узнае, че уязвимост в този продукт се експлоатира активно, с по-пълен доклад в рамките на 72 часа.

Частта от закона, която регламентира как точно се изгражда и поддържа продуктът – инженерните изисквания – започва да се прилага от 11 декември 2027 г.

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

Нашият главен изпълнителен директор, Abby Kearns, писа наскоро за тази времева разлика: за периода на този преходен етап CRA на практика представлява изискване за прозрачност и видимост, а не за сигурност. Съгласен съм! Преживял съм тази част лично: въпросът „какво е пуснато в експлоатация и кога за първи път научихме за проблем с него“ не е въпрос, на който екипите по съответствие ще отговарят за първи път през септември.

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

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

Всички заедно сме наблюдавали тази суматоха и преди. Когато САЩ издадоха Изпълнителна заповед 14028 през 2021 г. и започнаха да изискват софтуерен списък на материалите (SBOM) от доставчиците на федералното правителство, много организации генерираха SBOM по начина, по който се генерира всеки друг артефакт за съответствие: еднократно, под натиска на крайни срокове, точен за конкретния момент на създаване и остарял до момента, в който някой отново поиска да го види.

Документ, генериран миналия март, който никой не е отварял оттогава, не ви показва какво изпълнявате днес. Той показва какво сте изпълнявали през март. Европейският акт за киберустойчивост е много по-категоричен от тази изпълнителна заповед. Член 13 изисква SBOM да бъде актуален.

Тази празнина е по-голяма, отколкото повечето екипи очакват. 98% от приложенията съдържат компоненти с отворен код (Black Duck, Доклад за сигурност и анализ на риска при софтуера с отворен код за 2026 г.), така че почти всеки производител, продаващ на пазара в ЕС, трябва да отговори на това изискване, а не само ограничен брой частни случаи.

Сега производителите трябва да докажат какво е пуснато в експлоатация и кога са разбрали за него, докато нормативният часовник тиктака. Собствените статистически данни на индустрията за времето, необходимо за внедряване на корекция за сигурност, също не са обнадеждаващи: средното време за отстраняване на уязвимост с висока или критична степен в приложенията е около 55 дни (Edgescan, Доклад за статистика на уязвимостите за 2026 г.).

Прилагането на Европейския акт за киберустойчивост ще попадне точно в пролуката между ранното предупреждение от 24 часа, пълното уведомление в рамките на 72 часа и базовите срокове за отстраняване на уязвимости (Европейска комисия, задължения за докладване по Член 14 от Европейския акт за киберустойчивост).

Организациите преодоляват тази разлика по два начина. Някои изграждат капацитет вътре в организацията: оборудват собствените си процеси по разработка и внедряване (pipelines) с автоматично регенериране на SBOM, установяват документиран процес за обработка на уязвимости с определен отговорник и третират произхода като фундаментално свойство на софтуерната верига за доставки, а не като отчет, съставян под натиска на одит.

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

И двата подхода работят, но е рисковано в четиринадесетия месец от подготвителния период да откриете, че твърдението „ще бъдем в съответствие“ не е подкрепено с реалната способност да отговорите на въпроса при проверка.

Повечето екипи могат да отговорят само на 2 от тези 5 въпроса по Европейския акт за киберустойчивост. А вашият?

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

Възползвайте се от оценката за готовност за CRA (CRA Readiness Assessment), която лидерите в областта на сигурността и разработката използват, за да открият своите пропуски, преди ENISA да го направи.

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

Ние създадохме курираните каталози на ActiveState (ActiveState Curated Catalogs), за да запълним тази празнина: компоненти с отворен код в 12 езикови екосистеми, доставяни с неизменим произход на ниво компилация и коригирани съгласно договорни споразумения за ниво на обслужване (SLA) – 5 работни дни за критична уязвимост след появата на коригиращ код от разработчиците (upstream), 10 дни за висока степен и 30 за останалите.

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

Все още не знам колко строго ENISA ще налага спазването на Член 14 през първата година и се отнасям скептично към всеки, който твърди, че знае това със сигурност. Знам обаче, че докладът с 95 точки, който описах по-рано, не изчака регулация, за да постави въпроса. Той просто ме попита – с краен срок и обявена цена – дали наистина знам какво изпълнявам и колко бързо мога да го докажа.

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

Не чакайте 11 септември. Изберете продукт, който екипът ви е пуснал преди 6 месеца, и засечете колко време е необходимо на някого да ви каже какво съдържа той и кога за първи път сте разбрали за последната критична CVE уязвимост в него. Ако това отнеме повече от 72 часа, вече имате своя отговор.

Автор

Shane Warden, главен архитект в ActiveState

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

Спонсорирано и написано от ActiveState.