За последние несколько лет было написано много слов о СБОМ – Спецификация программного обеспечения. Несмотря на все это, люди чувствуют, что знают, что достаточно хорошо объяснить — это список компонентов программного обеспечения, он важен для прозрачности и безопасности и помогает выявить временные зависимости. Все это правда.
Тем не менее, SBOM не так однозначен, как кажется. Во-первых, учтите, что для обновления каждой новой версии библиотеки или патча требуется выпуск нового SBOM. Часто вы меняете или исправляете только одну или две библиотеки одновременно, чтобы можно было просто разобрать их новые ингредиенты, добавить их в SBOM и оставить все остальное без изменений, верно?
А как насчет понятия «известное-неизвестное»? Если разработчики знают, что им что-то не хватает, они могут ввести это как «известно-неизвестно» и заполнить пробелы позже (или не заполнить вообще).
Существуют также программные артефакты, которые очень сложны и включают в себя множество взаимосвязанных элементов, каждый из которых является программным артефактом сам по себе. Каждый элемент часто имеет свой собственный отдельный SBOM, а вся сборка может иметь более крупный агрегированный SBOM.
Все это показывает, что вместо четкого и простого файла SBOM вы можете получить множество различных, постоянно меняющихся элементов, которые необходимо постоянно поддерживать в актуальном состоянии.
Это все хорошо, но какая разница, если SBOM или часть SBOM не настолько точны и актуальны, насколько могли бы быть? Что мы можем сделать, чтобы сохранить как происхождение SBOM, так и его точность?
В этой статье мы рассмотрим использование SBOM при сканировании и раскрытии уязвимостей. Мы поговорим о криптографической подписи и посмотрим, как подписание SBOM или его частей делает его более полезным в качестве инструмента безопасности и прозрачности. Мы также поговорим о метаданных и о том, почему они так важны при создании SBOM и других артефактов, особенно при криптографической подписи в аттестации.
Начните здесь: что такое криптографическая подпись?
Криптографические подписи используются для проверки целостности и точности цифровых файлов или папок. Подписанный файл нельзя подделать, не сделав подпись недействительной, поэтому он будет немедленно обнаружен, как только кто-то попытается проверить подписанный документ.
Это делает цифровые подписи бесценным инструментом в арсенале безопасность программного обеспечения промышленности, и уже найдено множество применений простой концепции цифровой или криптографической подписи цифровых активов.
Как это работает? Цифровые подписи основаны на асимметричной криптографии, где у объекта есть два ключа — закрытый ключ и открытый ключ. Два ключа связаны друг с другом таким образом, что документ, подписанный личным ключом, можно проверить с помощью открытого ключа. Проверка будет означать как то, что документ не был каким-либо образом подделан (даже изменение одного бита сделает подпись непроверяемой), так и подтверждение личности подписавшего или, по крайней мере, идентичности используемого ключа.
Что ты делаешь с этим СБОМ?
SBOM — это не просто длинные сложные файлы, содержащие информацию о компонентах программного обеспечения. Они — ваш путь к точному знанию того, какие компоненты составляют ваш программный продукт. Вам необходимо знать полный список компонентов, поскольку даже если вы думаете, что точно знаете, что вы включили, есть вероятность, что с каждой добавленной библиотекой вы поставляете множество скрытых и временных зависимостей, каждая из которых может быть носителем уязвимости или эксплойта, который теперь включен в программное обеспечение, которое вы поставляете своим клиентам.
Получив SBOM и полный список ингредиентов, вы можете просмотреть этот список по базам данных известных уязвимостей и посмотреть, какие уязвимости включены в ваше программное обеспечение. Но это только начало. Любой, кто когда-либо проводил сканирование уязвимостей, знает, что результаты даже простого сканирования артефактов могут легко включать сотни (или более) уязвимостей.
Вот тут-то и начинается тяжелая работа: картирование каждой уязвимости, выяснение того, может ли она быть использована в вашем конкретном составе программного обеспечения, документирование этой информации и работа с уязвимостями, которые можно использовать, путем их исправления и исправления, желательно в порядке опасности, которую они представляют (действующие). эксплойты в дикой природе более опасны, чем теоретические эксплойты, которых еще никогда не было).
Вся эта работа, документация по уязвимостям и устранение уязвимостей важны для вас как производителя программного обеспечения, но они также важны для ваших клиентов, ваших партнеров и потенциальных аудиторов.
Они хотят знать, что вы знаете о потенциальных уязвимостях и что вы их контролируете, исправляя и исправляя недостатки, чтобы они не влияли на ИХ как ваших клиентов или партнеров.
Поскольку в этом отношении важно время выполнения сканирования из-за того, что новые уязвимости постоянно выходят на свет, подписание вашего SBOM вместе с метаданными того, КОГДА он был создан, является отличным способом показать, что вы действительно на высоте. вашего списка уязвимостей.
Таким способом можно доказать, что вы заранее знали об уязвимости и она неактуальна (с помощью VEX рекомендация), что его нет в определенной версии или что он вообще не существовал на момент выпуска последней версии.
Где подписать?
Теперь давайте заменим этот простой файл списка ингредиентов одним из более сложных вариантов использования, описанных в начале статьи. Как только вы объедините несколько SBOM в более крупную агрегированную версию, описывающую весь ваш артефакт, подписание и проверка каждой отдельной части этой агрегированной версии становится еще более важным. Допустим, вы создаете новую версию сложного программного продукта. В этой новой версии единственное, что изменилось, — это первая часть артефакта, состоящего из трех частей. Две другие части остаются точно такими же. Зачем вам тратить время и ресурсы на создание полного SBOM из трех частей, сканирование всех трех на наличие уязвимостей и сопоставление всех трех на наличие соответствующих эксплойтов? Единственные изменения были в части 1, так что это единственная часть, в которую вам следует вложить работу. Если вы подписали все 3 SBOM и сканирования уязвимостей в последний раз, когда вы их создавали, вы можете включить информацию о двух других частях, зная, что это не может быть они были изменены. Затем вы в любой момент сможете доказать, что SBOM для частей 3 и 3 идентичны исходным версиям. Конечно, вы можете выполнить сканирование еще раз, если вас беспокоят новые уязвимости, но это полностью зависит от вас и вашего программного обеспечения. анализ риска.
Возможность доказать своим клиентам, партнерам и аудиторам, когда и как часто вы создавали SBOM и сканировали их на наличие уязвимостей, полезна по многим причинам. Не в последнюю очередь это то, что его можно использовать в суде, чтобы доказать, что вы не несете ответственности за ущерб, нанесенный эксплойтом, поскольку вы сделали все, что должны были защитить, тем самым получив безопасная гавань.
Куда пойти отсюда
Как мы заявляли ранее, одной из проблем, связанных с цифровой подписью программных артефактов или файлов, является сложность работы с системами управления ключами. Как только мы устраним эту проблему, используя что-то вроде Sigstore, чтобы обойти использование традиционной PKI и автоматизировать процесс подписания и проверки, у нас действительно останется мало причин не использовать этот инструмент безопасности. Если вы считаете, что удостоверение, используемое для подписи файла или артефакта, также может использоваться в политике, проверяющей безопасность вашего конвейера CI/CD, у вас должно быть еще больше мотивации начать подписывать практически все, что попадается на глаза.
Подписание файлов их метаданными может помочь вам проверить время и место их происхождения, а также личность и систему, в которой они были созданы, а также всю соответствующую информацию, если рассматривать ее через призму специалиста по безопасности. Возможность определить, что человек, система и время соответствуют компании и конвейеру, в котором было создано программное обеспечение, является хорошей идеей, когда простая замена может представить подписанную убедительную подделку — до тех пор, пока не будет проверен поющий персонаж.
Учитывая, что инструмент, который я бы предложил для подписания и проверки доказательств, можно использовать бесплатно, у вас действительно не должно быть оправданий. Ознакомьтесь с нашей полной статьей о Валинт – наш инструмент проверки целостности, чтобы узнать, что еще вы можете с ним сделать, и начать подписывать свои SBOM и другие сгенерированные доказательства уже сегодня.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
