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

Безопасность программного обеспечения с открытым исходным кодом привлекла внимание отрасли., но решения требуют консенсуса по проблемам и сотрудничества в реализации.

Проблема сложная, и ее нужно охватить множеством аспектов. от цепочки поставок, управления зависимостями, идентификации, среди прочего. Для этого компания Google недавно выпустила структуру («Знай, предотвращай, исправляй»), которая объясняет, как отрасль может думать об уязвимостях в открытых исходных кодах и конкретных областях, которые необходимо устранить в первую очередь.

Google объясняет причины:

«Благодаря недавним событиям мир программного обеспечения получил более глубокое понимание реального риска атак на цепочку поставок. Программное обеспечение с открытым исходным кодом должно быть менее рискованным с точки зрения безопасности, поскольку весь код и зависимости открыты и доступны для проверки и проверки. И хотя в целом это так, предполагается, что люди действительно проводят эту инспекционную работу. При таком большом количестве зависимостей невозможно отслеживать все из них, а многие пакеты с открытым исходным кодом не поддерживаются должным образом.

«Программа обычно прямо или косвенно зависит от тысяч пакетов и библиотек. Например, Kubernetes теперь зависит примерно от 1000 пакетов. Открытый исходный код, вероятно, использует зависимости, а не проприетарное программное обеспечение, и поставляется более широким кругом поставщиков; количество независимых объектов, которым можно доверять, может быть очень большим. Это крайне затрудняет понимание того, как открытый исходный код используется в продуктах и ​​какие уязвимости могут быть актуальными. Также нет гарантии, что то, что создано, будет соответствовать исходному коду.

В рамках, предложенных Google, предлагается разделить эту трудность на три в значительной степени независимые проблемные области, каждая из которых имеет определенные цели:

Знайте уязвимости своего программного обеспечения

Узнать уязвимости вашего программного обеспечения сложнее, чем вы могли ожидать по многим причинам. да хорошо есть механизмы сообщения об уязвимостях, неясно, действительно ли они влияют на конкретные версии программного обеспечения, которое вы используете:

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

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

Было бы идеально избежать создания уязвимостей И хотя инструменты тестирования и анализа могут помочь, профилактика всегда будет сложной задачей.

здесь, Google предлагает сосредоточиться на двух конкретных аспектах:

• Осознайте риски при выборе новой зависимости
• Улучшение критически важных процессов разработки программного обеспечения

Исправить или удалить уязвимости

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

Также упоминается: 

«Сегодня здесь мало пользы, но по мере того, как мы повышаем точность, стоит инвестировать в новые процессы и инструменты.

«Один из вариантов, конечно, - исправить уязвимость напрямую. Если вы можете сделать это обратно совместимым способом, решение будет доступно каждому. Но проблема в том, что у вас вряд ли есть опыт решения проблемы или прямая способность вносить изменения. Устранение уязвимости также предполагает, что лица, ответственные за обслуживание программного обеспечения, осведомлены о проблеме и обладают знаниями и ресурсами, чтобы раскрыть уязвимость.

источник: https://security.googleblog.com