Новая надежда на безопасность программного обеспечения

Мэтт Эсей

Участник, InfoWorld |

Уязвимость Log4j в декабре 2021 года выявила цепочку поставок программного обеспечения как область безопасности, которой массово пренебрегают. Это показало, насколько взаимосвязаны наши программные артефакты и что наши системы защищены настолько, насколько безопасны их самые слабые звенья. Это также укрепило идею о том, что мы можем думать, что безопасность — это то, что мы можем купить, но на самом деле речь идет о том, как мы действуем как команды разработчиков.

С тех пор мы стремимся к улучшению.

Пожалуй, наиболее примечательно то, что проект Sigstore, исходный код которого был открыт Google, стал де-факто методом подписи для программных артефактов, принятым всеми основными языковыми экосистемами, включая Java, Python, Node, Ruby и другие. Он стал одним из самых быстро внедряемых проектов безопасности с открытым исходным кодом в истории и дал разработчикам «сургучную печать» подлинности для определения происхождения и происхождения строительных блоков их программного обеспечения.

Итак, мы уже там?

Не совсем. Еще нет. Концепция спецификации программного обеспечения (SBOM), представленная указом Белого дома в мае 2021 года, по-прежнему кажется отдаленной. Эта концепция лингва-франка, позволяющая разработчикам обмениваться списками ингредиентов в пакетах программного обеспечения, имеет несколько новых форматов (SPDX, CycloneDX), что усложняет ситуацию. Хуже того, не было ясно, как SBOM на самом деле впишутся в рабочие процессы разработчиков и какие конкретные преимущества разработчик получит в этом процессе.

Что начинает объединять все это — и делает более актуальным создание целостной стратегии в отношении подписания программного обеспечения, SBOM и рабочего процесса разработчиков — это регулирование, которое потребует более строгого контроля над целостностью безопасности программного обеспечения.

Еще в апреле Агентство кибербезопасности и инфраструктуры (CISA) опубликовало запрос на комментарии по недавно предложенной форме аттестации безопасной разработки программного обеспечения, которая возложит на руководителей компаний-разработчиков программного обеспечения обязанность подтверждать, что их программное обеспечение было создано в безопасных средах и что были предприняты добросовестные и разумные усилия для поддержания надежных цепочек поставок исходного кода.

Что считается «разумным»?

На данный момент «разумными» усилиями кажутся руководящие принципы, изложенные в «Требованиях FedRAMP к сканированию уязвимостей для контейнеров» и «Среде безопасной разработки программного обеспечения» Национального института стандартов и технологий. Но гораздо более тонкая и читабельная интерпретация новых требований к самоаттестации содержится в разделах, касающихся стороннего кода, встроенного в программное обеспечение. Короче говоря, поставщики программного обеспечения будут нести ответственность за нефинансируемый и неподдерживаемый популярный открытый исходный код, который они используют в своих цепочках поставок.

Чего ждать? Ответственен за какой-то случайный код сопровождающего проекта? Судя по всему, да. Это «разумно»?

Этот головокружительный разброс мнений для директоров по информационной безопасности стал предметом множества мемов в Твиттере:

Это несколько шокирующая, хотя и необходимая, проверка на беспрепятственное внедрение открытого исходного кода. Я не предлагаю компаниям не использовать открытый исходный код, скорее наоборот. Я напоминаю вам, что бесплатного обеда не бывает, в том числе когда оно поставляется в виде бесплатного (и с открытым исходным кодом) программного обеспечения. Кому-то нужно платить, чтобы поддерживать свет для сопровождающих, а кто-то должен помогать разработчикам разобраться во всем этом входящем программном обеспечении с открытым исходным кодом.

Chainguard как раз может быть таким кем-то.

Chainguard — компания, возглавляемая бывшими сотрудниками Google, работавшими над проектом Sigstore. Он пытается объединить все это в единую цепочку инструментов для разработчиков. Первые усилия стартапа были сосредоточены на мерах по блокированию процесса сборки и созданию таких функций, как подписи, происхождение и SBOM, встроенных в цепочки поставок программного обеспечения и процесс сборки программного обеспечения. В прошлом году вместе с Wolfi они представили первый (не)дистрибутив Linux, созданный специально для примитивов безопасности цепочки поставок. Они также запустили образы Chainguard, которые являются базовыми образами для автономных двоичных файлов, таких приложений, как nginx, и инструментов разработки, таких как компиляторы Go и C.