Инспекция и проверка кодовых баз на соответствие требованиям

Завершено

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

Почему важны инспекция и валидация

Проблема зависимостей: Приложения не только зависят от пакетов, которые вы импортируете напрямую. Каждая прямая зависимость обычно зависит от дополнительных пакетов (транзитивных зависимостей), создания глубоких деревьев зависимостей. Обычное приложение может напрямую ссылаться на 20-30 пакетов, но транзитивно зависит от 200-500 пакетов. Вы несете ответственность за уязвимости и лицензионные обязательства во всех зависимостях, и не только за непосредственные.

Императив безопасности: Уязвимости безопасности в зависимостях представляют значительные риски. Злоумышленники активно эксплуатируют известные уязвимости в популярных пакетах, делая неоткрытые зависимости привлекательными целевыми объектами. Громкие нарушения часто включают использование известных уязвимостей в компонентах с открытым исходным кодом, которые организации не смогли обновить.

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

Операционная реальность: Зависимости постоянно изменяются. Новые уязвимости раскрываются ежедневно, пакеты получают обновления, обслуживающие отказались от проектов и выпускаются новые версии. Однократная проверка недостаточно— требуется непрерывная проверка.

Что необходимо проверить и утвердить

Комплексная проверка базы кода охватывает несколько измерений:

Инвентаризация зависимостей

Создание полного счета за материалы:

• Прямые зависимости: Пакеты явно перечислены в файлах манифеста пакета (package.json, requirements.txt, pom.xml, *.csproj).
• Транзитивные зависимости: Пакеты, необходимые для прямых зависимостей, на нескольких уровнях.
• Зависимости разработки: Пакеты, используемые во время разработки и тестирования, но не поставляемые с рабочим кодом.
• Отслеживание версий: Определенные версии каждого пакета, используемого в настоящее время.
• Источники зависимостей: Какие реестры пакетов предоставляют зависимости (npm, PyPI, NuGet, Maven Central, частные реестры).

Почему полные запасы имеют значение:

• Управление уязвимостями: Вы не можете исправить уязвимости, о которые вы не знаете.
• Соответствие лицензии: Должен отслеживать обязательства по лицензии для всех зависимостей, а не только прямых.
• Планирование обновлений: Понимание связей зависимостей помогает планировать обновления, которые не будут нарушать совместимость.
• Видимость цепочки поставок: Точно знаете, какой внешний код включен в приложения.

Обнаружение уязвимостей безопасности

Определение известных уязвимостей:

• Сопоставление CVE (Общие уязвимости и экспозиции): Сравнение версий зависимостей с базами данных CVE, содержащими известные уязвимости.
• Оценка серьезности: Оценка серьезности уязвимостей с помощью оценки общих уязвимостей (общая система оценки уязвимостей) в диапазоне от 0 до 10.
• Анализ эксплойтируемости: Определите, активно ли уязвимости эксплуатируются в дикой природе.
• Доступность исправлений: Определите, какие версии исправляют уязвимости и доступны ли исправления.

Общие сведения об базах данных уязвимостей:

• Национальная база данных уязвимостей (NVD): Репозиторий данных уязвимостей для государственных организаций США на основе идентификаторов CVE.
• База данных рекомендаций GitHub: Курированные рекомендации по безопасности для пакетов в нескольких экосистемах.
• Списки рассылки по безопасности: Уведомления о безопасности на языке и платформе.
• Базы данных поставщика: Коммерческие средства SCA поддерживают собственные базы данных уязвимостей с дополнительной аналитикой.

Категории уязвимостей в зависимости:

• Недостатки внедрения: SQL-инъекция, инъекция команд, уязвимости межсайтового скриптинга в веб-фреймворках.
• Проблемы с проверкой подлинности: Слабые реализации проверки подлинности, проблемы управления сеансами, недостатки обработки учетных данных.
• Воздействие конфиденциальных данных: Небезопасное хранилище данных, неадекватное шифрование, утечка информации.
• Неправильное изменение конфигурации системы безопасности: Конфигурации по умолчанию с известными слабыми местами, ненужными функциями.
• Отказ в обслуживании: Уязвимости в истощении ресурсов, уязвимости в сложности алгоритмов.
• Недостатки десериализации: Небезопасная десериализация приводит к удаленному выполнению кода.

Проверка соответствия лицензий

Определение обязательств по лицензированием:

• Обнаружение лицензий: Определите, какие лицензии применяются к каждой зависимости.
• Классификация лицензий: Классифицируйте лицензии как пермиссивные, слабая копилефт, сильная копилефт или проприетарные.
• Анализ совместимости: Убедитесь, что лицензии разных зависимостей совместимы при объединении.
• Отслеживание обязательств: Требования к документам, такие как атрибуция, раскрытие исходного кода или лицензирование производных рабочих работ.

Распространенные проблемы с соответствием требованиям:

• Контаминация копилефта: Для зависимостей, лицензированных по GPL в закрытом программном обеспечении, может потребоваться открытие исходного кода всего приложения.
• Сбои атрибуции: Отсутствуют необходимые уведомления об авторских правах и текст лицензии в распределенном программном обеспечении.
• Несовместимые сочетания: Использование зависимостей с конфликтующими лицензиями, которые не могут быть юридически объединены.
• Изменения лицензии: Проекты иногда изменяют лицензии между версиями, требуя повторной оценки.

Оценка рисков лицензий:

• Высокий риск: Строгие лицензии copyleft (GPL, AGPL) в проприетарном распространении программного обеспечения.
• Средний риск: Слабые лицензии copyleft (LGPL, MPL) требуют тщательной интеграции.
• Низкий риск: Пропустимые лицензии (MIT, Apache 2.0, BSD) с минимальными ограничениями.
• Неизвестный риск: Пользовательские лицензии, неясные лицензии или отсутствующие сведения о лицензиях.

Оценка качества зависимостей

Оценка сопровождаемости зависимостей:

• Состояние обслуживания: Определите, активно ли поддерживаются или заброшены зависимости.
• Частота обновления: Оцените частоту получения обновлений и исправлений ошибок зависимостей.
• Здоровье сообщества: Оцените активность участников, время ответа на проблемы и взаимодействие с сообществом.
• Качество документации: Проверьте, имеют ли зависимости соответствующую документацию для правильного использования.
• Рекомендации по безопасности: Убедитесь, что проекты имеют ответственные процессы раскрытия и рекомендации по безопасности.

Показатели качества:

• Активное обслуживание: Регулярные фиксации, последние выпуски, адаптивные средства поддержки.
• Большое сообщество: Устойчивость обеспечивается многими участниками, звёздами, форками и пользователями.
• Четкая коммуникация: Активный трекер проблем, оперативные обсуждения, четкие замечания о выпуске.
• Осведомленность о безопасности: Опубликованная политика безопасности, исправление уязвимостей с запросом, рекомендации по безопасности.

Красные флаги:

• Заброшенные проекты: Никаких обновлений в течение многих лет, неактивные сопровождающие, накопление нерешённых проблем.
• Риск единого обслуживания: Критическая зависимость, поддерживаемая одним человеком, который может стать недоступным.
• Плохое качество: Неадекватное тестирование, частые ошибки, ломающие изменения в минорных версиях.
• Отсутствие безопасности: Нет политики безопасности, медленного реагирования на уязвимости, нераскрытых проблем безопасности.

Проблемы проверки вручную

Почему ручная проверка не масштабируется:

Подавляющее количество томов

• Сотни зависимостей: Даже небольшие приложения транзитивно зависят от сотен пакетов.
• Несколько приложений: Организации поддерживают десятки или сотни приложений, умножая число зависимостей.
• Постоянные изменения: Новые версии, выпускаемые ежедневно, делают любой ручной инвентарь сразу устаревшим.
• Человеческая ошибка: Отслеживание вручную неизбежно пропускает зависимости, особенно транзитивные.

Информация разбросана

• Несколько источников: Сведения об уязвимостях поступают из баз данных CVE, списков рассылки безопасности, рекомендаций GitHub, уведомлений поставщиков и раскрытий исследователей безопасности.
• Исследования лицензий: Для определения точных лицензий требуется изучение файлов исходного кода, документов readme и файлов лицензий в каждом пакете.
• Сведения о конкретной версии: Уязвимости и лицензии могут меняться между версиями, требуя исследования конкретной версии.
• Конфликтующие сведения: Различные источники иногда предоставляют противоречивые сведения об уязвимости или лицензии.

Анализ, требующий много времени

• Оценка уязвимостей: Исследование серьезности, эксплойтируемости и состояния исправления каждой уязвимости занимает значительное время.
• Анализ лицензий: Понимание условий лицензии, совместимости и обязательств требует юридического опыта.
• Планирование обновлений: Определение безопасных путей обновления с учетом критических изменений и конфликтов зависимостей является сложным.
• Непрерывный мониторинг: Для постоянного мониторинга новых уязвимостей и обновлений требуются выделенные ресурсы.

Отложенное обнаружение

• Задержка обнаружения: Процессы вручную обнаруживают уязвимости в течение нескольких недель или месяцев после раскрытия.
• Реактивный ответ: Организации учатся об уязвимостях от инцидентов безопасности, а не о упреждающей проверке.
• Циклы аудита: Периодические аудиты оставляют приложения уязвимыми между аудитами.
• Исправления для чрезвычайных ситуаций: Без непрерывного мониторинга критически важные уязвимости требуют аварийного исправления.

Автоматизированное решение

Средства анализа композиции программного обеспечения решают проблемы ручной проверки:

Автоматическое обнаружение

• Синтаксический анализ зависимостей: Средства SCA автоматически анализируют файлы манифеста пакета для идентификации зависимостей.
• Транзитивное разрешение: Инструменты следуют цепочкам зависимостей для создания полной спецификации материалов.
• Анализ файлов блокировки: Анализ файлов блокировки (package-lock.json, Pipfile.lock) с указанием точно установленных версий.
• Двоичное сканирование: Некоторые средства сканируют скомпилированные двоичные файлы и контейнеры для обнаружения внедренных зависимостей.

Непрерывный мониторинг

• Оповещения об уязвимостях в режиме реального времени: Получайте немедленные уведомления, когда новые уязвимости влияют на зависимости.
• Автоматические обновления: Такие средства, как GitHub Dependabot, автоматически создают pull-запросы при наличии обновлений системы безопасности.
• Видимость панели мониторинга: Централизованные панели мониторинга показывают состояние уязвимости во всех приложениях.
• Запланированное сканирование: Регулярное автоматическое сканирование гарантирует, что данные зависимостей остаются текущими.

Комплексные базы данных

• Агрегированные данные об уязвимостях: Средства SCA агрегируют сведения из NVD, GitHub Advisory Database, списков рассылки безопасности и баз данных поставщика.
• Базы данных лицензий: Сохраняйте исчерпывающие сведения о лицензии, включая полные тексты лицензий и сводки обязательств.
• Курирование и проверка: Поставщики проверяют и курируют данные уязвимостей, чтобы уменьшить ложные положительные результаты.
• Собственная аналитика: Коммерческие инструменты предоставляют дополнительные исследования и анализ за пределами общедоступных баз данных.

Интеллектуальный анализ

• Оценка серьезности: Автоматически вычислять оценки CVSS и определять приоритеты уязвимостей по риску.
• Анализ доступности: Определите, используются ли уязвимые пути кода в приложении.
• Руководство по исправлению: Предоставьте определенные рекомендации по версиям, которые устраняют уязвимости при сохранении совместимости.
• Принудительное применение политик: Автоматическое сбой сборки или блокирование развертываний при обнаружении нарушений политики.

Создание базовых показателей проверки

Перед реализацией автоматического сканирования установите критерии проверки:

Политики безопасности

• Устойчивость к уязвимостям: Определите, какие уровни серьезности уязвимостей допустимы (например, нет критических или высоких, ограниченных средних).
• Интервалы времени исправления: Определите, насколько быстро необходимо устранить различные уязвимости серьезности.
• Процессы исключений: Создайте процедуры для принятия рисков, когда немедленное исправление невозможно.
• Требования к отчетам: Определите, кто нуждается в уведомлениях об уязвимостях и как быстро.

Политики соответствия

• Утвержденные лицензии: Список лицензий, которые всегда допустимы (например, MIT, Apache 2.0).
• Ограниченные лицензии: Определите лицензии, требующие специального утверждения (например, LGPL) или запрета (например, GPL для частного программного обеспечения).
• Требования к атрибуции: Определите способ предоставления атрибуции в распределенном программном обеспечении.
• Следы аудита: Укажите требования к документации для подтверждения соответствия требованиям.

Стандарты качества

• Требования к обслуживанию: Определите минимальные ожидания обслуживания (например, обновления за прошлый год).
• Размер сообщества: Установите пороговые значения для допустимых метрик работоспособности сообщества.
• Стандарты документации: Укажите минимальные требования к документации для зависимостей.
• Практики безопасности: Требовать, чтобы зависимости имели опубликованные политики безопасности и оперативно справлялись с уязвимостями.

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