«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

😂 Must-have: «симулятор программиста-аутиста»

Можно поиграть за разраба, пытающего в социум и работать корректно, а теперь представьте еще и ИБ приходит с ноги?

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

Местами перебор даже для прожженных, но "отборный и искрометный" юмор показывает, что в целом как то напоминает ... (подставьте сами)

#lol #кулуарка

🤔 Что такое авторское право и практика DMCA (с)

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

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

Обычно это все мы передаем по ТК и/ или по договорам услуг, работ уже заказчику, но есть классные тонкости, как например в части для софта как не отчуждаемость на произведение (хотя это юридическая возможность позволяющая прекращать юридическую связь с объектами прав) или же лицензирование и иное (но это мы обсудим)

Давай разберем, что это?

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

DMCA (Digital Millennium Copyright Act) — это закон об авторском праве в digital путем использования механизма «notice and takedown», то есть: автор/ правообладатель может отправить жалобу и твой контент удалят без суда и разбирательств. Обычно это именно тот знак копирайтерства как (с).

Авторское право для РФ это конкретное цельное произведение, как Объект интеллектуальной собственности, а для DMCA это любой созданный контент человеком, то есть: если в РФ я сделал картинку и ее переиспользуют 1 в 1, то это кейс нарушения АП, а если изменяют больше 40% - нет, а вот для DMCA оба случая указывают, что это нарушение.

Теперь важные для тебя особенности, запоминай:

- Объекты авторского права/ интеллектуальной собственности - результат творческого труда, независимо от назначения
- Субъект авторского права - физическое лицо или соавторы, чьим творческим трудом оно создано
- Права не могут возникнуть у юридического лица или у ИИ (включая промты)
- Любое изменение объекта авторского права уже классифицируется как отдельное произведение, при условии изменений более 40% материала или рерайтинга этого контента
- Полного отчуждение авторского права не существует, вы можете всегда оставить за собой права опубликовать, что любая модификация материалов должна быть с вашим упоминанием
- Полные права всегда остаются за вами и при необходимости вы можете их возобновить, если условия передачи отсутствовали и/ или были нарушены при использовании
- Юридические лица могут получить исключительное разрешение (не полные права) на использование произведения:

-- Договор отчуждения только с отдельным видом стоимости за работы, которые обязательно должны быть включены на весь срок действия
-- Лицензионный договор на использования в определённых пределах (так работаат политика например игровой индустрии)
-- Договор авторского заказа по техзаданию заказчика, где формулировка на исключительные права только в рамках условий
-- Служебные произведения принадлежат все работодателю (ст. 1295 ГК РФ), если иное не предусмотрено договорными отношениями

- Типы лицензирования носят разный характер для проприетарного, а также свободного распространения (разберем отдельно). Пример:

MIT License - одна из самых ранних лицензий, разработанная Массачусетским технологическим университетом. Является максимально пермиссивной лицензией, не накладывающей на пользователей никаких ограничений, кроме уведомления об авторстве. Позволяет включать код под данной лицензией в проприетарные продукты с их последующей продажей.

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

#toolchain #compliance #reco #specialty

🛠 VI/ VIM: немного полезной навигации, как структуры

Что-то резко вспомнил про vi/ vim, nano, etc. В итоге самое комфортная работа на vim для меня, практика еще показывает когда учился на старых добрых тачках ubuntu, fedora, freebsd на консольке/ терминале. Решил давно себе заготовочку сделать и поделиться с вами. Так скажем для инфо.

Режимы работы

• Режим команд (Command mode) - используется для выполнения команд. При запуске Vim, вы находитесь в этом режиме.
• Режим вставки (Insert mode) - используется для ввода текста. Для перехода в этот режим, нажмите клавишу "i".
• Режим замены (Replace mode) - используется для замены существующего текста. Для перехода в этот режим, нажмите клавишу "R".
• Режим визуального выделения (Visual mode) - используется для выделения текста для копирования, вырезания или изменения. Для перехода в этот режим, нажмите клавишу "v"

Навигация

• h - переместить курсор влево
• j - переместить курсор вниз
• k - переместить курсор вверх
• l - переместить курсор вправо
• w - переместить курсор на начало следующего слова
• b - переместить курсор на начало предыдущего слова
• e - переместить курсор на конец текущего слова
• 1 - переместить курсор в начало строки
• $ - переместить курсор в конец строки
• gg - переместить курсор в начало файла
• G - переместить курсор в конец файла

 Редактирование текста

• i - вставить текст перед курсором
• a - вставить текст после курсора
• o - вставить новую строку после текущей строки и перейти в режим вставки
• dd - вырезать текущую строку
• yy - скопировать текущую строку
• p - вставить скопированный или вырезанный текст после курсора
• u - отменить последнее действие
• Ctrl + r - повторить отмененное действие

Сохранение и выход из редактора

• :w - сохранить файл
• :q - выйти из Vim
• :wq - сохранить файл и выйти

#toolchain #reco