AppSECT.A.
378 subscribers
427 photos
9 videos
126 links
Блог Ильи Шмакова

geminishkv.tech

- AppSec Toolchain
- DevOps
- Процессы DevSecOps
- Infosec Risks
- PMI
- Кулуарный ИБ

AppSec Teamlead СберСпасибо @sberbank

Лидер findevsecops.ru @fintechassociation

Преподаватель @bmstu1830, @miptru
Download Telegram
🫡 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
🔥4
Кстати, от ЛАНИТ напоминалка о ивенте, который нас вместе ждет 2/10/2025 с 10:00. Сама дискуссия пройдёт с 15:00 до 16:00.

📍 Место проведения: LOFT#2, ул. Ленинская Слобода, д.26, стр.11.

Для участия нужна
регистрация.

#conf #pmcases #humanres #кулуарка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6
🛠 .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
🔥4
😅 Свежачок подъехал,
Планирую выступить спикером на конфе 7/10/25 - "Оптимизируем инструментарий для процессов безопасной разработки". Интересная конфа, которая помогает послушать нетривиальные точки зрения ребят на рынке.

Мы обсудим:

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


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

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

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

#conf #pmcases #humanres #кулуарка
🔥5
🛠 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
🔥5🤯2
Ух, конференция GuardConf 2025 в самом разгаре 😅

В итоге, дорогие, на базе и уже готовлюсь к модерации своей секции @guardconf

Людей приятное количество, зал будет битком по ходу, а пока напомню, кто будет вместе со мной в треке: Андрей Карпов PVS-Studio, Светлана Газизова Positive Technologies, Антон Володченко Codescoring, Владислав Крылов AKTIV CONSULTING.

Тематика вопросов:

1 - Кому и зачем нужна безопасная разработка, какие специалисты этим занимаются?
2 - Какие принципы должны быть заложены в продукте с самого начала?
3 - Как оцениваются риски ИБ для уязвимостей и считают ли их финансовый убыток?
4 - Какие типы атак наиболее актуальны на конвейер поставки?
5 - Как выстроить процесс безопасной разработки в организации?
6 - Показатели и критерии безопасности ПО

Синкнемся на митапе 🙏

#conf #pmcases #humanres #кулуарка
🔥5❤‍🔥3
🎧 DevSecOps без фильтров: подкаст по безопасной разработке ПО

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

Буду периодически закидывать highlites, которые позволяет получать интересную и полезную выжимку.

Ранее с Aktiv.Consulting @aktivcons мы провели классную беседу, которая вскрыла острые вопросы рынка про то как взаимодействовать ИБ и командам разработки, как не "влетать с двух ног" и почему важна безопасная разработки. Отдельно красочно описали каким образом стоит считать ущерб инцидента. Примеры разбирали на базе Банковской отрасли.


В первом подкасте мы разобрали

- Зачем DevSecOps бизнесу, а не только ИБ-специалистам
- Какой минимальный набор практик нужен, чтобы стартовать
- как измерять пользу от внедрения и что делать с «провальными» метриками
- Кто такие Security Champions и как они спасают команды от ошибок в части ИБ
- Какие тренды и перспективы есть у безопасной разработки в России


Отмечу важное

Именно этот выпуск до сих пор актуален — он как навигатор для тех, кто задумывается о DevSecOps или хочет вытащить свой процесс на новый уровень.

Смотри и слушай:
▶️VK Видео
▶️Rutube
🎼Podster
🎼Yandex Музыка

В этой рубрике я буду разбирать самые спорные и практичные моменты: короткие видео, дополнительные кейсы, конкретные инструменты. Чтобы у вас была не просто теория, а рабочие ответы «как это сделать у себя».


А дальше будет только интереснее. Следите за DevSecOps без фильтров — всё самое полезное о безопасной разработке будет здесь.

#подкаст #кулуарка #devsecops #appsec #pmcases #roadmap #riskanalys #vulnmanagement #humanres #compliance #gost
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4❤‍🔥2
🔥 DevSecOps уже не «дополнение», а must-have для бизнеса

В материале РБК Trends я поделился своим опытом, где мы разбираем, почему безопасность перестала быть «чем-то на потом» и стала частью самой разработки.

Ремарка: согласно исследованию Positive Technologies, 83% российских корпораций уже уделяют внимание security-практикам при создании собственного ПО.


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

Также своим опытом делятся Александр Самсонов Код Безопасности, Светлана Газизова Positive Technology, а также мои коллеги Николай Сальников, Александр Чербунин из ЛАНИТ.

Ключевые мысли, которые откликнутся многим:

- Инструменты — это не DevSecOps. Без процессов и культуры они превращаются в дорогую декорацию
- Основное сопротивление идёт не от технологий, а от людей: привычка «мы пишем код, а вы потом проверяйте» слишком крепкая
- Стартовать лучше маленькими шагами: встроить проверки в CI/CD, отработать триаж, постепенно прокачивать культуру команды.
- Не «слишком много работы», а экономия времени на старте, в процессе, а не в конце, когда фича в проде и могут быть последствия
- Самое ценное в работе с ИБ: PRE-, POST-условия, то есть система ограничений, допущений, когда мы можем договориться


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

Читать статью: Практики DevSecOps: как меняется подход бизнеса к цифровой безопасности

#кулуарка #devsecops #paper #pmcases #vulnmanagement #specialty
🔥3
"Да ладно, Дядя Федя..."

#lol #кулуарка
🤣4
🛠 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
🔥3
😂 Must-have: «симулятор программиста-аутиста»

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

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

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

#lol #кулуарка
🤣3🔥1
🤔 Что такое авторское право и практика DMCA (с)

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

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

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

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

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


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


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

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

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

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


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

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


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

#toolchain #compliance #reco #specialty
🔥5❤‍🔥3
🛠 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
🔥4🤯3
"По братски, для своих"

#lol #кулуарка
🤣3
Салют,
Сейчас идет интересная конфа, которую вы можете посетить или на фоне покрутить.

Речь про ITSec форум с онлайн трансляцией по темам "Оптимизируем инструментарий для процессов безопасной разработки". Вот тут описывал преролл к нему.

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

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

В закрепе привел коллег участников на конференции. Послушать кулуарные обссуждения можно будет после 13:00 по мск.

Свидимся 🙏

#conf #pmcases #humanres #кулуарка
🔥3
🛠 SBOM: легковесная генерация cdxgen

Ранее, мы с тобой посмотрели тут, что такое Software Bill of Materials SBOM. Мы разобрали как он выглядит, зачем и почему используется. Давай теперь посмотрим на сам инструмент и на то как его использовать, но он с особенностями.

Инструмент:

cdxgen - CLI инструмент для автоматизации SBOM в формате CycloneDX. Основные функции как анализ метаданных и лицензий, чтение manifest файлов. Из важного у него только генерация одного формата. Тип лицензии: Apache License 2.0.

Конвертация SBOM в формат, отличный от CycloneDX потребует конвертор. Зависимости, собранные вручную либо перепакованные могут не определяться или частично. Совместим с Dependency-Track для управления SBOM, включая Trivy, Grype.

Поддерживает следующие языки и форматы пакетов. Официальная документация и репозиторий. Может подписывать их.


Применение:



sudo npm install -g @cyclonedx/cdxgen
cd <Path to source code>

docker run --rm -e CDXGEN_DEBUG_MODE=debug -v /tmp:/tmp -v $(pwd):/app:rw -t ghcr.io/cyclonedx/cdxgen:master -r /app -o /app/bom.json # либо -p для вывода в консоли/ терминале

cdxgen -t java -o bom.json --server-url https://deptrack.server.com --api-key "token" --project-group ... # пример отправки на Dependency-Track



Флаги:



cdxgen [-t], [-o], [-p], [-r], [-h], [-v]
 
-t, --type # если не указывать этот параметр, то соберет вообще все зависимости, которые сможет
--exclude-type # убрать из обработки

-o, --output # сохранение в формате - XML, JSON
-p, --print # вывод "дерева SBOM" в виде таблицы
-r, --recurse // кекурсивное сканирование по директориям
      --no-recursive # базово по файлам в корневой директории
      --deep
     --fail-on-error # при сбое сбора одного из типов компонент высвечивает earning
     --technique # по умолчанию стоит auto режим, но можно задать "source-code-analysis", "binary-analysis", "manifest-analysis", "hash-сomparison", "instrumentation", "filename"
     --required-only # для исключений/ ограничений



Поддерживаемые BOM:
• Cryptography CBOM - Java, Python
• Operations OBOM - Linux container images
• Software-as-a-Service SaaSBOM - Java, Python, JavaScript, TypeScript, PHP
• Attestations (CDXA)
• Vulnerability Disclosure Report (VDR) -
OWASP depscan VDR


Pipeline:



sbom:
  image: node:20-alpine
  stage: test
  script:
    - npm i -g @cyclonedx/cdxgen
    - cdxgen -r . -o sbom.json
  artifacts:
    paths: [sbom.json]




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

#toolchain #sbom
🔥3