Натискът за все по-бързо пускане на софтуер възпрепятства разработчиците да контролират напълно промените във версиите (снимка: CC0 Public Domain)
Софтуерът продължава да става все по-сложен, тъй като повече от всякога досега разработчиците добавят отворен код и код на трети страни към своите приложения. Междувременно се увеличава регулирането, което налага да се знае откъде идват софтуерните компоненти, кой ги е създал, кога, с каква цел и номера на версията. Затова необходимостта от “софтуерните сметки за материали” (SBOM), които не са ново явление, продължава да нараства.
Като се има предвид постоянният натиск за все по-бързо пускане на софтуер, версиите на продуктите непрекъснато се променят по начини, които разработчиците не могат да контролират. Разбирането на състава на софтуера чрез SBOM включва „уязвимости, използване на лицензи, индикатори около сложността, нарушения на инженерните политики или произволен брой неща, свързани със състава на софтуера”, казва Майкъл Либерман, технически директор и съосновател Kusari в интервю за Information Week.
„Важно е, че SBOM не е необходимо да съществуват във вакуум. Те са отворен стандарт, който позволява на организациите не само да разберат риска, свързан с отделен софтуер, но могат да бъдат използвани за по-добро разбиране на риска в множество софтуерни части”, допълна Либерман.
Зависимости и съответствие
Софтуерните зависимости са друга причина за използване на SBOM. „Като се има предвид, че почти нито един разработчик не вижда всеки един ред код, който всяка зависимост внася в неговото приложение, е по-критично от всякога да имаме множество пътища за откриване на нови заплахи, проникващи в софтуерните вериги за доставки”, казва Ерик Фурие, главен изпълнителен директор на GitGuardian. „SBOM могат да помогнат на екипите по сигурността да наблюдават нови проблеми и да действат бързо, когато бъде открит и докладван нов експлойт”.
Съответствието също е двигател. „Един от основните рискове за съответствие, свързани с BOM, е да се гарантира, че всички компоненти, използвани в софтуера, отговарят на съответните лицензи. Различните лицензи с отворен код имат различни изисквания, вариращи от разрешителни лицензи, които позволяват широко използване и модифициране, до по-ограничителни лицензи, които изискват производни продукти да бъдат пуснати под същия лиценз. Неспазването на лицензионните условия може да доведе до големи правни последици за организациите, включително съдебни дела и глоби”, казва Джъстин Реок, ръководител на отдела за връзки с разработчиците в Cortex IDP.
„За да смекчат тези рискове, компаниите трябва да внедрят стабилни процеси за създаване и поддържане на точни BOM, провеждане на редовни оценки на уязвимостите, ефективно управление на лицензи и осигуряване на съответствие с регулаторните и договорни задължения през целия жизнен цикъл на разработка на софтуер”, съветва той.
AI – възможност и риск
Изкуственият интелект помага за разбирането на софтуерните съставки, но крие и риск. AI се вгражда във всички видове приложения и SBOM не са изключение. В съчетание с автоматизация, AI прави бързо и лесно разбирането на това, което има в SBOM, докато GenAI улеснява “прочитането” на SBOM, въпреки че човек не трябва да се доверява сляпо на резултатите.
„Някои модели на AI показаха, че могат да бъдат добри в обобщаването на данни. Така че, ако имате набор от SBOM, те потенциално могат да ви помогнат да прочетете тези данни и да предоставите човешко резюме за тях. Бъдете внимателни обаче, тъй като те могат да бъдат склонни към неточности и е изключително важно да се използват като допълнение към други инструменти и да помогнат за обяснението, но не и да се използват при вземане на решения без допълнителни портове”, казва Либерман от Kusari.
„От друга страна, AI е огромен риск за веригата за доставки. Както при традиционния софтуер с отворен код, така и при софтуера от доставчик, можете да го проследите в повечето случаи. Но в момента е трудно да се проследи AI модел до данните, върху които е бил обучен. Това води както до рискове за сигурността, дължащи се на обучение на потенциално злонамерени данни и други задължения, ако се окаже, че моделите са обучени на предубедени или незаконни данни”.
Кодът, генериран от AI, също е риск, който трябва да се вземе предвид. „Видяхме как разработчиците се доверяват все повече и повече на създадения от AI код. Опасно е как те стават самодоволни, че резултатите са достатъчно добри, за да бъдат изпратени в производство без задълбочена проверка”, казва Фурие от GitGuardian.
„Без старание във всеки ред код, който AI произвежда, пакетите, които AI просто съставят и от които лошите актьори са се възползвали, ще продължат да бъдат нарастваща заплаха. SBOM са още един инструмент, който можем да използваме, за да поддържаме бдителност”, допълва той.
Мъдър съвет
Организациите, които не използват SBOM, е разумно да започнат да го правят сега. „Просто е, започнете да записвате възможно най-много данни за софтуера, който въвеждате. Генерирайте SBOM, сканирания за статичен анализ и атестации за изграждане на софтуер като in-toto/SLSA, за да започнете. Поискайте SBOM от вашите доставчици и ги потърсете в отворен код, като същевременно проверявате дали данните в SBOM, които консумирате, са достатъчно пълни, за да бъдат полезни, казва Либерман от Kusari.
„Данните са най-критичната част от пъзела. Може да разработвате и използвате софтуер безопасно, но ако нямате данните, няма да имате видимост какво пропускате и какво да правите, когато се случи нещо неизбежно като следващия log4shell”, предупреждава той.
Майк Либорг, CISO в компанията за сигурност Swimlane, също предупреждава, че организациите трябва да внимават да не споделят прекалено много своите SBOM, защото лошите актьори могат да ги използват за нечестиви цели. „Те могат много бързо да видят, че има критичен път. Софтуер A, B и C използват това, така че те биха могли да намалят обхвата на своите разузнавателни дейности”.
„Никой не може да вземе вашия SBOM и да копира вашата кодова база. Това не е рискът. Рискът е, че това потенциално е пътна карта за лош актьор и ако наистина не променяте стека на приложението си, това е просто непрекъснато разпространение на всякакви възможни уязвимости, които могат да бъдат свързани със зависимостите във веригата на доставки”, пояснява Либорг.
И накрая, уверете се, че използването на SBOM не е упражнение за поставяне на отметки, съветват експертите. В противен случай човек може да загуби ползите. „Ако не знаете какво управлявате и не ви пука, може да имате по-големи проблеми”, казва Виле Айкас, съосновател на доставчика на сигурност на веригата за доставки Chainguard.
„Една от причините [да имате SBOM] е да разберете дали сте били засегнати от уязвимост. Другото нещо е, че понякога има части от софтуера, които вече не се поддържат. Ако софтуерът не се поддържа, тогава трябва да намеря алтернатива или да започна да го поддържам сам”, заключава Айкас.