Безопасность с открытым исходным кодом получила отпор в 2022 году

Мэтт Эсей

Участник, InfoWorld |

В начале декабря исполнился год со дня краха системы безопасности Log4j. С тех пор мир программного обеспечения постоянно пытается гарантировать, что подобное никогда не повторится. Мы, наконец, видим некоторую динамику, поскольку недостающие звенья в безопасности цепочки поставок программного обеспечения начинают заполняться.

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

Не покрыли себя славой и поставщики систем безопасности. Сначала мы увидели волну оппортунистических маркетологов программного обеспечения для обеспечения безопасности, которые бросились позиционировать свои продукты как прямые решения. Но, по словам Дэна Лоренка, генерального директора и основателя стартапа Chainguard, занимающегося безопасностью цепочек поставок программного обеспечения, «большинство сканеров используют базы данных пакетов, чтобы увидеть, какие пакеты установлены внутри контейнеров. Программное обеспечение, установленное за пределами этих систем, сложно идентифицировать, что делает его невидимым для сканеров».

Другими словами, поставщики средств безопасности продавали мысли и молитвы, а не реальные решения.

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

В сфере безопасности цепочки поставок программного обеспечения наблюдается невероятная активность, и в 2022 году вокруг вагонов кружит множество примеров сообщества открытого исходного кода.

Некоторые из них приветствуются, но по большей части являются пустыми публичными сигналами со стороны чиновников, такими как указ Белого дома о безопасности цепочки поставок программного обеспечения и Закон Сената США о защите программного обеспечения с открытым исходным кодом от 2022 года. Это хорошо, но безопасность программного обеспечения — это не публичные заявления. . К счастью, то, что действительно происходило в прошлом году, — это большая суета, направленная на то, чтобы вооружить разработчиков наборами инструментов для обеспечения безопасности цепочки поставок на более левом этапе жизненного цикла разработки программного обеспечения.

Неудивительно, что Linux Foundation и Cloud Native Computing Foundation активно участвовали в реализации этого в ключевых проектах с открытым исходным кодом. Например, формат SPDX SBOM проник на основные платформы, такие как Kubernetes. Фонд безопасности открытого исходного кода насчитывает более 100 членов и многие миллионы долларов финансирует новые стандарты и инструменты. Языки, безопасные для памяти, такие как Rust, поддерживаются ядром Linux для предотвращения целого класса уязвимостей, связанных с программными артефактами.

Возможно, самой заметной отдельной технологией, которая пришла в упадок в прошлом году, является Sigstore, инструмент для подписи кода, который был создан Google и Red Hat и стал де-факто «сургучной печатью», теперь встроенной в реестры программного обеспечения с открытым исходным кодом и цепочки инструментов. Kubernetes, npm и PyPi входят в число платформ и реестров, которые приняли Sigstore в качестве своих стандартов подписи. Важно отметить, что все эти подписи Sigstore сохраняются в общедоступном журнале прозрачности, что является важным новым импульсом для экосистемы безопасности, позволяющим начать связывать точки между подписями программного обеспечения, спецификациями программного обеспечения (SBOM) и всей цепочкой инструментов обеспечения безопасности в цепочке поставок программного обеспечения. .

Любой, кто обращал внимание на открытый исходный код в течение последних 20 лет (или даже последних двух лет), не будет удивлен, увидев, что вокруг этих популярных технологий с открытым исходным кодом начинает процветать коммерческий интерес. Как стало стандартом, этот коммерческий успех обычно называют облаком. Вот один яркий пример: 8 декабря 2022 года компания Chainguard, основатели которой вместе с Google создали Sigstore, выпустила Chainguard Enforce Signing, которая позволяет клиентам использовать Sigstore как услугу для создания цифровых подписей для программных артефактов внутри своих собственных устройств. организации, используя свои индивидуальные идентификаторы и одноразовые ключи.