Изучение непрерывной проверки безопасности

Завершено

Сегодня разработчики не стесняются использовать компоненты, доступные в общедоступных источниках пакетов (например, npm или NuGet).

Благодаря более быстрой доставке и повышению производительности компоненты программного обеспечения с открытым исходным кодом (OSS) поощряются во многих организациях.

Однако, поскольку зависимость от этих сторонних компонентов OSS увеличивается, риск уязвимостей безопасности или скрытых требований к лицензии также увеличивает проблемы соответствия требованиям.

Для бизнеса это важно, так как проблемы, связанные с соответствием, обязательствами и личными данными клиента, могут привести к многим проблемам конфиденциальности и безопасности.

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

Многие средства могут проверять наличие этих уязвимостей в конвейерах сборки и выпуска.

После завершения слияния сборка CI должна выполняться в рамках pull request (PR-CI).

Как правило, основное различие между двумя запусками заключается в том, что процесс PR-CI не требует упаковки и промежуточного хранения в сборке CI.

Эти сборки CI должны выполнять статические тесты анализа кода, чтобы убедиться, что код следует всем правилам обслуживания и безопасности.

Для него можно использовать несколько средств:

  • SonarQube.
  • Анализ кода в Visual Studio и анализаторы безопасности Roslyn.
  • Checkmarx — средство тестирования безопасности статических приложений (SAST).
  • BinSkim — средство двоичного статического анализа, которое обеспечивает результаты безопасности и правильности для переносимых исполняемых файлов Windows и многое другое.

Многие средства легко интегрируются в процесс сборки Azure Pipelines. Дополнительные сведения о возможностях интеграции этих средств см. в Visual Studio Marketplace.

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

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

Организации, пытающиеся управлять уязвимостями сторонних пакетов или лицензиями OSS, объясняют, что их процесс мучен и вручную.

К счастью, средства Mend Software могут сделать этот процесс идентификации почти мгновенным.

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