Уязвимости в сигурността на кода
Софтуерът на операционната система, приложният софтуер или фърмуерът в една вградена система са елементарни компоненти на всяка дигитална инфраструктура. Въпреки това нарастващото ускорение и натискът за спазване на крайните срокове в проектите често водят до пренебрегване на наложителните аспекти на информационната сигурност. Изискванията за разработване на софтуер обикновено са функционално-ориентирани и наблягат на конструктивните аспекти, така че деструктивният поглед върху потенциалните уязвимости в сигурността най-често е диаметрално противоположен на действителните цели на разработката: на много програмисти просто им липсва и структуриран и изострен поглед върху киберсигурността.
При тези условия екипите за разработване трудно извършват непрекъснат преглед и последователно защитават кодирането на своя софтуер, както се вижда от многото уязвимости, които корпорацията с нестопанска цел MITRE Corporation публикува всяка година в своя списък CVE (Common Vulnerabilities and Exposures). Редовните пачове за сигурност дори на добре познати производители на софтуер са показател за сизифовската задача за отстраняване на грешки, свързани със сигурността, да не говорим за идентифицирането им още преди пускането им на пазара.
Код с отворен код - специален случай
Когато програмират самостоятелно разработен софтуер, програмистите обичат да прибягват до библиотеки и модули с отворен код. Практическите предимства са очевидни: ако не се налага да изобретявате колелото отново и отново, Вие се възползвате от този технологичен напредък, бърза разработка, по-ниски разходи за разработка, по-голяма прозрачност чрез отворения код и по-висока оперативна съвместимост чрез отворените стандарти и интерфейси.
Често се казва също, че кодът с отворен код предлага висока степен на сигурност, тъй като кодът е потвърден от много потребители, а роевият интелект на общността с отворен код позволява бързо и ефективно отстраняване на грешки.
На практика това доверие вече трябва да се оценява по диференциран и критичен начин. Най-сериозният пример е уязвимостта в сигурността от типа нулев ден Log4Shell в широко използваната библиотека за регистриране Log4J за Java приложения, която беше открита през ноември 2021 г. Може би сте чували за червеното ниво на предупреждение, издадено от Германската федерална служба за информационна сигурност (BSI) за Log4Shell. Библиотеката Log4J, разпространявана като надеждно функциониращ квазистандарт чрез Apache Foundation, се е установила в много системи от 2013 г. насам - включително в добре познати уеб услуги като Amazon AWS.
Сложността на тези добре разработени и също така поддържани библиотеки имплицитно предоставя мощни функционалности, за които импортиращият разработчик често не знае в собствената си комбинирана нова разработка, но които могат да бъдат използвани от нападателите.
Друг фактор за несигурност на компонентите с отворен код са т.нар. атаки по веригата на доставките, т.е. умишлено вградени уязвимости от злонамерени участници, които се представят за част от общността с отворен код и помагат в разработването на кода. Такава уязвимост е изключително ефикасен начин за хакерите да атакуват голям брой потребителски организации надолу по веригата. Затова не е чудно, че този вектор на атака се разраства бързо: проучване на Sonatype диагностицира 650% увеличение при сравняване на 2020 и 2021 г.
