GitHub постави на обсъждане предложение за внедряване на услугата Sigstore за верификация на пакети чрез цифрови подписи и водене на публичен лог за потвърждение на автентичността при разпространение на релизи. Прилагането на Sigstore ще осигури допълнително ниво на защита срещу атаки, насочени към подмяна на софтуерни компоненти и зависимости (supply chain). Например, внедреното изменение ще защити изходните текстове на проектите в случай на компрометиране на акаунта на разработчика на една от зависимостите в NPM и формиране на злонамерена актуализация на пакета с вредоносен код.
Благодарение на новото ниво на защита разработчиците ще могат да свържат формирания пакет с използвания изходен код и среда за компилация, предоставяйки на потребителя възможност да се увери, че съдържанието на пакета съвпада с съдържанието на изходния код в основния репозиторий на проекта. Прилагането на Sigstore значително опростява процеса на управление на ключове и позволява да се избегнат сложностите, свързани с регистрацията, отзоваването и управлението на криптографски ключове. Sigstore се представя като аналог на Let’s Encrypt за кода, предоставящ сертификати за заверяване на кода с цифрови подписи и инструментариум за автоматизация на проверката.
Вместо постоянни ключове, в Sigstore се прилагат краткоживеещи ефимерни ключове, които се генерират на базата на правомощия. Използваният за подписване материал се отразява в защитен срещу изменения публичен лог, който позволява да се уверим, че авторът на подписа е именно този, за когото се представя, и подписът е формиран от същия участник, който е отговарял за предишните релизи. За осигуряване на целостта и защита от манипулации с данните задним числом се прилага дървовидна структура „дърво Меркла“ (Merkle Tree), в която всеки клон верифицира всички долни клонове и възли благодарение на съвместното (дървовидно) хеширане. Имайки крайния хеш, потребителят може да се увери в коректността на цялата история на операциите, както и в коректността на предишните състояния на базата данни (кореновият проверъчен хеш на новото състояние на базата се изчислява, като се взема предвид предишното състояние).
Източник: opennet.ru
