Google предлага да установи нови правила за подобряване на сигурността с отворен код

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

Проблемът е сложен и има много аспекти за покриване, от веригата на доставки, управлението на зависимостите, идентичността, наред с други неща. За да направи това, наскоро Google пусна рамка („Know, Prevent, Fix“), която обяснява как индустрията може да мисли за уязвимости в отворен код и конкретни области, които трябва да бъдат разгледани първо.

Google обяснява причините си:

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

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

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

Познайте уязвимостите на вашия софтуер

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

• Цел: Точни данни за уязвимост: Първо, от решаващо значение е да се съберат точни метаданни за уязвимост от всички налични източници на данни. Например, знанието коя версия е въвела уязвимост помага да се определи дали софтуерът е засегнат и знанието кога е поправено води до точни и навременни корекции (и тесен прозорец за потенциална експлоатация). В идеалния случай този работен процес на класификация трябва да бъде автоматизиран.
• Второ, повечето уязвимости се крият във вашите зависимости, а не в кода, който пишете или контролирате директно. Така че дори когато вашият код не се променя, пейзажът от уязвимости, засягащи вашия софтуер, може постоянно да се променя - някои са коригирани, други са добавени.
• Предназначение: Стандартна схема за бази данни за уязвимости Необходими са инфраструктурни и индустриални стандарти за проследяване и поддържане на уязвимости с отворен код, разбиране на последствията от тях и управление на техните смекчаващи мерки. Стандартна схема за уязвимост би позволила общите инструменти да работят в множество бази данни за уязвимост и да опрости задачата за проследяване, особено когато уязвимостите пресичат множество езици или подсистеми.

Избягвайте да добавяте нови уязвимости

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

Тук, Google предлага да се съсредоточи върху два конкретни аспекта:

• Разберете рисковете при вземане на решение за нова зависимост
• Подобрете критичните процеси за разработване на софтуер

Поправете или премахнете уязвимости

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

Той също така споменава: 

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

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

Fuente: https://security.googleblog.com