«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

"Да ладно, Дядя Федя..."

#lol #кулуарка

🛠 AppSec инструменты: синкнемся по определениям

Ремарка сходу:

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

Ощущение, все те же, что как бы интересует AppSec и процесс DevSecOps давненько, но главное бы не впутываться и скорее потеряться теряться (а вдруг там сожрет?), да и в целом так повсеместно в смежном PMI, либо ценности продукта.

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

Окейси, немного вкинули, хоть красивое будет 😄

По этой причине решил подобрать общую подборку определений для toolchain. Это для того, что бы мы концептуально могли понимать друг друга, итак:

- DAST (Dynamic Application Security Testing) – динамическое тестирование безопасности приложения, то есть это имитация реальных атак на приложение во время его работы
- SAST (Static Application Security Testing) – статический анализ кода без его запуска на наличие ошибок и уязвимостей в исходном коде
- SCA (Software Composition Analysis) – анализ состава компонент (зависимостей) ПО
- OSA (Open Source Analysis) – анализ компонент с открытым исходным кодом при попадании в периметр разработки, то есть процесс проверки безопасности open-source компонентов, включающий в себя совокупность инструментов SCA, SCS и анализа лицензионных рисков. 
- SCS (Secure Code Standarts) - набор правил и практик, используемый разработчиками ПО с целью предотвращения нарушений безопасности, неконтролируемых утечек данных и других видов угроз
- License Policy - нарушение лицензионного соглашение, что то на подобии соблюдения авторского права (это что то типа DMCA с с помесью части Trade Secret)
- SBOM (Software Bill of Materials) - инвентаризационный список всех компонентов (пакетов, библиотек), используемых в разрабатываемом приложении или необходимых для его работы
- NVS (Network Vulnerability Scanner) - сетевой сканер уязвимостей с уклоном на L3/L4 c ограниченными DAST-возможностями (не тривиальненько)
- BCA (Bytecode and Container Analysis) – анализ бинарного кода и состава контейнеров
- CIS (Container Image Scanner) – сканирование образов контейнеров на уязвимости (Container Security)
- CSPM (Cloud Security Posture Management) – контроль конфигураций Kubernetes и облачных сред
- SM (Secret Management) – управление секретами

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

#toolchain #appsec #devsecops #specialty