🛠 Grype как SCA для артефактов

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

Grype работает на уровне артефактов, а не исходного кода и сканирует программные пакеты.

Поддерживает Python, JavaScript (NPM, Yarn), Java, Ruby, Golang, PHP, Rust, .NET. Образы Docker, OCI, Singularity (SIF).

Тип лицензии: Apache 2.0
Форматы отчетов: JSON, SARIF, CycloneDX

Grype используется в связке с Syft

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

Применение

curl -sSfL https://get.anchore.io/grype | sh -s -- -b /usr/local/bin # Разворачивание
grype <image:tag> # Сканирование контейнерного образа
grype <image> --scope all-layers # Сканирование с учетом слоев образа
grype dir:path/to/yourproject # Сканирование директории
grype sbom:./sbom.json # Сканирование с использованием SBOM, созданного Syft
grype <image> -o sarif > results.sarif # Сканирование с выводом в SARIF
grype <image> -o json > results.json # Сканирование с выводом в JSON
grype --add-cpes-if-none --distro alpine:3.10 sbom:./sbom.json # Генерация CPE и указание дистрибутива

docker run --rm \ # Запуск сканирования docker
  -v /var/run/docker.sock:/var/run/docker.sock \
  anchore/grype:latest \
  <image:tag>

Gitlab CI

stages:
  - security
 
Syft:
  stage: security
  image: nixos/nix:latest
  script:
    - nix-shell -p syft --run "syft ${DOCKER_IMAGE}:latest -o cyclonedx-json=sbom.json"
  artifacts:
    paths:
      - sbom.json
 
Grype:
  stage: security
  image: nixos/nix:latest
  needs: ["Syft"]
  script:
    - nix-shell -p grype --run "grype --fail-on high sbom:sbom.json"

Jenkins

pipeline {
  agent any
  stages {
    stage('Grype Scan') {
      steps {
        sh '''
          docker run --rm --volume $(pwd):/tmp/results anchore/grype:latest \
          your-image:tag -o json > /tmp/results/grype_report.json
        '''
      }
    }
  }
  post {
    always {
      archiveArtifacts artifacts: 'grype_report.json'
    }
  }
}

Итого:

- локально разработчиком можно использовать для проверки образов перед их отправкой в registry
- имеет интеграции: SARIF, JSON в GitLab Vulnerability Report, DefectDojo, Jira и т.д.
- может сканировать образы контейнеров, файловые системы, docker save и SBOM
- помимо стандартной Severity CVSS, Grype использует EPSS - вероятность эксплуатации и индикатор KEV, чтобы помочь расставить приоритеты
- достаточно часто покрывает false positive, но после исключений срабатывания более точечные если настроить файл .grype.yaml для подавления не влияющих на конкретный проект уязвимостей
- подходит с лету для проектов с Docker-образами и/ или OCI-артефактами
- охватывает и ОС, и языковые пакеты
- политики можно настраивать с помощью флага --fail-on, указывая минимальный уровень Severity, при котором пайплайн должен быть остановлен
- результаты по умолчанию сортируются по Risk Score, но можно изменить сортировку с помощью --sort-by, как пример, по severity, epss, package

#toolchain #containersecurity #sca #sbom

🤔 Терминология CyberDefend

Салют, начнем рассматривать базу и как работает бизнес в рамках условий рисков ИБ.

#term #pmcases #riskanalys

🤔 Терминология Malicious

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

#term #pmcases

🤔 Терминология Security Champion

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

#term #pmcases

🤔 Терминология Access Control

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

А я плавно вкатываюсь обратно и готовлю классный контент для тебя 🙏

#term #pmcases

🛠 Практики DevSecOps для Android

Салют,
Во-первых у нас с тобой классная стата роста, а именно нас уже 200 подписчиков. Я очень рад этому. Спасибо тебе, что отслеживаешь материалы в канале 🙏

Во-вторых, сегодня я хочу поделиться практическим опытом работы с платформой Android и практик DevSecOps для нее.

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

Практики для Andriod

- Следует исключать возможность хранения конфиденциальной информации во внешних хранилищах: /sdcard, /mnt/sdcard и тд, так как она может быть изменена или прочитана другим приложением, включая внешнее устройство

- При использовании класса ContentProvider должен быть реализован механизм контроля доступа

- Если обмен данными с другими приложениями не требуется, то следует объявить android:exported=”false” в файле манифеста

- export для компонента должен быть помечен как false в файле манифеста, включая ограничение доступа к нему

- Разрешение для ответа вызывающему приложению следует реализовать с использованием методов Context.checkCallingPermission() и Context.enforceCallingPermission()

- Любой URL, полученный через intent, вне доверенной зоны должен быть проверен перед его отображением в WebView

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

-- вместо явных intent, следует использовать указание на конкретный компонент, используя setComponent(ComponentName или класс setClass(Context, Class)
-- ограничение трансляции одним приложением с помощью параметра Intent.setPackage() и процессом через Context.sendBroadcast(Intent)
-- после отладки атрибуту android:debuggable должно быть присвоено значение false, чтобы исключить возможность отладки приложения пользователем
-- необходимо исключить предоставление доступа к методу addJavascriptInterface в WebView из-за предполагаемого вредоносного контента

- Метод onGeolocationPermissionsShowPrompt() для геолокации должен запрашивать разрешение

- В SDK необходимо указывать разрешения, так как выходные файлы по умолчанию создаются с правами на чтение

- Необходимо исключить использование loopback при обработке конфиденциальных данных путем использования HttpsURLConnectionclass или SSLSocketclass

- Рекомендуется использовать App Security Practices из документации Android Developers

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

#appsec #devsecops #reco #specialty #pmcases

🛠 Практики DevSecOps для C

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

Для указателей необходимо учитывать:

- Подделку указателей, где нельзя использовать их не по назначению для доступа, дублирования или изменения переменных объекта
- Адресную арифметику, где осуществляется динамического выделения памяти массиву, что может привести к ошибкам чтения смежных областей памяти
- Висячие указатели, где происходит удаление/ освобождение объекта без изменения значения связанного с ним указателя
- Блуждающие указатели, где запрещено использование указателя без предварительной инициализации для любого состояния, так как аналогичное поведение как у висячих указателях

А теперь смотри, есть не типовые вещи как рекомендации:

- Использование принудительной инициализации указателей для удаления диких указателей
- После удаления указателя необходимо установить его на нулевой или недействительный адрес
- Вместо перебора массива с использованием адресной арифметики необходимо использовать отдельную индексную переменную и проверить, что бы индекс не превышал размер массива
- Использовать Garbage Collector для освобождения памяти, используемую объектами, на которые больше нет ссылок с system.gc, delete
- Контролировать вызов операций суперкласса для исключения type confusion из-за нестрогой проверки типов в языке
- Необходимо исключить использование функций, которые не выполняют проверку границ, таких как strcpy(), strcat(), sprintf(), vsprintf() и gets() с заменой на strncpy(), strncat(), snprintf() и fgets()
- При использовании функций scanf(), scanf(), fscanf(), sscanf(), vscanf(), vsscanf() и vfscanf() должна контролироваться длина
- Необходимо исключить использование функций позволяющих реализовать возможности переполнения буфера: realpath(3), getopt(3), getpass(3), stradd(3), strecpy(3) и strtrns(3)
- Использовать calloc() вместо malloc() для динамического выделения памяти
- Реализовать проверку диапазона целых чисел как часть проверки ввода из-за усечения
- Объявлять переменную как volatile для удаления
- Использовать системный вызов mlock() для UNIX и VirtualLock() для Windows, который предотвращает выгрузку заблокированной памяти на диск
- Использовать IndexOutOfRangeException для отслеживания попыток обращения по некорректному индексу
- Использовать небезопасный контекст с unsafe для работы с указателями, что отключает автоматические проверки безопасности при условии их зачистки после и контроля проверки границ, корректного управление памятью
- Доступ к unsafe строго регламентируется и используется как исключение
- Исключить формирование SQL-запросов путём конкатенации строк
- Делать ориентацию на параметризированные запросы
- Использовать современные криптографические алгоритмы BCrypt или Argon2 с солью и итерациями для хранения хэшей паролей
- Избегать прямого вывода пользовательского ввода
- Стараться использовать контекстно-зависимую очистку
- Использовать потокобезопасные коллекции (ConcurrentDictionary, ConcurrentQueue)

Вот теперь отличия для C#, что именно следует игнорировать:

- Работа с указателями: подделка, висячие и блуждающие указатели, принудительная инициализация, обнуление после удаления
- Адресная арифметика для массивов
- Использование malloc(), calloc(), free(); ручное управление памятью
- Использование функций типа strcpy(), sprintf(), gets(), scanf() и подобных для ввода/вывода
- Системные вызовы mlock() и VirtualLock() (кроме специфичных случаев с секретами)
- Использование volatile для управления удалением объектов
- Проверка type confusion через вызов суперкласса (C# строго типизирован)

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

#appsec #devsecops #reco #specialty #pmcases

🛠 Nuclei: open-source DAST с использованием YAML-шаблонов

Салют,
Давай сегодня посмотрим с тобой в сторону динамического тестирования DAST, который применяет шаблонизатор YAML. Я хочу поделиться с тобой удобным инструментом, который обычно используется в дополнении к Burp Suite.

Описание

Поддерживает веб-приложения, API, сетевые сервисы и облачные инфраструктуры. Вот тут можешь посмотреть официальный репозиторий и детали по используемым флагам вот тут. Поддерживает параллельную обработку для массового сканирования. Работает в связке с subfinder, httpx, naabu. Не имеет собственных настроек политик. Управление политиками Quality Gate осуществляется на уровне конвейера при его вызове. Лицензия MIT.

У инструмента есть особенности, давай отметим некоторые из них:

- Шаблоны с протоколами code/javascript требуют цифровой подписи и явного указания флага -code для запуска
- Следует использовать режим -disable-unsigned-templates, который разрешает выполнение только подписанных шаблонов и запускайте только в изолированной среде
- Запуск не проверенных шаблонов от третьих лиц опасен из-за риска внедрения вредоносного кода.
- Перед запуском анализируйте id, info, payloads и fuzzing на предмет подозрительных операций
- Используйте флаги ограничения скорости -rl и количества параллельных запросов -c 

Применение

nuclei -u https://example.ru # Сканирование одиночной цели
nuclei -l targets.txt # Сканирование списка целей
nuclei -u https://example.ru -t cves/2021/CVE-2021-12345.yaml # Запуск конкретного шаблона
nuclei -u https://example.ru -tags jira -s critical,high # Фильтрация по тегам и серьезности
nuclei -u https://example.ru -as # Автоматическое определение технологий
subfinder -d example.ru | httpx | nuclei # Интеграция с инструментами разведки
nuclei -l openapi.json -im openapi # Сканирование OpenAPI
nuclei -t template_with_code.yaml -code -c 50 -rl 100 # Безопасный запуск шаблонов с кодом
docker run projectdiscovery/nuclei:latest -u https://example.ru # Запуск сканирования c docker

GitLab CI

security_scan:
  stage: test
  image: golang:latest
  before_script:
    - go install -v github.com/projectdiscovery/nuclei/v2/cmd/nuclei@latest
  script:
    - nuclei -u $URL -t /templates -json -o nuclei-report.json
  artifacts:
    paths:
      - nuclei-report.json

Jenkins

stages {
        stage('Security Scan') {
            steps {
                sh '''
                    # Установка Nuclei
                    go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
                     
                    # Запуск сканирования
                    $HOME/go/bin/nuclei -u $URL -t $NUCLEI_TEMPLATES -json -o nuclei-report.json
                '''
            }
        }
    }
     
    post {
        always {
            archiveArtifacts artifacts: 'nuclei-report.json', fingerprint: true
        }
    }
}

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

- Следует использовать environment с указанием тестируемого URL = 'https://example.com' и используемым NUCLEI_TEMPLATES = '/templates'
- Имеет огромную базу актуальных шаблонов и низкий уровень ложных срабатываний
- Поддерживает множества протоколов (HTTP, TCP, DNS, SSL)
- Имеет риски выполнения вредоносных шаблонов из-за отсутствия опыта
- Имеет последующий потенциальный DoS-эффект на продакшн-системы
- Необходима экспертиза для написания собственных шаблонов
- Тестирует кроме web, также API, облачную инфраструктуру (AWS S3, Azure, etc.), сетевые устройства, включая сторонних поставщиков

#toolchain #dast

🛠 Нетиповые практики DevSecOps для CI/CD

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

Continuous Integration/ Continuous Delivery — это автоматизация процессов разработки, которая включает непрерывную интеграцию и непрерывную доставку. Автоматизация нацелена на SDLC цикл.

А теперь давай рассмотрим сами практики и начнем с базы:

- Изоляция контроллера: сборки не на встроенном узле, а инициализируются из глобальных переменных
- Не допускается наличие не используемых переменных среды
- Не запускать сборку от ТУЗ с привилегированными правами
- Средства сборки и деплоя не должны требовать расширение прав доступа
- Обеспечивать строгий рендеринг пользовательского контента: файлы из рабочих директорий, архивные артефакты и т.д.
- В процессе CI\CD должна быть исключена возможность переполнений и несанкционированной перезаписи.
- Не допускается вызов внешних зависимостей на этапе деплоя

Stages

- Каждый Stage изолируется и разделяет операции функционально
- Учётные записи, используемые или вызываемые при сборке или деплое, должны проходить предварительную аутентификацию:
- аутентификация должна быть персональной и обеспечивать возможность отслеживать действия;
- аутентификация должна быть обеспечена для пользователей всех уровней доступа (администраторы, супервизоры)

- Все jobs необходимо разделять по назначению: CI (сборка, тестирование, анализ кода и т.д. - обособленно и не взаимодействует со средами эксплуатации, а CD использует отдельные УЗ
- Библиотеки, сборки и шаблоны конвейеров следует хранить отдельно от управляющего конфига
- Рекомендуется использовать отдельные репозитории для сборок и шаблонов для изоляции конфигураций
- Подключаемые скрипты: Groovy, Shell, Python и др. не должны содержать проверок или условий, позволяющих обходить этапы сборки, тестирования или других критических стадий конвейера
- Для обеспечения целостности и отслеживания изменений необходимо автоматически собирать хэш-сумму профиля конвейера или конфигурации при каждой сборке
- На этапе CD требуется проверка хэш-суммы профайла

Особенности

- Ниже maintainer нет возможности самостоятельно выбирать окружение и быть ограничены
- Деплой не должен выполняться без MR
- Все pre-действия должны включать полные метаданные артефакта — параметры сборки, атрибуты поставки и идентификаторы версий
- Все callback-действия внутри конвейера,
- Build и тд. должны выполняться только для приложений, упакованных в Docker-контейнеры для единообразия сред
- В CI рекомендуется запускать несколько типов тестов: интеграционные, unit-тесты, регрессионные тесты
- При неуспешной сборке артефакт не должен попадать в репозиторий артефактов
- Среды деплоя: staging, production и тд. должны быть логически и физически разделены
- Все post-действия в конвейере не должны вызываться независимо и обязаны выполняться только после завершения соответствующих pre- или main-этапов

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

#appsec #devsecops #reco #specialty #pmcases

🤔 Product Requirement Document для Shift-Left

Салют,
Сегодня хочу поделиться с тобой своей практикой для проектного управления (PMI), которая позволяет мне видеть концептуально картинку и анализировать корректность выстраивания процессов DevSecOps, интеграции AppSec Toolchain и управления человеческими ресурсами.

Что такое PRD и зачем он нужен?

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

Структура

- краткое описание функционала - описываем что мы хотим сделать простыми словами (как например, если бы рассказывали коллеге у "кулера")

Плохой пример: «Добавить кнопку «Верификация» в авторизованную часть 2FA, класть данные логов, кто заходил, потому что нужно потом строить из них графики»

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

- почему мы это делаем - разворачивает смысл в первом абзаце. Дальше декомпозируется.

Плохой пример: «Потому что требует решгулятор эту фичу для соответствия требованиям»

Хороший пример: «Потому что это может дать нам возможность быстрого прохождения верификации и контроля пользователей, обезопасить user story и быть уверенными в защищенности данных (ссылка на результаты эксперимента/ расчет/ кейс)»

- ожидаемый результат - описываем какого именно результата ждем, наш Win Condition.

Win Condition отвечает на один простой вопрос — как мы поймем, что у нас получилось. Это может быть любая количественная или качественная метрика, событие оценки. Главные критерии качества для Win Condition — измеримость, однозначная трактуемость и простота (принцип Invest).

Fail Condition отдельно можно не прописывать. По умолчанию предполагаем, что при не достижении Win Condition мы автоматически попали в состояние Fail.

- риски ИБ - описываем и оцениваем, что может стать ее причиной и прямого/ косвенного урона требующих изменение архитектуры, функционала и тд, - как пример риск киберпреступления и мы понимаем, что входная поверхность атаки больше, чем мы покрыли и допускаем
- артефакты - исследования, результаты, требования, evidence
- функциональные требования - само решение, приводя альтеранативы для выбора и доработки кейсов, таким образом мы окажем сервисное обслуживание и оптимизируем взаимодействие

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

Хардкорные ФТ: описываем всю бизнес логику пошагово (применимо при проработке сложных кейсов.

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

Итого:

- PRD хватает для того, чтобы техническая команда вместе могла провести первичную декомпозицию.
- Логика использования PRD в ИБ - встраивание Shift Left процесса в разработку и фиксация требований ИБ, а также контроль, сбор evidence.
- Именно он (или ссылка на него) составляет описание user story, которая потом декомпозируется на tasks (задачи)
- После окончания работ/ описания требований или иных дополнений над задачами - PRD становится документацией о том, как это работало и почему/ зачем было реализовано.
- PRD пишется для больших и сложных вещей, где есть много зависимостей и очень важно сохранить для истории как это работало.

#devsecop #pmi #specialty #pmcases