«Это цитата, слова, полные мудрости, которые кто-то важно сказал и может заставить читателя вдохновиться» - кто-то из великих.

#lol

Салют,
Тут намечается классное событие 2 октября, а именно GuardConf 2025 (@guardconf). Я буду выступать в роли модератора в блоке по безопасной разработке и мы поговорим с топами: Андреем Карповым PVS-Studio, Светланой Газизовой Positive Technologies, Антоном Володченко Codescoring, Владиславом Крыловым AKTIV.CONSALTING про:

1 - Кому и зачем нужна безопасная разработка, какие специалисты этим занимаются? Обсудим регуляторику, стимулы для инженеров, целесообразность для бизнеса именно со стороны ценности для конечного продукта.
2 - Какие принципы должны быть заложены в продукте с самого начала? Обсудим Secure-by-design, парадигму Shift-Left, разберем технические решения и их прототипирование.
3 - Как оцениваются риски ИБ для уязвимостей и считают ли их финансовый убыток? Обсудим как выстроить оценку влияния на продукт, как считать убыток (считаем ли ФОТ на устранение, расследование, переработки, влияние на технологические процессы, операционную надежность и тд)?
4 - Какие типы атак наиболее актуальны на конвейер поставки? Обсудим практические кейсы на фоне обзора рынка в разных отраслях, а также какие типовые паттерны атак существуют.
5 - Как выстроить процесс безопасной разработки в организации?
6 - Показатели и критерии безопасности ПО

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

Дополнительная информация от организаторов.

До встречи на митапе 🙏

#conf #pmcases #humanres #кулуарка

🥶 Анализ рисков ИБ: зачем нам риски?

Итак, начнем,
Данный процесс - Анализ Рисков, описывает практику Shift Left (раннего вовлечения) на этапах проектирования (далее тоже посмотрим как это работает?), проработки технического решения и внесения изменений в архитектуру уже на стадии эксплуатации.

Анализ Рисков служит источником требований для команды в рамках Lean-Agile подхода при разработке продукта или проекта. Этот подход особенно полезен и актуален при оценке влияния features на бизнес-логику.

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

Один из самых частых вопросов на проектах:
«Как объяснить бизнесу, что наш AppSec нужен, а не просто тормозит релизы?»

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

Именно поэтому нужен анализ рисков ИБ - язык, который одинаково понимают и разработчики, и бизнес, и мы как инженеры.

Базовые шаги:

1. Идентифицировать - где может прилететь: feature, изменение спецификации инфраструктуры, изменение процессов, новые люди.
2. Классифицировать - описать (vulnerability description), по источнику возникновения (threat description), влиянию (scenario impact description).

В случае необходимости сгруппировать, определить вектор реализации, на сколько уязвимость вменяема для продукта, а дальше проработать PRE- (обязательные условия до поставки в продукционную среду - именно критикалы, блокаторы), POST-меры (что может быть устранено впоследствии)3. Оценить - вероятность (от 0 до 1) × ущерб × устранение × влияние = уровень риска. Здесь помогают предикторные метрики (например, % закрытых findings до релиза) и классические отстающие (legging) метрики

(первичное и базовое приблежение)

4. Сопоставить с бизнес-функциями которые являются как изменения технического решения, либо аффектящие компоненты, функции, API endpoints, etc
5. Принять решение в зависимости от принципа работы с рисками: принятие, отказ, делегирование, минимизация

Что это даёт:

1. Разговор с бизнесом на понятных терминах («потери», «TTM», «стоп фактор»)
2. Приоритезацию (не чиним всё подряд, а то, что реально бьёт по деньгам/ срокам)
3. Прозрачность: команда понимает, почему фикс именно этих задач важен

Ошибка многих компаний:

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

Рабочий подход:

карта рисков типа Critical, Medium уровня с оценкой и мерами их снижения.

Концептуальный пример: devops необходимо осуществлять мониторинг критичного сервиса, для этого им надо понимать, что и когда может упасть, что бы отследить вовремя инцидент отказа в обслуживании. Следовательно появляется вполне классная мысль: "давайте мы будем отправлять нотификации себе в общий чатик типа телеги?". Идея очень мощная и классная, но например для сектора fintech могут быть вызванные обоснованные риски, такие как.. (смотри картинку поста). Надо продумать какие меры снизят риски ИБ, это может быть линк на внутренний прокси с 2fa, чистка логов в канале, модерирование ботом, использование шифрование канала (WSO2? Мы его рассмотрим), DAM, обезличивание/ маскирование чувствительных данных, подготовка заранее определенных шаблонов и тд. Этот подход либо снижает риски, либо дают понимание бизнесу для реальной ответственности.

Вывод:

именно поэтому важно оценивать правильность использования тех или иных feature и давать им оценку влияния от влекущих рисков ИБ.

#riskanalys #pmi #compliance #pmcases #techsolution

«my mom says I’m special”

#lol

🫡 SBOM: что это и для чего?

Software Bill of Material - файл в формате JSON или XML, который включает в себя инвентаризационный список всех компонентов (пакетов, библиотек), используемых в разрабатываемом приложении или необходимых для его работы.

В components SBOM указывается автор пакета, purl (Package URL), лицензия, хэш библиотеки, CPE (Common Platform Enumeration) и другие компоненты. Используется CycloneDX, SPDX (Software Packet Data Exchange) и SWID (Software Identification). Алгоритм прикреплен к посту.

SBOM позволяет решить две связанные задачи:

- Инвентаризировать все использованные в продукте (исходном коде, артефакте, операционной системе) компоненты
- Автоматизировать анализ их безопасности с помощью инструментов SCA (Software Composition Analysis)

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

Состоит из:

- Метаданные самого файла SBOM: спецификация, уникальный номер, метка времени
- Перечень компонентов
- Описание источника SBOM (блок externalReferences)
- Описание связей между компонентами (блок dependencies) - содержит название пакета из исходного кода и его зависимости, то есть пакеты, которые необходимы ему для работы. С помощью данных dependencies и названий библиотек можно построить граф зависимостей, в том числе транзитивных.

Как это выглядит //SPDX //CycloneDX

{
  "spdxVersion": "SPDX-2.3",
  "dataLicense": "CC0-1.0",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "example-project-1.0.0",
  "documentNamespace": "http://spdx.org/spdxdocs/example-project-1.0.0-abc123",
  "creationInfo": {
    "created": "2025-06-24T10:00:00Z",
    "creators": [
      "Tool: spdx-sbom-generator-0.0.1",
      "Organization: ExampleOrg"
    ],
    "licenseListVersion": "3.23"
  },
  "packages": [
    {
      "name": "lodash",
      "SPDXID": "SPDXRef-Package-Lodash",
      "versionInfo": "4.17.21",
      "downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
      "filesAnalyzed": false,
      "licenseConcluded": "MIT",
      "licenseDeclared": "MIT",
      "supplier": "Organization: Lodash Team",
      "originator": "Person: John-David Dalton",
      "externalRefs": [
        {
          "referenceCategory": "PACKAGE-MANAGER",
          "referenceType": "purl",
          "referenceLocator": "pkg:npm/lodash@4.17.21"
        },
        {
          "referenceCategory": "SECURITY",
          "referenceType": "cpe23Type",
          "referenceLocator": "cpe:2.3:a:lodash:lodash:4.17.21:*:*:*:*:*:*:*"
        }
      ]
    }
    ...
   ]
}

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "timestamp": "2025-06-24T10:00:00Z",
    "tools": [
      {
        "vendor": "CycloneDX",
        "name": "cyclonedx-cli",
        "version": "0.24.0"
      }
    ],
    "component": {
      "type": "application",
      "name": "example-project",
      "version": "1.0.0",
      "purl": "pkg:npm/example-project@1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "e3b0c44298fc1c149afbf4c8996fb924..."
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ]
      ...
    }
  ]
}

Итого: SBOM нужен для контроля компонент и может использоваться как проверка на подмену зависимостей или для golden-repo. Это то, что позволяет контролировать окружение и сами сборки, что дает нам возможность управления и построение Vulnerability Management.

Далее в постах рассмотрим также как работает например Cdxgen, Syft и тд.

#toolchain #sbom

🛠 .gitignore: почему важно игнорирование избыточных артефактов?

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

Рассмотрим детальнее:

.gitignore - это конфиг (по факту файлик) игнорирований для Git, который сообщает ему, какие файлы и каталоги следует не учитывать, то есть не отслеживать и не добавлять в репозиторий.

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

1. Файлы, образующиеся в процессе и результате компиляции проекта. Как правило, для них отводятся каталоги с именами вроде target/, output/, release/, debug/
2. Файлы, генерируемые тестовым фреймворком, профилировщиком, дебаггером и т.п.
3. Сгенерированная из кода документация — только если не генерируется в отдельный репозиторий, через который потом развертывается сайт с документацией (пример gpages)
4. Файлы, создаваемые при выполнении кода: журналы (*.log), результаты работы и т.п.
5. Временные файлы текстового редактора или среды разработки (*~)
6. Файлы, создаваемые операционной системой, например thumbs.db, .DS_Store

Пример:

- В C# хранится вывод, чтобы можно было легко собрать проект, но можно настроить, что запускалась при сборке, однако это возможно не для всех скриптов
- Хранить или не хранить composer.lock - нужно понимать его работу
- Нельзя заигнорить .idea/, потому что отвалятся настройки проекта, либо нельзя просто взять и оставить .idea/, потому что личные пути попадут ко всем и наплодят конфликтов.

Ремарка:

Для хранения есть классная возможность, как использование packages в виде артефакта (рассмотрим далее). Если можете использовать NuGet, Composer, CPAN, Lein, Maven, то бинарные зависимости должны быть там.

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

Реко: для создания .gitignore удобно использовать генераторы шаблонов, типа

этого.

#toolchain #reco #specialty

😅 Свежачок подъехал,
Планирую выступить спикером на конфе 7/10/25 - "Оптимизируем инструментарий для процессов безопасной разработки". Интересная конфа, которая помогает послушать нетривиальные точки зрения ребят на рынке.

Мы обсудим:

• Практические кейсы оптимизации стека — меньше инструментов, больше пользы
• AI Security: как защитить код, данные и ML-модели от новых угроз
• DevSecOps без тормозов: безопасность как встроенный элемент CI/CD
• Экспертный нетворкинг: AppSec и DevSecOps лидеры делятся опытом

В прошлом году также выступал (ознакомиться) с темой "Quality Gate: повышение оценки защищенности для безопасной разработки ПО". Есть видеозапись, можем посмотреть тут.

С программой можно будет ознакомиться вот тут.

Присоединяйтесь, буду рад вас видеть там и мы с кайфом обсудим интересные вопросы, которые задают себе люди по ценности ИБ в командах разработки. Регистрируйтесь вот тут (там еще есть пару вариантов).

#conf #pmcases #humanres #кулуарка

🛠 Semgrep: custom как фича и почему начинаем с него?

Салют, начнем,
Я бы хотел поговорить про

Static Application Security Testing - метод анализа, при котором проверяется статичный исходный код на наличие уязвимостей. Это подход «белого ящика».

Теперь давайте посмотрим на сам инструмент, а начем с полезной выжимки, такой как

- Tool позволяет работать с приложением в нетривиальном режиме: dataflow/ taint-трекинг, межфайловые цепочки
- Приоритизирует уязвимости зависимостей по достижимости/использованию (reachability)
- Масштабируется и в custom под написание своих собственных политик
- Определение и валидация активных секретов
- Анализирует код с помощью синтаксических шаблонов
- Поддерживает множество языков (Python, JavaScript, TypeScript, Java, Go, C/C++, Ruby и др.)
- baseline-commit
- Для фиксирования инкременты без задержек с вычислением diff не нужно костылить
- Может в pre-commit
- Тип лицензии: LGPL 2.1 (ранние версии — проприетарные, сейчас полностью opensource)
- Форматы отчетов: JSON, SARIF, GitLab SAST, JUnit XML, Text, Emacs, Vim

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

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

# Установка через pip (или brew, docker)
python -m pip install semgrep
 
# Сканирование репозитория
semgrep scan --config auto # автоопределение языка и базовых правил
semgrep scan --config p/python # только Python-правила (варианты - p/gosec/ golang/ javascript/ dockerfile/ react/ secrets/ owasp-top-ten)
 
# CI/CD
semgrep ci # для использования semgrep в составе пайплайна
semgrep scan --config "p/ci" --exclude "tests/" # исключение директории
semgrep ci --allow--untristed-validators # разрешение работы с ненадежными источниками правил, отличными от semgrep.dev
semgrep ci --code # запуск статического анализатора от semgrep
semgrep ci --autofix # внедрение в правило автоправок от инструмента (экспериментальная функция)
semgrep ci --dryrun # отмена внесения автоисправлений в правила
 
# Вывод в SARIF (для GitHub Security)
semgrep scan --config auto --sarif -o results.sarif

#  Docker
docker pull returntocorp/semgrep
docker run -v $(pwd):/src returntocorp/semgrep semgrep scan --config auto // запуск сканирования

Ну и зацепим как происходит интеграции в pipeline

CI/CD

semgrep_scan:
  stage: security
  image: returntocorp/semgrep
  script:
    - semgrep scan --config auto --sarif -o semgrep.sarif
  artifacts:
    reports:
      sarif: semgrep.sarif

pipeline {
  agent any
  environment {
    REPORT_DIR = 'semgrep-reports'
  }
  stages {
    stage('Semgrep Scan') {
      steps {
        sh '''
          docker run -v $(pwd):/src returntocorp/semgrep \
            semgrep scan --config auto --json -o ${REPORT_DIR}/semgrep.json
        '''
      }
    }
  }
  post {
    always {
      archiveArtifacts artifacts: '${REPORT_DIR}/**'
    }
  }
}

#toolchain #sast