Русский
Русский
English
Статистика
Реклама

Sca

Из песочницы DevSecOps принципы работы и сравнение SCA. Часть первая

26.08.2020 14:06:49 | Автор: admin
Значимость анализа сторонних компонентов ПО (англ. Software Composition Analysis SCA) в процессе разработки растет по мере выхода ежегодных отчетов об уязвимостях open source библиотек, которые публикуются компаниями Synopsys, Sonatype, Snyk, White Source. Согласно отчету The State of Open Source Security Vulnerabilities 2020 число выявленных уязвимостей в open source в 2019 выросло почти в 1.5 раза в сравнении с предыдущим годом, в то время как компоненты с открытым кодом используются от 60% до 80% проектов. Если обратиться к независимому мнению, то процессы SCA являются отдельной практикой OWASP SAMM и BSIMM в качестве показателя зрелости, а в первой половине 2020 года OWASP выпустила новый стандарт OWASP Software Component Verification Standard (SCVS), предоставляющий лучшие практики по проверке сторонних компонент в цепочке поставок ПО.



Один из самых показательных кейсов произошел с компанией Equifax в мае 2017 года. Неизвестные злоумышленники завладели информацией о 143 млн. американцев, включая полные имена, адреса, номера социального страхования и водительских удостоверений. В 209 000 случаях в документах также фигурировала информация о банковских картах пострадавших. Данная утечка произошла в следствие эксплуатации критической уязвимости в Apache Struts 2 (CVE-2017-5638), в то время как исправление было выпущено еще в марте 2017 года. У компании было два месяца на установку обновления, однако этим никто не озаботился.

В данной статье будет обсуждаться вопрос выбора инструмента для проведения SCA с точки зрения качества результатов анализа. Также будет приведено функциональное сравнение инструментов. Процесс встраивания в CI/CD и возможности по интеграции оставим на последующие публикации. Широкий список инструментов был представлен OWASP на своем сайте, но в рамках текущего обзора мы коснемся только самого популярного open source инструмента Dependency Check, чуть менее известной open source платформы Dependency Track и Enterprise-решения Sonatype Nexus IQ. Также разберемся, как работают эти решения и сравним полученные результаты на предмет ложных срабатываний.



Принцип работы


Dependency Check это утилита (CLI, maven, jenkins модуль, ant), которая анализирует файлы проекта, собирает фрагменты информации о зависимостях (package name, groupid, specification title, version), строит строку CPE (Common Platform Enumeration), Package URL (PURL) и выявляет для CPE/PURL уязвимости из баз данных (NVD, Sonatype OSS Index, NPM Audit API), после чего строит единоразовый отчет в формате HTML, JSON, XML

Рассмотрим, как выглядит CPE:

cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

  • Part: Указание о том, что компонент относится к приложению (a), операционной системе (o), железу (h) (Обязательный пункт)
  • Vendor: Название производителя продукта (Обязательный пункт)
  • Product: Название продукта (Обязательный пункт)
  • Version: Версия компоненты (Устаревший пункт)
  • Update: Обновление пакета
  • Edition: Наследуемая версия (Устаревший пункт)
  • Language: Язык, определяемый в RFC-5646
  • SW Edition: Версия ПО
  • Target SW: Программная среда, в которой работает продукт
  • Target HW: Аппаратная среда, в которой работает продукт
  • Other: Информация о поставщике или продукте

Пример CPE выглядит следующим образом:

cpe:2.3:a:pivotal_software:spring_framework:3.0.0:*:*:*:*:*:*:*

Строка означает, что CPE версии 2.3 описывает компонент приложения от производителя pivotal_software с названием spring_framework версии 3.0.0. Если мы откроем уязвимость CVE-2014-0225 в NVD, то можем увидеть упоминание этой CPE. Первая проблема, на которую сразу стоит обратить внимание CVE в NVD, согласно CPE, сообщает о наличии проблемы во фреймворке, а не в конкретной компоненте. То есть, если разработчики плотно завязаны на фреймворк, а выявленная уязвимость не касается тех модулей, которые используют разработчики, специалисту по безопасности так или иначе придется разбирать данную CVE и задумываться об обновлении.

URL-адрес также используется инструментами SCA. Формат URL-адреса пакета следующий:

scheme:type/namespace/name@version?qualifiers#subpath

  • Sсheme: Всегда будет 'pkg', указывающий, что это URL-адрес пакета (Обязательный пункт)
  • Type: Тип пакета или протокол пакета, например maven, npm, nuget, gem, pypi и т.д. (Обязательный пункт)
  • Namespace: Некоторый префикс имени, такой как идентификатор группы Maven, владелец образа Docker, пользователь или организация GitHub.Необязательный и зависит от типа.
  • Name: Имя пакета (Обязательный пункт)
  • Version: Версия пакета
  • Qualifiers: Дополнительные квалификационные данные для пакета, такие как ОС, архитектура, дистрибутив и т. Д. Необязательный и зависящий от типа пункт.
  • Subpath: Дополнительный путь в пакете относительно корня пакета

Например:

pkg:golang/google.golang.org/genproto#googleapis/api/annotationspkg:maven/org.apache.commons/io@1.3.4pkg:pypi/django-package@1.11.1.dev1

Dependency Track on-premise веб-платформа, которая принимает готовые Bill of Materials (BOM) сформированные CycloneDX и SPDX, то есть готовые спецификации об имеющихся зависимостях. Это XML-файл с описанием зависимостей name, hashes, package url, publisher, license. Далее Dependency Track разбирает BOM, смотрит имеющиеся к выявленным зависимостям CVE из базы данных уязвимостей (NVD, Sonatype OSS Index ), после чего строит графики, вычисляет метрики, регулярно обновляя данные о статусе уязвимости компонент.

Пример того, как может выглядеть BOM в формате XML:

<?xml version="1.0" encoding="UTF-8"?><bom xmlns="http://personeltest.ru/away/cyclonedx.org/schema/bom/1.2" serialNumber="urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79" version="1">  <components>    <component type="library">      <publisher>Apache</publisher>      <group>org.apache.tomcat</group>      <name>tomcat-catalina</name>      <version>9.0.14</version>      <hashes>        <hash alg="MD5">3942447fac867ae5cdb3229b658f4d48</hash>        <hash alg="SHA-1">e6b1000b94e835ffd37f4c6dcbdad43f4b48a02a</hash>        <hash alg="SHA-256">f498a8ff2dd007e29c2074f5e4b01a9a01775c3ff3aeaf6906ea503bc5791b7b</hash>        <hash alg="SHA-512">e8f33e424f3f4ed6db76a482fde1a5298970e442c531729119e37991884bdffab4f9426b7ee11fccd074eeda0634d71697d6f88a460dce0ac8d627a29f7d1282</hash>      </hashes>      <licenses>        <license>          <id>Apache-2.0</id>        </license>      </licenses>      <purl>pkg:maven/org.apache.tomcat/tomcat-catalina@9.0.14</purl>    </component>      <!-- More components here -->  </components></bom>

BOM может использоваться не только в качестве входных параметров для Dependency Track, но и для инвентаризации компонентов ПО в цепочке поставок, например, для предоставления заказчику ПО. В 2014 году на рассмотрение в США был даже предложен закон Cyber Supply Chain Management and Transparency Act of 2014, который гласил, что при закупке ПО любое гос. учреждение должно запрашивать BOM для предотвращения использования уязвимых компонент, однако в силу акт так и не вступил.

Возвращаясь к SCA, у Dependency Track есть готовые интеграции с Notification Platforms вроде Slack, системами управления уязвимостями вроде Kenna Security. Стоит также сказать, что Dependency Track ко всему прочему выявляет устаревшие версии пакетов и предоставляет информацию о лицензиях (за счет поддержки SPDX).

Если говорить именно о качестве SCA, то здесь есть принципиальная разница.

Dependency Track не принимает проект в качестве входных данных, а принимает именно BOM. Это означает, что если мы захотим проверить проект, то сначала нам нужно сгенерировать bom.xml, например, с помощью CycloneDX. Таким образом, Dependency Track напрямую зависит от CycloneDX. В то же время, это дает возможность кастомизации. Так команда OZON написала модуль CycloneDX для сборки BOM-файлов для проектов на Golang с целью дальнейшего сканирования через Dependency Track.

Nexus IQ коммерческое решение SCA от компании Sonatype, которое является частью экосистемы Sonatype, куда также входит Nexus Repository Manager. Nexus IQ может принимать в качестве входных данных как war архивы (для java проектов) через веб-интерфейс или API, так и BOM, если ваша организация не успела перестроиться с CycloneDX на новое решение. В отличие от open source решений, IQ обращается не только к CP/PURL к выявленной компоненте и соответствующей уязвимости в базе данных, но и учитывает собственные исследования, например, название уязвимой функции или класса. Механизмы IQ будут рассмотрены позднее при разборе результатов.

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

Язык Nexus IQ Dependency Check Dependency Track
Java + + +
C/C++ + + -
C# + + -
.Net + + +
Erlang - - +
JavaScript (NodeJS) + + +
PHP + + +
Python + + +
Ruby + + +
Perl - - -
Scala + + +
Objective C + + -
Swift + + -
R + - -
Go + + +

Функциональные возможности

Функциональные возможности Nexus IQ Dependency Check Dependency Track
Возможность обеспечивать проверку компонент, используемых в исходном коде на лицензионную чистоту + - +
Возможность сканирования и анализа на наличие уязвимостей и лицензионной чистоты для образов Docker + Интеграция с Clair - -
Возможность настройки политики безопасности для использования библиотек с открытым исходным кодом + - -
Возможность сканирования репозиториев с открытым исходным кодом на наличие уязвимых компонентов + RubyGems, Maven, NPM, Nuget, Pypi, Conan, Bower, Conda, Go, p2, R, Yum, Helm, Docker, CocoaPods, Git LFS - + Hex, RubyGems, Maven, NPM, Nuget, Pypi
Наличие специализированной исследовательской группы + - -
Работа в закрытом контуре + + +
Использование сторонних баз данных + Закрытая БД Sonatype + Sonatype OSS, NPM Public Advisors + Sonatype OSS, NPM Public Advisors, RetireJS, VulnDB, поддержка собственной БД уязвимостей
Возможность фильтровать компоненты с открытым исходным кодом при попытке загрузки в контур разработки согласно сконфигурированным политикам + - -
Рекомендации по исправлению уязвимостей, наличие ссылок на исправление + +- (зависит от описания в публичных базах) +- (зависит от описания в публичных базах)
Ранжирование обнаруженных уязвимостей по степени критичности + + +
Ролевая модель доступа + - +
Поддержка интерфейса командной строки CLI + + +- (только для CycloneDX)
Выборка / сортировка уязвимостей по определяемым критериям + - +
Dashboard по состоянию приложений + - +
Генерация отчётов в PDF-формате + - -
Генерация отчётов в формате JSON\CSV + + -
Поддержка русского языка - - -

Интеграционные возможности
Интеграция Nexus IQ Dependency Check Dependency Track
Интеграция с LDAP/Active Directory + - +
Интеграция с системой непрерывной интеграции (continous integration) Bamboo + - -
Интеграция с системой непрерывной интеграции (continous integration) TeamCity + - -
Интеграция с системой непрерывной интеграции (continous integration) GitLab + +- (в виде плагина для GitLab) +
Интеграция с системой непрерывной интеграции (continous integration) Jenkins + + +
Наличие плагинов к IDE + IntelliJ, Eclipse, Visual Studio - -
Поддержка кастомизированной интеграции через web-services (API) инструмента + - +


Dependency Check


Первый запуск


Запустим Dependency Check к умышленно уязвимому приложению DVJA.

Для этого воспользуемся Dependency Check Maven Plugin:

mvn org.owasp:dependency-check-maven:check

В результате в директории target появится dependency-check-report.html.



Откроем файл. После сводной информации об общем количестве уязвимостей можем увидеть информацию об уязвимостях с высоким уровнем Severity и Confidence с указанием на пакет, CPE, число CVE.

Следом идет более подробная информация, в частности то, на основе чего было принято решение (evidence), то есть некий BOM.



Далее идет CPE, PURL и описание CVE. Рекомендации об исправлении кстати не прилагаются в силу отсутствия их в базе NVD.



Для систематичного просмотра результатов сканирования можно настроить Nginx с минимальными настройками, либо отправлять полученные дефекты в систему управления дефектами, которые поддерживают конекторы к Dependency Check. Например, Defect Dojo.

Dependency Track


Установка


Dependency Track, в свою очередь, является веб-платформой с отображающими графиками, поэтому острый вопрос о хранении дефектов в стороннем решении здесь не стоит.
Для установки есть следующие поддерживаемые сценарии: Docker, WAR, Executable WAR.

Первый запуск


Переходим по URL запущенного сервиса. Входим через admin/admin, меняем логин и пароль, после чего попадаем на Dashboard. Следующее, что мы сделаем создадим проект для тестового приложения на Java в Home/Projects Create Project . В качестве примера возьмем DVJA.



Так как Dependency Track может принимать в качестве входных данных только BOM, этот BOM необходимо получить. Воспользуемся CycloneDX Maven Plugin:

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

Получаем bom.xml и загружаем файл в созданном проекте DVJA Dependeencies Upload BOM.

Зайдем в Administration Analyzers. Понимаем, что у нас включен только Internal Analyzer, включающий NVD. Подключим также Sonatype OSS Index.



Таким образом, получим следующую картину для нашего проекта:



Также в списке можно найти одну уязвимость, применимую к Sonatype OSS:



Основное разочарование было в том, что Dependency Track больше не принимает xml-отчеты Dependency Check. Последние поддерживаемые версии интеграции с Dependency Check были 1.0.0 4.0.2, в то время как я тестировал 5.3.2.

Вот видеовот), когда это было еще возможно.

Nexus IQ


Первый запуск


Установка Nexus IQ происходит из архивов по документации, но мы для этих целей собрали себе образ Docker.

После входа в консоль необходимо создать Организацию и Приложение.







Как можно видеть, настройка в случае с IQ происходит несколько сложнее, ибо нам также необходимо создать политики, применимые для разных стейджей (dev, build, stage, release). Это необходимо, чтобы блокировать уязвимые компоненты по мере продвижения по пайплайну ближе к проду, либо блокировать как только они попадают в Nexus Repo при скачивании разработчиками.

Чтобы ощутить разницу open source и enterprise, выполним такое же сканирование через Nexus IQ аналогично через Maven plugin, предварительно создав тестовое приложение в интерфейсе NexusIQ dvja-test-and-compare:

mvn com.sonatype.clm:clm-maven-plugin:evaluate -Dclm.applicationId=dvja-test-and-compare -Dclm.serverUrl=<NEXUSIQIP> -Dclm.username=<USERNAME> -Dclm.password=<PASSWORD>

Переходим по URL к сгенерированному отчету в веб-интерфейсе IQ:



Здесь можно увидеть все нарушения политики с указанием разного уровня значимости (от Info до Security Critical). Буква D рядом с компонентой означает, что компонента DirectDependency, а буква T рядом с компонентом означает, что компонента TransitiveDependency, то есть является транзитивной.

Кстати, отчет State of Open Source Security Report 2020 от Snyk сообщает, что более 70% уязвимостей open source обнаруженных в Node.js, Java и Ruby находятся в транзитивных зависимостях.

Если открыть одно из нарушений политики Nexus IQ, мы можем увидеть описание компоненты, а также Version Graph, который показывает местоположение текущей версии на временном графе, а также в какой момент уязвимость перестает быть уязвимой. Высота свечей на графе показывает популярность использования этой компоненты.



Если перейти в раздел уязвимостей и раскрыть CVE, то можно прочитать описание к этой уязвимости, рекомендации по устранению, а также причину, по которой данная компонента попала под нарушение, то есть наличие класса DiskFileitem.class.





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

Итого Nexus IQ:

  • Dependencies Scanned:62
  • Vulnerable Dependencies:16
  • Vulnerabilities Found:42 (8 sonatype db)

Итого Dependency Check:

  • Dependencies Scanned:47
  • Vulnerable Dependencies:13
  • Vulnerabilities Found:91 (14 sonatype oss)

Итого Dependency Track:

  • Dependencies Scanned: 59
  • Vulnerable Dependencies:10
  • Vulnerabilities Found:51 (1 sonatype oss)

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

Дисклеймер


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

Сравнение результатов


Условия:

Ложным срабатыванием по отношению к уязвимостям сторонних компонентов является:

  • Несоответствие CVE к выявленной компоненте
  • Например, если уязвимость выявлена во фреймворке struts2, а инструмент указывает на компоненту фреймворка struts-tiles, к которой эта уязвимость не относится, то это false positive
  • Несоответствие CVE к выявленной версии компоненты
  • Например, уязвимость привязана к версии python > 3.5 и инструмент отмечает уязвимой версию 2.7 это false positive, так как на самом деле уязвимость относится только к ветке продукта 3.x
  • Дублирование CVE
  • Например, если SCA указал на CVE, позволяющую реализовать RCE, после чего SCA указывает для этой же компоненты CVE, применимую к продуктам Cisco, подверженным этой RCE. В таком случае будет false positive.
  • Например, CVE была найдена в компоненте spring-web, после чего SCA указывает на эту же CVE в других компонентах фреймворка Spring Framework, в то время как CVE к другим компонентам отношения не имеет. В таком случае будет false positive.

Объектом исследования выбран Open Source проект DVJA. В исследовании участвовали только java компоненты (без js).

Сводные результаты


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

Сводные результаты по всем уязвимостям:
Параметр Nexus IQ Dependency Check Dependency Track
Всего выявлено уязвимостей 42 91 51
Неверно выявлено уязвимостей (false positive) 2(4.76%) 62(68,13%) 29(56.86%)
Не обнаружено релевантных уязвимостей (false negative) 10 20 27

Сводные результаты по компонентам:
Параметр Nexus IQ Dependency Check Dependency Track
Всего выявлено компонентов 62 47 59
Всего уязвимых компонентов 16 13 10
Неверно выявлены уязвимые компоненты (false positive) 1 5 0
Неверно выявлены уязвимые компоненты (false positive) 0 6 6

Построим визуальные графики, чтобы оценить соотношение false positive и false negative к общему числу уязвимостей. По горизонтали отмечены компоненты, а по вертикали выявленные в них уязвимости.







Для сравнения, аналогичное исследование было проведено командой Sonatype по тестированию проекта из 1531 компоненты с помощью OWASP Dependency Check. Как мы можем увидеть, соотношение шума к корректным срабатываниям соезмиримо с нашими результатами.


Источник: www.sonatype.com/why-precision-matters-ebook

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

Подробнее


1


Разберем сначала некоторые интересные моменты Sonatype Nexus IQ.

Nexus IQ указывает на проблему с десереализацией с возможностью выполнить RCE в Spring Framework несколько раз. CVE-2016-1000027 в spring-web:3.0.5 в первый раз, и CVE-2011-2894 в spring-context:3.0.5 и spring-core:3.0.5. Поначалу кажется, что происходит дублирование уязвимости по нескольким CVE. Ибо, если посмотреть CVE-2016-1000027 и CVE-2011-2894 в базе NVD, то кажется, что все очевидно

Компонент Уязвимость
spring-web:3.0.5 CVE-2016-1000027
spring-context:3.0.5 CVE-2011-2894
spring-core:3.0.5 CVE-2011-2894

Описание CVE-2011-2894 из NVD:


Описание CVE-2016-1000027 из NVD:


CVE-2011-2894 сама по себе довольно известная. В отчете White Source за 2011 год эта CVE была признана одной из самых часто встречающихся. Описания для CVE-2016-100027 в принципе немного в NVD, да и применима она, вроде бы, только для Spring Framework 4.1.4. Взглянем на reference и тут становится все более или менее понятно. Из статьи Tenable мы понимаем, что помимо уязвимости в RemoteInvocationSerializingExporter в CVE-2011-2894, уязвимость наблюдается в HttpInvokerServiceExporter. Об этом нам и говорит Nexus IQ:



Тем не менее ничего подобного нет в NVD, из-за чего Dependency Check и Dependency Track получают по false negative.

Также из описания CVE-2011-2894 можно понять, что уязвимость действительно присутствует и в spring-context:3.0.5 и в spring-core:3.0.5. Подтверждение этому можно найти в статье от того, кто эту уязвимость нашел.

2


Компонент Уязвимость Результат
struts2-core:2.3.30 CVE-2016-4003 FALSE

Если мы изучим уязвимость CVE-2016-4003, то поймем, что ее исправили еще в версии 2.3.28, тем не менее Nexus IQ нам о ней сообщает. В описании к уязвимости есть примечание:



То есть уязвимость существует только в связке с устаревшей версией JRE, о чем нас решили предупредить. Тем не менее, считаем это False Positive, хоть и не самым страшным.

3


Компонент Уязвимость Результат
xwork-core:2.3.30 CVE-2017-9804 TRUE
xwork-core:2.3.30 CVE-2017-7672 FALSE

Если мы посмотрим описание к CVE-2017-9804 и CVE-2017-7672, то поймем, что проблема в URLValidator class, причем CVE-2017-9804 вытекает из CVE-2017-7672. Наличие второй уязвимости не несет никакой полезной нагрузки кроме того, что ее severity вырос до High, поэтому можно считать это лишним шумом.

В целом других false positive для Nexus IQ найдено не было.

4


Есть несколько моментов, которые выделяют IQ на фоне других решений.
Компонент Уязвимость Результат
spring-web:3.0.5 CVE-2020-5398 TRUE


CVE в NVD сообщает, что она применима только для версий 5.2.x до 5.2.3, 5.1.x до 5.1.13, и версий 5.0.x до 5.0.16, тем не менее, если мы посмотрим описание CVE в Nexus IQ, то увидим следующее:
Advisory Deviation Notice: The Sonatype security research team discovered that this vulnerability was introduced in version 3.0.2.RELEASE and not 5.0.x as stated in the advisory.

После этого следует PoC к этой уязвимости, который сообщает, что она присутствует в версии 3.0.5.

False negative отправляется к Dependency Check и Dependency Track.

5


Посмотрим на false positive для Dependency Check и Dependency Track.

Dependency Check отдельно выделяется тем, что отражает те CVE, которые относятся ко всему фреймворку в NVD, в те компоненты, к которым эти CVE не применимы. Это касается CVE-2012-0394, CVE-2013-2115, CVE-2014-0114, CVE-2015-0899, CVE-2015-2992, CVE-2016-1181, CVE-2016-1182, которые Dependency Check прикрутил к struts-taglib:1.3.8 и struts-tiles-1.3.8. Эти компоненты не имеют ничего общего с тем, что описано в CVE обработка запросов, валидация страниц и так далее. Это обусловлено тем, что общее между этими CVE и компонентами только фреймворк, из-за чего Dependency Check и посчитал это уязвимостью.

Такая же ситуация с spring-tx:3.0.5, и похожая ситуация с struts-core:1.3.8. Для struts-core Dependency Check и Dependency Track нашли очень много уязвимостей, которые на самом деле применимы к struts2-core, который по сути является отдельным фреймворком. В данном случае Nexus IQ правильно понял картину и в тех CVE, которые выдал, указал, что struts-core пришел end of life и необходимо перейти к struts2-core.

6


В некоторых ситуациях трактовать явную ошибку Dependency Check и Dependency Track несправедливо. В частности CVE-2013-4152, CVE-2013-6429, CVE-2013-6430, CVE-2013-7315, CVE-2014-0054, CVE-2014-0225, CVE-2014-0225, которые Dependency Check и Dependency Track отнесли к spring-core:3.0.5 на самом деле относятся к spring-web:3.0.5. При этом часть из этих CVE были найдены и Nexus IQ, тем не менее IQ их корректно определил к другой компоненте. От того, что эти уязвимости не были найдены в spring-core, нельзя утверждать, что их нет во фреймворке в принципе и open source инструменты справедливо указали на эти уязвимости (просто немного промахнулись).

Выводы


Как мы можем видеть, определение достоверности выявленных уязвимостей ручным ревью не дает однозначных результатов, из-за чего возникают спорные моменты. Результаты таковы, что решение Nexus IQ обладает наименьшим показателем ложных срабатываний и наибольшей точностью.

В первую очередь, это связано с тем, что команда Sonatype расширило описание для каждой уязвимости CVE из NVD в своих базах, указав с точностью до класса или функции уязвимости для той или иной версии компоненты, проведя дополнительные исследования (например, проверив уязвимости на более старых версий ПО).

Немаловажное влияние на результаты играют и те уязвимости, которые не попали в NVD, но тем не менее присутствуют в базе Sonatype с пометкой SONATYPE. Согласно отчету The State of Open Source Security Vulnerabilities 2020 о 45% обнаруженных уязвимостей с открытым исходным кодом не сообщается в NVD. Согласно базе данных WhiteSource, только 29% всех уязвимостей с открытым исходным кодом, зарегистрированных за пределами NVD, в конечном итоге публикуются в ней, поэтому так важно искать уязвимости также в других источниках.

Как итог Dependency Check выдает большое количество шума, упуская часть уязвимых компонент. Dependency Track выдает меньший шум и выявляет большое число компонент, что визуально не режет глаза в веб-интерфейсе.

Тем не менее, практика показывает, что именно open source должен становится первым шагов на пути к зрелому DevSecOps. Первое, над чем стоит задуматься для встраивания SCA в разработку, это процессы, а именно размышления совместно с руководством и смежными департаментами над тем, как должны выглядеть идеальные процессы у себя в организации. Возможно, окажется так, что для вашей организации на первых порах Dependency Check или Dependency Track закроют все стоящие перед бизнесом потребности, а Enterprise-решения будут являться логическим продолжением в силу роста сложности разрабатываемых приложений.

Приложение А. Результаты применительно к компонентам
Условные обозначения:

  • High уязвимости высокого и критичного уровня в компоненте
  • Medium Уязвимости среднего уровня критичности в компоненте
  • TRUE Верно определенная уязвимость (True positive issue)
  • FALSE Ложное срабатывание (False positive issue)

Компонент Nexus IQ Dependency Check Dependency Track Результат
dom4j: 1.6.1 High High High TRUE
log4j-core: 2.3 High High High TRUE
log4j: 1.2.14 High High - TRUE
commons-collections:3.1 High High High TRUE
commons-fileupload:1.3.2 High High High TRUE
commons-beanutils:1.7.0 High High High TRUE
commons-codec:1:10 Medium - - TRUE
mysql-connector-java:5.1.42 High High High TRUE
spring-expression:3.0.5 High компонент не найден
TRUE
spring-web:3.0.5 High компонент не найден High TRUE
spring-context:3.0.5 Medium компонент не найден - TRUE
spring-core:3.0.5 Medium High High TRUE
struts2-config-browser-plugin:2.3.30 Medium - - TRUE
spring-tx:3.0.5 - High - FALSE
struts-core:1.3.8 High High High TRUE
xwork-core: 2.3.30 High - - TRUE
struts2-core: 2.3.30 High High High TRUE
struts-taglib:1.3.8 - High - FALSE
struts-tiles-1.3.8 - High - FALSE



Приложение Б. Результаты применительно к уязвимостям
Условные обозначения:

  • High уязвимости высокого и критичного уровня в компоненте
  • Medium Уязвимости среднего уровня критичности в компоненте
  • TRUE Верно определенная уязвимость (True positive issue)
  • FALSE Ложное срабатывание (False positive issue)

Компонент Nexus IQ Dependency Check Dependency Track Severity Результат Комментарий
dom4j: 1.6.1 CVE-2018-1000632 CVE-2018-1000632 CVE-2018-1000632 High TRUE
CVE-2020-10683 CVE-2020-10683 CVE-2020-10683 High TRUE
log4j-core: 2.3 CVE-2017-5645 CVE-2017-5645 CVE-2017-5645 High TRUE
CVE-2020-9488 CVE-2020-9488 CVE-2020-9488 Low TRUE
log4j: 1.2.14 CVE-2019-17571 CVE-2019-17571 - High TRUE
- CVE-2020-9488 - Low TRUE
SONATYPE-2010-0053 - - High TRUE
commons-collections:3.1 - CVE-2015-6420 CVE-2015-6420 High FALSE Дублирует RCE(OSSINDEX)
- CVE-2017-15708 CVE-2017-15708 High FALSE Дублирует RCE(OSSINDEX)
SONATYPE-2015-0002 RCE (OSSINDEX) RCE(OSSINDEX) High TRUE
commons-fileupload:1.3.2 CVE-2016-1000031 CVE-2016-1000031 CVE-2016-1000031 High TRUE
SONATYPE-2014-0173 - - Medium TRUE
commons-beanutils:1.7.0 CVE-2014-0114 CVE-2014-0114 CVE-2014-0114 High TRUE
- CVE-2019-10086 CVE-2019-10086 High FALSE Уязвимость применима только для версий 1.9.2+
commons-codec:1:10 SONATYPE-2012-0050 - - Medium TRUE
mysql-connector-java:5.1.42 CVE-2018-3258 CVE-2018-3258 CVE-2018-3258 High TRUE
CVE-2019-2692 CVE-2019-2692 - Medium TRUE
- CVE-2020-2875 - Medium FALSE Та же самая уязвимость как и CVE-2019-2692, но c припиской attacks may significantly impact additional products
- CVE-2017-15945 - High FALSE Не относится к mysql-connector-java
- CVE-2020-2933 - Low FALSE Дубликат к CVE-2020-2934
CVE-2020-2934 CVE-2020-2934 - Medium TRUE
spring-expression:3.0.5 CVE-2018-1270 компонент не найден - High TRUE
CVE-2018-1257 - - Medium TRUE
spring-web:3.0.5 CVE-2016-1000027 компонент не найден - High TRUE
CVE-2014-0225 - CVE-2014-0225 High TRUE
CVE-2011-2730 - - High TRUE
- - CVE-2013-4152 Medium TRUE
CVE-2018-1272 - - High TRUE
CVE-2020-5398 - - High TRUE Показательный пример в пользу IQ: The Sonatype security research team discovered that this vulnerability was introduced in version 3.0.2.RELEASE and not 5.0.x as stated in the advisory.
CVE-2013-6429 - - Medium TRUE
CVE-2014-0054 - CVE-2014-0054 Medium TRUE
CVE-2013-6430 - - Medium TRUE
spring-context:3.0.5 CVE-2011-2894 компонент не найден - Medium TRUE
spring-core:3.0.5 - CVE-2011-2730 CVE-2011-2730 High TRUE
CVE-2011-2894 CVE-2011-2894 CVE-2011-2894 Medium TRUE
- - CVE-2013-4152 Medium FALSE Дубликат этой же уязвимости в spring-web
- CVE-2013-4152 - Medium FALSE Уязвимость относится к компоненте spring-web
- CVE-2013-6429 CVE-2013-6429 Medium FALSE Уязвимость относится к компоненте spring-web
- CVE-2013-6430 - Medium FALSE Уязвимость относится к компоненте spring-web
- CVE-2013-7315 CVE-2013-7315 Medium FALSE SPLIT из CVE-2013-4152. + Уязвимость относится к компоненте spring-web
- CVE-2014-0054 CVE-2014-0054 Medium FALSE Уязвимость относится к компоненте spring-web
- CVE-2014-0225 - High FALSE Уязвимость относится к компоненте spring-web
- - CVE-2014-0225 High FALSE Дубликат этой же уязвимости в spring-web
- CVE-2014-1904 CVE-2014-1904 Medium FALSE Уязвимость относится к компоненте spring-web-mvc
- CVE-2014-3625 CVE-2014-3625 Medium FALSE Уязвимость относится к компоненте spring-web-mvc
- CVE-2016-9878 CVE-2016-9878 High FALSE Уязвимость относится к компоненте spring-web-mvc
- CVE-2018-1270 CVE-2018-1270 High FALSE Для spring-expression / spring-messages
- CVE-2018-1271 CVE-2018-1271 Medium FALSE Уязвимость относится к компоненте spring-web-mvc
- CVE-2018-1272 CVE-2018-1272 High TRUE
CVE-2014-3578 CVE-2014-3578 (OSSINDEX) CVE-2014-3578 Medium TRUE
SONATYPE-2015-0327 - - Low TRUE
struts2-config-browser-plugin:2.3.30 SONATYPE-2016-0104 - - Medium TRUE
spring-tx:3.0.5 - CVE-2011-2730 - High FALSE Уязвимость не относится к spring-tx
- CVE-2011-2894 - High FALSE Уязвимость не относится к spring-tx
- CVE-2013-4152 - Medium FALSE Уязвимость не относится к spring-tx
- CVE-2013-6429 - Medium FALSE Уязвимость не относится к spring-tx
- CVE-2013-6430 - Medium FALSE Уязвимость не относится к spring-tx
- CVE-2013-7315 - Medium FALSE Уязвимость не относится к spring-tx
- CVE-2014-0054 - Medium FALSE Уязвимость не относится к spring-tx
- CVE-2014-0225 - High FALSE Уязвимость не относится к spring-tx
- CVE-2014-1904 - Medium FALSE Уязвимость не относится к spring-tx
- CVE-2014-3625 - Medium FALSE Уязвимость не относится к spring-tx
- CVE-2016-9878 - High FALSE Уязвимость не относится к spring-tx
- CVE-2018-1270 - High FALSE Уязвимость не относится к spring-tx
- CVE-2018-1271 - Medium FALSE Уязвимость не относится к spring-tx
- CVE-2018-1272 - Medium FALSE Уязвимость не относится к spring-tx
struts-core:1.3.8 - CVE-2011-5057 (OSSINDEX)
Medium FASLE Уязвимость к Struts 2
- CVE-2012-0391 (OSSINDEX) CVE-2012-0391 High FALSE Уязвимость к Struts 2
- CVE-2014-0094 (OSSINDEX) CVE-2014-0094 Medium FALSE Уязвимость к Struts 2
- CVE-2014-0113 (OSSINDEX) CVE-2014-0113 High FALSE Уязвимость к Struts 2
CVE-2016-1182 3VE-2016-1182 - High TRUE
- - CVE-2011-5057 Medium FALSE Уязвимость к Struts 2
- CVE-2012-0392 (OSSINDEX) CVE-2012-0392 High FALSE Уязвимость к Struts 2
- CVE-2012-0393 (OSSINDEX) CVE-2012-0393 Medium FALSE Уязвимость к Struts 2
CVE-2015-0899 CVE-2015-0899 - High TRUE
- CVE-2012-0394 CVE-2012-0394 Medium FALSE Уязвимость к Struts 2
- CVE-2012-0838 (OSSINDEX) CVE-2012-0838 High FALSE Уязвимость к Struts 2
- CVE-2013-1965 (OSSINDEX) CVE-2013-1965 High FALSE Уязвимость к Struts 2
- CVE-2013-1966 (OSSINDEX) CVE-2013-1966 High FASLE Уязвимость к Struts 2
- CVE-2013-2115 CVE-2013-2115 High FASLE Уязвимость к Struts 2
- CVE-2013-2134 (OSSINDEX) CVE-2013-2134 High FASLE Уязвимость к Struts 2
- CVE-2013-2135 (OSSINDEX) CVE-2013-2135 High FASLE Уязвимость к Struts 2
CVE-2014-0114 CVE-2014-0114 - High TRUE
- CVE-2015-2992 CVE-2015-2992 Medium FALSE Уязвимость к Struts 2
- CVE-2016-0785 (OSSINDEX) CVE-2016-0785 High FALSE Уязвимость к Struts 2
CVE-2016-1181 CVE-2016-1181 - High TRUE
- CVE-2016-4003 (OSSINDEX) CVE-2016-4003 High FALSE Уязвимость к Struts 2
xwork-core:2.3.30 CVE-2017-9804 - - High TRUE
SONATYPE-2017-0173 - - High TRUE
CVE-2017-7672 - - High FALSE Дубль к CVE-2017-9804
SONATYPE-2016-0127 - - High TRUE
struts2-core:2.3.30 - CVE-2016-6795 CVE-2016-6795 High TRUE
- CVE-2017-9787 CVE-2017-9787 High TRUE
- CVE-2017-9791 CVE-2017-9791 High TRUE
- CVE-2017-9793 - High FALSE Дубликат к CVE-2018-1327
- CVE-2017-9804 - High TRUE
- CVE-2017-9805 CVE-2017-9805 High TRUE
CVE-2016-4003 - - Medium FALSE Применимо к Apache Struts 2.x до 2.3.28, а это версия 2.3.30. Тем не менее, исходя из описания, CVE действует при любых версиях Struts 2, если используется JRE 1.7 и меньше. Видимо нас тут решили перестраховать, но больше похоже на FALSE
- CVE-2018-1327 CVE-2018-1327 High TRUE
CVE-2017-5638 CVE-2017-5638 CVE-2017-5638 High TRUE Та самая уязвимость, которой воспользовались злоумышленники в Equifax в 2017 году
CVE-2017-12611 CVE-2017-12611 - High TRUE
CVE-2018-11776 CVE-2018-11776 CVE-2018-11776 High TRUE
struts-taglib:1.3.8 - CVE-2012-0394 - Medium FALSE Для struts2-core
- CVE-2013-2115 - High FALSE Для struts2-core
- CVE-2014-0114 - High FALSE Для commons-beanutils
- CVE-2015-0899 - High FALSE Не относится к taglib
- CVE-2015-2992 - Medium FALSE Относится к struts2-core
- CVE-2016-1181 - High FALSE Не относится к taglib
- CVE-2016-1182 - High FALSE Не относится к taglib
struts-tiles-1.3.8 - CVE-2012-0394 - Medium FALSE Для struts2-core
- CVE-2013-2115 - High FALSE Для struts2-core
- CVE-2014-0114 - High FALSE Под commons-beanutils
- CVE-2015-0899 - High FALSE Не относится к tiles
- CVE-2015-2992 - Medium FALSE Для struts2-core
- CVE-2016-1181 - High FALSE Не относится к taglib
- CVE-2016-1182 - High FALSE Не относится к taglib

Подробнее..

От Threat Modeling до безопасности AWS 50 open-source инструментов для выстраивания безопасности DevOps

14.09.2020 10:18:41 | Автор: admin

Привет, Хабр! Я консультант по информационной безопасности в Swordfish Security по части выстраивания безопасного DevOps для наших заказчиков. Я слежу за тем, как развивается тенденция развития компаний в сторону DevSecOps в мире, пытаюсь транслировать самые интересные практики в русскоговорящее сообщество и помогаю выстраивать этот процесс с нашей командой у заказчиков. За последние 2 года тема DevSecOps стала привлекать все больше внимания. Новые инструменты не успевают стать частью быстро растущего набора практик, из-за чего у меня появилось желание поставить некоторую контрольную точку в виде списка инструментов. Отправной точкой стал выход статьи коллег из Mail.ru, где отдельно был выделен раздел по безопасности Kubernetes. Я решил расширить этот список, охватив другие этапы жизненного цикла SDLC и приведя пару новых инструментов.

Под практикой подразумевается набор мер, который может быть встроен в один из этапов SDLC/DevOps (Threat modeling, SAST, DAST, SCA, Docker image scanning, Kubernetes scanning, AWS Audit и так далее).

Оглавление

Одно из видений практик DevSecOps. Источник: https://holisticsecurity.io/2020/02/10/security-along-the-container-based-sdlcОдно из видений практик DevSecOps. Источник: https://holisticsecurity.io/2020/02/10/security-along-the-container-based-sdlc

Dev

Threat Modeling

Моделирование угроз в контексте Secure Development Lifecycle представляет из себя процесс анализа архитектуры ПО на предмет наличия в ней потенциальных уязвимостей и небезопасных технологий. Чтобы сократить расходы на добавление дополнительного функционала с точки зрения безопасности, решением может являться внедрение процесса проверок ИБ еще на этапе проектирования архитектуры. На этом же этапе формируются требования со стороны специалистов по безопасности приложений, которые в дальнейшем пойдут в backlog. Подобный подход прибегается, на самом деле, во всех практиках DevSecOps и получил устойчивое выражение Shift security to the left.

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

OWASP Threat Dragon

Ссылка на OWASP Threat Dragon

Довольно простой инструмент для самостоятельного моделирования угроз. Пользователь отрисовывает архитектуру ПО, указывая на ней угрозы, которые могут следовать по методологии STRIDE. Никакой автоматизации, но в классическом варианте, когда процессы отлажены, может быть полезно. Это инструмент в частности используется для моделирования угроз в GitHub.

Пример диаграммы Threat DragonПример диаграммы Threat Dragon

Pytm

Ссылка на Pytm

Pytm - фреймворк на Python для создания диаграмм потоков данных и списка угроз системы.

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

Результат Pytm в виде графика Результат Pytm в виде графика

Materialize threats tool

Ссылка на Materialize threats tool

Materialize-threats - фреймворк на Python, который позволяет конвертировать схемы архитектуры ПО из сервиса draw.io в графы, сохранить их в базу и в дальнейшем работать с утверждениями относительно этих графов при помощи SQL запросов. Помимо этого инструмент умеет формировать тесты на Gherkin.

Это любопытный open-source инструмент, который хорошо описывает то, куда двигаются современные Enterpise-решения по моделированию угроз вроде Irius Risks.

Сценарий работы с ним следующий:

  1. Создание диаграммы взаимодействия компонентов в .drawio, согласно вашему data flow

  2. Выделение доверенных зон на диаграмме, согласно Rapid Threat Model Prototyping methodology(в readme есть пояснение)

  3. Сохранение файла .drawio

  4. Запуск materialize.py с импортом файла .drawio

  5. Получение сценария реализации угроз в формате Gherkin.

Пример архитектуры в draw.io в качестве входных данных для Materialize threats tool Пример архитектуры в draw.io в качестве входных данных для Materialize threats tool Результат работы Materialize threats tool Результат работы Materialize threats tool

Не будем долго останавливаться на других инструментах ибо принцип работы везде похожий.

Вот еще несколько open-source инструментов по части моделирования угроз:

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

Статический анализ приложений на уязвимости (SAST):

Переходим к этапу тестирования, а именно статическому анализу кода . Анализаторов кода существует огромное количество. Open-source инструменты, в свою очередь, выделяются тем, что они написаны под какой-то конкретный язык. Большое количество инструментов можно найти в следующих подборках:

Но есть и несколько довольно любопытных инструментов, которые могут быть применены универсально.

Salus

Ссылка на Salus

Образ контейнера, в который помещено сразу несколько статических анализаторов, вроде Bandit, Gosec, Brakeman, а также анализаторы open-source компонентов (Ruby,Node.js, Python,Go). Запускается это следующим образом:

# Navigate to the root directory of the project you want to run Salus on$ cd /path/to/repo# Run the following line while in the root directory (No edits necessary)$ docker run --rm -t -v $(pwd):/home/repo coinbase/salus

На выходе получаем JSON/YAML отчет. На GitHub также можно найти описание встраивания в CircleCI.

ShiftLeft Scan

Ссылка на ShiftLeft Scan

Инструмент работает по аналогии с Salus, но с поддержкой большего количества статических анализаторов. В репо можно посмотреть те статические анализаторы, которые были помещены в docker образ (gosec, find-sec-bugs, psalm, bandit, ). В образ Docker поместили даже анализаторы terraform, bash, kubernetes манифестов.

Пример запуска статического анализа Python проекта:

$ docker run --rm -e "WORKSPACE=${PWD}" -v "$PWD:/app" shiftleft/sast-scan scan --src /app --type python

Более того, к инструменту есть интеграция с IDE.

Пример интеграции с VS Code для ShiftLeftПример интеграции с VS Code для ShiftLeft

GitLab SAST

Ссылка на описание SAST в GitLab

Gitlab является довольно популярной DevOps платформой, но что еще в ней есть, так это бесплатный набор разных open-source SAST, которые можно подключить из коробки в пайплайн. В Gitlab также есть возможность встроить SCA, поиск секретов, fuzzing и другие практики DevSecOps, но централизованное управление всеми средствами будет доступно только в Gold-версии.

Пример встраивания SAST в пайплайн GitLab.Пример встраивания SAST в пайплайн GitLab.

LGTM

Ссылка на LGTM

LGTM - облачная платформа для сканирования кода от компании Semmle, которая в конце того года стала частью GitHub. Semmle также являются автором CodeQL, применение которого было анонсировано GitHub на своей онлайн-конференции Satellite.

Пример отчета LGTMПример отчета LGTM

Semgrep

Ссылка на облачную версию Semgrep

Уникальный проект, про который хотелось бы написать отдельную статью. По сути это не столько статический анализатор кода на наличие уязвимостей, сколько фреймворк, под капотом которого находится AST и Data flow, который можно использовать по разным назначениям. Например, можно сформировать следующий запрос:

$ semgrep --config=&lt;path/to/config> path/to/src

Конфигурационный файл для semgrep пусть будет следующим:

rules:- id: user-eval  patterns:  - pattern-inside: |      def $F(...):        ...  - pattern-either:    - pattern: eval(..., request.$W.get(...), ...)    - pattern: |        $V = request.$W.get(...)        ...        eval(..., $V, ...)    - pattern: eval(..., request.$W(...), ...)    - pattern: |        $V = request.$W(...)        ...        eval(..., $V, ...)    - pattern: eval(..., request.$W[...], ...)    - pattern: |        $V = request.$W[...]        ...        eval(..., $V, ...)

В результате Semgrep будет находить инъекции вроде тех, что отображены ниже на скриншоте (желтым отмечены те строки, которые semgrep посчитал уязвимыми):

Результат выполнения поиска Semgrep из облачной версии инструментаРезультат выполнения поиска Semgrep из облачной версии инструмента

Примечание. На мой взгляд, большой проблемой во многих open-source инструментах, особенно в SAST, так это отсутствие унификации по части вывода результатов. Очень малая часть этих инструментов предоставляет CWE к найденным срабатываниям, из-за чего возникают проблемы на уровне менеджмента уязвимостей. На текущий момент все коммерческие решения, которые я знаю, приводят результат найденных уязвимостей к CWE и CVE.

Проверка open-source компонент - SCA

Наряду с тем кодом, разработка которого выполняется внутри команды, необходимо также проверить open-source, который подключается к проекту. Отсутствие процесса анализа сторонних компонент на наличие уязвимостей может существенно повлиять на безопасность продукта (как например, это случилось с компанией Equifax). Принципы работы, сравнение популярных инструментов SCA я приводил в отдельной статье, а здесь мы поговорим о том, какие существуют инструменты.

Dependency Check

Ссылка на Dependency Check

Dependency Check - одно из самых популярных open-source решений от OWASP для проверки сторонних компонентов . Существует большое количество готовых интеграций, способов встраивания в пайплайн, но у инструмента есть куда развиваться в сторону качества. Рекомендуется к внедрению для компаний, где процессы Secure SDLC находятся на начальных этапах и у специалистов со стороны ИБ есть время для разбора ложных срабатываний. У Dependency Check нет единой платформы, в которой можно отслеживать результаты в ретроспективе, поэтому, если процессы менеджмента уязвимостей в организации не выстроены, стоит обратить внимание на Dependency Track.

# Dependency Check Maven Plugin example$ mvn org.owasp:dependency-check-maven:check
Скриншот из HTML-отчета Dependency CheckСкриншот из HTML-отчета Dependency Check

Dependency Track

Ссылка на сайте Dependency Track

Dependency Track - второе по популярности решение от OWASP, которое представляет из себя веб-платформу, принимающую на вход Software bill of materials (SBOM) от другого инструмента CycloneDx. Dependency Track исследует BOM, после чего обращается в общедоступные базы данных уязвимостей, например, NVD. Инструмент имеет также возможность интегрироваться со Slack, Microsoft Teams, сканировать репозитории артефактов и проверять сторонние компоненты на лицензионную чистоту.

# CycloneDx Maven Plugin example to make SBOM$ mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom
Скриншот из веб-интерфейса Dependency Track.Скриншот из веб-интерфейса Dependency Track.

Snyk Open-source

Ссылка на официальном сайте Snyk Open-source

Компания Snyk кроме того, что развивает свою коммерческую платформу для сканирования open-source компонентов в проектах, также предоставляет бесплатную версию в виде SaaS-решения. Проекты можно подгружать как через репозиторий (GitHub, Bitbucket), так и через CLI.

Скриншот из SaaS-платформы Snyk open-source для Python-проектаСкриншот из SaaS-платформы Snyk open-source для Python-проекта

Как может выглядеть сканирование snyk для npm:

$ npm install -g snyk$ snyk auth$ snyk monitor

Sonatype Open-source

Помимо NVD (основного источника информации об уязвимостях для большинства решений) существует база Sonatype OSS, поддерживаемая компанией Sonatype, у которой также есть коммерческое решение Nexus IQ. Мы, в свою очередь, взяли на вооружение Nexus IQ как основной инструмент SCA для наших заказчиков. Sonatype OSS - база данных уязвимостей, которая может быть подключена инструментами Dependency Check и Dependency Track. Кроме того, Sonatype поддерживает следующие open-source инструменты SCA, которые могут быть использованы для сканирования зависимостей и берут данные из Sonatype OSS:

Скриншот из отчета Nexus Vulnerability ScannerСкриншот из отчета Nexus Vulnerability Scanner

Другие материалы по SCA:

Поиск секретов

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

git-secrets

Ссылка на официальном сайте git-secrets

$ git secrets --scan /path/to/file

Gitrob

Ссылка на gitrob

$ export GITROB_ACCESS_TOKEN=&lt;TOKEN>$ gitrob &lt;target>

Gitleaks

Ссылка на gitleaks

$ gitleaks --repo-path=&lt;path to repo>$ gitleaks --repo=&lt;url of github>

Также есть в виде Github-action.

TruffleHog

Ссылка на TruffleHog

$ trufflehog [-h] [--json] [--regex] [--rules RULES]                  [--entropy DO_ENTROPY] [--since_commit SINCE_COMMIT]                  [--max_depth MAX_DEPTH]                  git_url

TruffleHog - самый известный инструмент в сообществе, осуществляющий поиск секретов как по регулярным выражениям, так и прибегая к оценки энтропии методом Шеннона.

GitGuardian

Ссылка на GitGuardian

SaaS платформа для поиска секретов. Есть также коммерческая on-prem версия. В России не продается.

Скриншот из GitGuardianСкриншот из GitGuardian

Примечание. Для хранения секретов и сокрытия их в исходном коде и конфигурационных файлах необходимо использовать решения класса Password Vault (HashiCorp Vault, conjur, )

Динамический анализ приложений на уязвимости (DAST):

Arachni

Ссылка на Arachni

Одно из моих любимых open-source решений, в первую очередь за свою точность. Есть возможность развертывания в виде Docker-контейнера, CLI и веб-интерфейса. Жаль, что решение перестало поддерживаться разработчиками. Результаты выводятся в CWE-формате.

Скриншот из веб-интерфейса ArachniСкриншот из веб-интерфейса Arachni

Способ сканирования через Docker:

$ docker run -d \    -p 222:22 \    -p 7331:7331 \    -p 9292:9292 \    --name arachni \    arachni/arachni:latest

После развертывания контейнера, запуск сканирования и выгрузка отчетов происходит через REST API по порту 7331 в виде json.

OWASP ZAP

Ссылка на OWASP ZAP

Одно из самых популярных open-source решений, которое может быть встроено в CI/CD. Имеет свой GUI, может быть развернуто в виде CLI или docker-контейнера. Также есть режим работы в виде прокси.

# OWASP ZAP as a daemondocker run -p 8090:8090 -i owasp/zap2docker-stable zap.sh -daemon -port 8090 -host 0.0.0.0# OWASP ZAP runs for 1  minute and then waits for the passive scanning to complete before reporting the results.docker run -t owasp/zap2docker-weekly zap-baseline.py -t https://www.example.com
Скриншот из GUI OWASP ZAPСкриншот из GUI OWASP ZAP

Есть даже кастомные сценарии развертывания в виде Kubernetes-оператора.

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

w3af

Ссылка на w3af

Несмотря на то, что инструмент давно не обновляется и не обозревается аналитиками (например, наиболее свежий обзор в журнале Хакер датируется 2012 годом (http://personeltest.ru/aways/xakep.ru/2012/11/09/w3af-pentest/)), тем не менее есть официальный docker-контейнер и инструкции по встраиванию сканера в CI/CD

Вот например, автор встроил разные open-source решения по безопасности в пайплайн Jenkins на AWS, включая w3af.

Пример сканирования через docker:

$ git clone https://github.com/andresriancho/w3af.git$ cd w3af/extras/docker/scripts/$ sudo ./w3af_console_docker
Скриншот w3af. Источник: https://xakep.ru/2012/11/09/w3af-pentest/Скриншот w3af. Источник: https://xakep.ru/2012/11/09/w3af-pentest/

Примечание. Динамический анализ бывает не только для веб-приложений. Более полный список можно увидеть здесь.

Стоит отметить про отдельный класс решений для динамического сканирования мобильных приложений, open-source инструментов и enterprise, которых весьма мало. Мы в частности занимаемся разработкой собственного инструмента DAST для мобильных приложений.

Тестирование по принципам Behaviour Driven Development

Behavioral Driven Development (BDD) (или разработка через поведение)- подход в разработке ПО, который произошел от Test Driven Development (TDD) (разработка через тестирование). Несмотря на том, что эти подходы, как итог, стали применяться для разных целей и использовать разные инструменты, их применение можно найти и в сфере безопасности. Основная концепция BDD в описании пользовательских сценариев тестирования с помощью человеко-читаемоего языка Gherkin.

Посмотрим, как это выглядит сразу на примере инструментов.

Gauntlt

Ссылка на Gauntlt

Guantlt - фреймворк, использующий концепцию Behavioral Driven Development. Он автоматизировать сканирование с помощью различных инструментов и позволяет описать Arachni, nmap, sslyze, sqlmap и другие инструменты на языке Gherkin.

# nmap-simple.attackFeature: simple nmap attack to check for open ports  Background:    Given "nmap" is installed    And the following profile:      | name     | value       |      | hostname | example.com |  Scenario: Check standard web ports    When I launch an "nmap" attack with:      """      nmap -F <hostname>      """    Then the output should match /80.tcp\s+open/    Then the output should not match:      """      25\/tcp\s+open      """

Таким образом, Guantlt может стать мостиком между командами разработки, безопасности и менеджмента.

Примечание. Аналогом Guantlt является BDD-Security, который в поддерживаемых инструментах имеет также OWASP ZAP, Tenable Nessus Scanner.

Сканирование образов Docker:

В силу того, что команды разработки все чаще стали прибегать к варианту развертывания через Docker (да и в принципе Docker стал важной частью DevOps), нельзя не сказать про сканеры Docker-образов как отдельный класс решений.

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

Пройдемся по некоторым из инструментов.

Clair

Ссылка на Clair

Инструмент для проверки слоев образа на общедоступные CVE уязвимости. У инструмента отсутствует из коробки UI для работы, поэтому необходимо подключать сторонние инструменты вроде Klar.

$ docker run -d -e POSTGRES_PASSWORD="" -p 5432:5432 postgres:9.6$ docker run --net=host -d -p 6060-6061:6060-6061 -v $PWD/clair_config:/config quay.io/coreos/clair:latest -config=/config/config.yaml

Klar

Ссылка на Klar

Утилита для взаимодействия с API Clair.

$ mkdir klar &amp;&amp; cd klar &amp;&amp; wget https://github.com/optiopay/klar/releases/download/v2.4.0/klar-2.4.0-linux-amd64 -O klar &amp;&amp; chmod +x klar$ CLAIR_ADDR=http: //localhost:6060 CLAIR_THRESHOLD=10 ./klar &lt;docker image>

Trivy

Ссылка на Trivy

Trivy находит уязвимости сборок ОС (поддерживаются Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) и проблемы в зависимостях (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock) В отличие от Clair умеет сканировать как в репозитории, так и локально, или на основании переданного .tar файла с Docker образом.

# Download bin$ wget https: //github.com/knqyf263/trivy/releases/download/v0.1.3/trivy_0.1.3_Linux-64bit.deb$ dpkg -i ./trivy_0. 1 .3_Linux-64bit.deb# Scan image$ trivy bkimminich/juice-shop# Scan image in tar$ trivy -i ./ my_saved_docker_image.tar
Результат сканирования TrivyРезультат сканирования Trivy

Anchore

Ссылка на Anchore

Популярный инструмент для сканирования образов Docker. Есть возможность работы через REST API или CLI.

$ anchore-cli --u admin --p foobar image add httpd:latest$ anchore-cli --u admin --p foobar image vuln httpd:latest all
Результат сканирования Anchore. Источник: https://swordfishsecurity.ru/blog/obzor-utilit-bezopasnosti-dockerРезультат сканирования Anchore. Источник: https://swordfishsecurity.ru/blog/obzor-utilit-bezopasnosti-docker

AquaMicroscanner

Ссылка на AquaMicroscanner

Инструмент от Aqua Security, который развивается параллельно вместе с Trivy.

$ docker run --rm -it aquasec/microscanner --register &lt;email address>
ADD https://get.aquasec.com/microscanner /RUN chmod +x /microscannerRUN /microscanner &lt;TOKEN> [--continue-on-failure]

Примечание. Сравнение инструментов по сканированию образов на общедоступные CVE можно почитать здесь:

Dagda

Ссылка на Dagda

Dagda выделяется тем, что имеет под капотом Dependency Check, Retire.js и ClamAV для поиска вредоносных программ.

$ export DAGDA_HOST='127.0.0.1'$ export DAGDA_PORT=5000$ python3 dagda.py vuln --init$ python3 dagda.py check --docker_image jboss/wildfly

Docker bench

Ссылка на Docker Bench

Docker bench - инструмент для compliance-проверок как образов, так и контейнеров и хостов.
Основной набор проверок строится на базе документа CIS Benchmarks для Docker.

$ docker run -it --net host --pid host --userns host --cap-add audit_control \      -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \      -v /etc:/etc:ro \      -v /usr/bin/containerd:/usr/bin/containerd:ro \      -v /usr/bin/runc:/usr/bin/runc:ro \      -v /usr/lib/systemd:/usr/lib/systemd:ro \      -v /var/lib:/var/lib:ro \      -v /var/run/docker.sock:/var/run/docker.sock:ro \      --label docker_bench_security \      docker/docker-bench-security
Результат сканирования Docker benchРезультат сканирования Docker bench

Dockle

Ссылка на Dockle

Инструмент для выполнения compliance-проверок, в том числе, выходящих за рамки CIS.

$ docker run --rm goodwithtech/dockle:v${DOCKLE_LATEST} [YOUR_IMAGE_NAME]
Результат работы DockleРезультат работы Dockle

Ops:

Kubernetes Security

Переходим на этап Deploy. В случае с Kubernetes, помимо образов Docker, необходимо также проверять настройки Kubernetes в силу того, что Kubernetes по умолчанию развертывается в менее безопасной конфигурации для большего удобства начинающих пользователей.

Дополнительный материал для расширения подборки:

My Arsenal of Cloud Native (Security) Tools by MARCO LANCINI

Kube-bench

Ссылка на Kube-bench

Еще один (и не последний) инструмент от компании Aqua Security. Инструмент выполняет проверки CIS Kubernetes Benchmark для развернутых рабочих нагрузок Kubernetes (в том числе GKE, EKS and AKS)

Для разных сценариев желателен разный вариант запуска команд:

# Run inside a container$ docker run --rm --pid=host                      \   -v $(which kubectl):/usr/bin/kubectl         \   -t aquasec/kube-bench:latest <master|node># Run in a cluster - on master node$ kubectl run                                          \      --rm                                             \      -it                                              \      kube-bench-master                                \      --image=aquasec/kube-bench:latest                \      --restart=Never                                  \      --overrides="{ \"apiVersion\": \"v1\",           \          \"spec\": { \"hostPID\": true,               \          \"nodeSelector\":                            \          { \"kubernetes.io/role\": \"master\" },      \          \"tolerations\": [ {                         \          \"key\": \"node-role.kubernetes.io/master\", \          \"operator\": \"Exists\",                    \          \"effect\": \"NoSchedule\" }]}}"             \      -- master                                        \      --version 1.8# Run in a cluster - on worker nodes$ kubectl run                                \      --rm                                   \      -it                                    \      kube-bench-node                        \      --image=aquasec/kube-bench:latest      \      --restart=Never                        \      --overrides="{ \"apiVersion\": \"v1\", \          \"spec\": { \"hostPID\": true } }" \      -- node                                \      --version 1.8

Kubernetes Auto Analyzer

Ссылка на Kubernetes Auto Analyzer

Инструмент работает по тому же принципу, что и Kube-bench, но в отличие от него перестал поддерживаться. Сами авторы инструмента предлагают продолжить пользоваться Kube-bench от Aqua Security.

# Put the config file in a directory and mount it to the /data folder$ docker run --rm                               \      -v /data:/data raesene/kube_auto_analyzer \      -c /data/admin.conf -r testdock# Provide a KUBECONFIG file to identify and authenticate the session$ kubeautoanalyzer -c <kubeconfig_file_name> -r <report_name> --html
Пример отчета Kuberntes-Auto-AnalyzerПример отчета Kuberntes-Auto-Analyzer

Kube-hunter

Ссылка на Kube-hunter

Инструмент для имитации тестирования на проникновения Kubernetes. Может быть запущен на сервере кластера, внутри контейнера или на удаленном компьютере с указанием IP-адреса / доменного имени кластера Kubernetes.

# Run from docker$ docker run -it --rm --network host aquasec/kube-hunter# Run from kubectl$ kubectl run --rm -it                        \     kube-hunter                            \     --image=aquasec/kube-hunter            \     --restart=Never                        \     --overrides="{ \"apiVersion\": \"v1\", \     \"spec\": { \"hostNetwork\": true } }"

KubiScan

Ссылка на KubiScan

Инструмент для проверки выданных разрешений RBAC-модели Kubernetes.

Кстати, проверке выданных разрешений посвящена отдельная неплохая статья на сайте CyberARK.

# Run from MASTER node$ docker run -it --rm -e CONF_PATH=~/.kube/config -v /:/tmp cyberark/kubiscan [CMD]# Search for pods with privileged accounts$ kubiscan -rp# Show all risky subjects (users, service accounts, groups)$ kubiscan -rs# Show all the rules a service account has$ kubiscan -aars "SANAME" -ns "default" -k "ServiceAccount"# List service account RoleBindings$ kubiscan -aarbs "SANAME" -ns "default" -k "ServiceAccount"

Krane

Ссылка на Krane

Инструмент, выполняющий статический анализ RBAC за счет индексации объектов RBAC в RedisGraph. Управление рисками RBAC происходит через настройку политик. Krane может работать как CLI, docker-контейнер или автономная служба для непрерывного анализа, а также быть встроенным в CI/CD.

Пример графа Krane.Пример графа Krane.

Statboard

Ссылка на Starboard

Инструмент, позволяющий нативно интегрировать инструменты безопасности в среду Kubernetes благодаря CustomResourceDefinitions (CRDs) для работы с такими инструментами как trivy, kube-bench, kube-hunter. Starboard предоставляет также kubectl-совместимый инструмент командной строки и плагин Octant, который делает отчеты о безопасности доступными через знакомые инструменты Kubernetes.

$ starboard find vulnerabilities deployment/nginx --namespace dev$ starboard get vulnerabilities deployment/nginx \  --namespace dev \  --output yaml
Результат работы Starboard через OctantРезультат работы Starboard через Octant

Kubeaudit

Ссылка на Kubeaudit

Еще один инструмент, выполняющий проверки Kubernetes.

# Run from kubectl (as plugin)$ kubectl audit all

Kubesec

Ссылка на Kubesec

Последний легковесный инструмент для проверки Kubernetes в этой подборке.

$ krew install kubesec-scan$ kubectl kubesec-scan pod <podname>

Deepfence Runtime Threat Mapper

Ссылка на Deepfence Runtime Threat Mapper

Бесплатная community-версия комплексного решения по защите облачных нагрузок. Платформа отображает рабочие нагрузки на графе, ищет аномалии в поведении с помощью агентов сканирования, интегрируется с CI/CD для сканирования образов, а также выполняет поиск уязвимостей образов в заданном Registry. Также есть интеграция с SIEM, Slack, Jira, Amazon S3 (неполный список интеграций).

Скриншот из Deepfence Runtime Threat MapperСкриншот из Deepfence Runtime Threat Mapper

Sysdig Falco

Ссылка на Sysdig Falco

Бесплатная версия решения для защиты в режиме run-time от Sysdig, хорошо себя зарекомендовавшая в сообществе.

Vulnerability Management

Можно выполнять огромное количество различных сканирований инструментами SAST, DAST, SCA, анализаторами образов Docker и конфигурации Kubernetes, но без правильно построенного процесса управления выявленными уязвимостями и распределения ответственных процесс устранения выявленных дефектов может очень сильно затянуться. Решения класса Vulnerability Management призваны помочь в этом вопросе. Как правило, это единая точка входа всех выявленных уязвимостей посредством взаимодействия через API или при помощи веб-интерфейса с целью дальнейшей визуализации и экспорта структурированной информации в дефект-трекинг. Мы в своих практиках используем коммерческое решение собственной разработки AppSec.Hub, которое помимо управления уязвимостями, умеет также создавать и экспортировать готовые DevSecOps-пайплайны в CI/CD системы. Но в этой статье мы коснемся только open-source решений.

DefectDojo

Ссылка на DefectDojo

Решение для управление уязвимостями от OWASP. Есть много интеграций (22+) как с open-source сканерами (ZAP, Trivy, nmap, Dependency Check), так и с enterprise (Veracode, Checkmarx, Twistlock). Как правило, имеет некоторые сложности при интеграции с API.

Вот здесь можно увидеть пример скрипта для интеграции.

Скриншот DefectDojo.Скриншот DefectDojo.

Secure code Box

Ссылка на Secure code box

Open-source фреймворк, объединяющий несколько бесплатных инструментов сканирования (ZAP, NMAP, Nikto, Arachni), собранных вместе в docker-compose в связке с Kibana и Elasticsearch. В отличие от того же DefectDojo, здесь все инструменты развертываются вместе с решением, и отчеты о результатах сканирования подтягиваются самостоятельно (не нужно писать скрипты для автоматической отправки issue в сборщик). Также можно запускать сканирование всех заявленных инструментов из UI. На текущий момент инструменты направлены исключительно на тестирование веб-приложений.

Несмотря на кажущуюся простоту развертывания и работы, разработчики заявляют, что это не one-button-click-solution и требуется глубокое понимание для настройки сканеров.

Скрншот графиков Kibana из Secure Code Box.Скрншот графиков Kibana из Secure Code Box.

Archery

Ссылка на Archery

Еще одна open-source система управления уязвимостями. Есть поддержка Acuntetix, Nessus, Burp, Netsparker, WebInspect. В отличие от DefectDojo, о котором я упоминал ранее, решение позволяет запускать из консоли сканирование ZAP, Burp и OpenVAS. Из интересного то, что есть обработчик false positive. Ну и конечно же интеграция с CI/CD.

Скриншот из ArcheryСкриншот из Archery

Еще материал по vulnerability management:

Public Cloud Security

Говоря про безопасный DevOps нельзя не сказать про безопасность облачных провайдеров (AWS, GCP, Azure, Oracle) в силу активного перехода из on-prem в облака.

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

Сервисы безопасности от AWS. Источник :https://cloudseclist.com/issues/issue-42/Сервисы безопасности от AWS. Источник :https://cloudseclist.com/issues/issue-42/

AWS-inventor

Ссылка на AWS-inventor

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

$ python aws_inventory.py# Select the generated JSON file when prompted$ firefox gui/dist/index.html
Результат инвентаризации AWS-inventorРезультат инвентаризации AWS-inventor

Aws-public-ips

Ссылка на AWS-puclic-ips

Инструмент для получении информации об общедоступных ресурсах AWS в виде ip-адресов.

# Uses default ~/.aws/credentials$ aws_public_ips -f json -s apigateway,cloudfront,ec2, \    elasticsearch,elb,elbv2,lightsail,rds,redshift# With a custom profile$ AWS_PROFILE=production aws_public_ips ...

CloudSploit

Ссылка на CloudSploit

Инструмент для compliance-проверок публичных облаков AWS, GCP, Azure, OCI. В частности, можно провести проверку на CIS и PCI DSS.

# Edit the&nbsp;index.js&nbsp;file with your AWS key and secret# Run a standard scan$ node index.js# Run a compliance scan$ node index.js --compliance=hipaa

AWS Security Benchmark

Ссылка на AWS Security Benchmark

Отдельный инструмент для проверки AWS на соответствие CIS Amazon Web Services Foundations Benchmark 1.1.

$ python aws-cis-foundation-benchmark-checklist.py

S3 Scan

Ссылка на S3 Scan

Инструмент, формирующий отчет обо всех S3-корзинах и установленных для них ролях.

$ python s3scan.py [-f &lt;format>] [-p &lt;profile>]

Примечание. Наверное, самая большая подборка инструментов по AWS Security:

My-arsenal-of-aws-security-tools

G-Scout

Ссылка на G-Scout

Инструмент, формирующий отчет о проблемах с безопасностью GCP.

# Permissions required on the projects: Viewer, Security Reviewer, Stackdriver Account Viewer$ python gscout.py --project-id <projectID>

ScoutSuite

Ссылка для ScoutSuite

Популярный инструмент для проведения аудита безопасности публичных облаков GCP, AWS, Oracle, Azure.

# GCP example# Using an user account$ python Scout.py --provider gcp --user-account --project-id <projectID>#Using a service account$ python Scout.py --provider gcp                                     \                  --service-account --key-file service_account.json  \                  --project-id <projectID>
Пример отчета ScoutSuiteПример отчета ScoutSuite

И это еще не все?

Подборку продолжать можно еще долго, но я постарался привести все, что может стать отправной точкой в процессе выстраивания безопасности DevOps/SDLC. Тем не менее, это далеко не все практики. Я не коснулся также этапов фаззинга, управления секретами и процесса проверки манифестов IaC. И разумеется, правильно построенный процесс разработки не может существовать без организационных мер и налаженных отношений между командами разработки и безопасности. Здесь я могу порекомендовать познакомиться с моделями оценки BSIMM и OWASP SAMM.

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

RASP - практика, при которой инструмент безопасности интегрируется напрямую с сервером, отслеживая его работу (обращения к базе данных, файловые операции, сетевые запросы и тд.). Часто к этой практике относят инструменты класса Container Run-time Security (например Sysdig Falco). Вот также RASP для отслеживания работы веб-приложений:

IAST - практика, совмещающая принципы работы SAST и DAST:

Fuzzing - практика тестирования приложения, при которой на вход программе подаются данные, которые могут привести к неопределенному поведению :

IaC Security - практика тестирования декларативного описания инфраструктуры через конфигурационные файлы на соответствие требования безопасности:

  • Cfn Nag-Сканер AWS CloudFormation шаблонов на небезопасную конфигурацию

  • Checkov-Сканер Terraform, AWS CloudFormation и Kubernetes шаблонов на небезопасную конфигурацию

  • Terrascan-Сканер Terraform шаблонов на соответствие лучшим практикам безопасности

  • Tfsec-Сканер Terraform шаблонов на неправильную конфигурацию и несоответствие лучшим практикам безопасности AWS, Azure и GCP.

  • Kubernetes YAML validating:

Compliance-as-code - практика представления требований безопасности через декларативное описание в виде кода с целью дальнейшей непрерывной оценки на соответствие:

Security Chaos Engineering - молодая практика, основанная на нескольких принципах: определение "стабильного" состояния, создание гипотезы о последующем состоянии, введение переменных, осуществление попыток "сломать" гипотезу. После серии тестов инфраструктура оценивается на предмет доступности, безопасности и производительности. Как итог цель всего этого - получить систему, способную выдерживать экстремальные условия. Security Chaos Engineering отличается от классического Chaos Engineering лишь гипотезами, касающимися безопасности. Тесты могут состоять, например, из отключения правил Security Groups, изменения файлов случайным образом, прослушивания портов, внедрения вредоносного трафика в VPC, случайного "убийства" процессов. При этом все это должно быть автоматизированно, а состояния системы должны непрерывно отслеживаться. Примеры инструментов:

Каналы и чаты по DevSecOps и безопасности приложений:

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru