🛠 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

🎧 Интервью с ассоциацией BISA по рискам ИБ и безопасной разработке

Салют,
Нашёл бородатое в закромах, но до сих пор актуальное интервью с ассоциацией BISA @bisafm - про безопасную разработку ПО, риски ИБ и как дружить все это вместе.

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

По сути, три года прошло, а вопросы то теже:
Как встроить безопасность в разработку, не похоронив скорость TTM, и зачем бизнесу вообще этот DevSecOps.

О чём говорили

- Кто такие DevSecOps и почему «Sec» - это не инструмент, а культура
- Как построить SDLC, где безопасность не мешает релизам
-⁠ Зачем банку Quality Gate и как он снижает риски ещё до продакшена (привет моим кайфовым коллегам из Росбанка, мы с вами делали вещи)
- Как риск-менеджмент реально связан с безопасной разработкой
- Что такое ограничения и допущения для бизнес-ориентированного подхода с рисками ИБ?
- Как и почему вообще нужна эта история? Затронули немного регуляторку (на то время любимое, как must-have)
- Почему Shift-Left - это не лозунг, а способ экономить время и деньги

Почему стоит посмотреть

Если вы работаете с продуктами, безопасностью или просто хотите gонять, как компании уровня банка выстраивают DevSecOps-подход, - интервью даст чёткую картинку.
Без пиара, без страшных слов - только реальный опыт.

Timestamp:

▪️00:35 - Что такое DevOps
▪️1:50 - DevSecOps как процесс разработки безопасного ПО
▪️3:15 - Как риск-менеджмент связан с разработкой безопасного ПО
▪️6:52 - Что дает банку внедрение разработки безопасного ПО и ее взаимодействие с управлением рисками
▪️8:59 - Какие риски банка и клиентов снижаются при таком подходе
▪️10:20 - Какие плюсы это дает командам разработки
▪️11: 59 - Как оценивается зрелость реализации этих процессов в командах
▪️12:30 - Почему Росбанк решил внедрять процесс разработки безопасного ПО

🎬 YouTube

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

#подкаст #devsecops #appsec #compliance #pmi #gost

🤔 Лицензирование: свободное и проприетарное

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

Проприетарные лицензии:

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

Принципы:
- Ограничение на коммерческое использование ПО
- Ограничение на распространение ПО
- Ограничение на изучение и модификацию ПО

По объему выделяют:
- OEM лицензии (поставляются вместе с оборудованием)
- Однопользовательские лицензии
- Многопользовательские лицензии
- Корпоративные лицензии (для организаций)

Свободные лицензии:

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

Виды:
- Permissive (разрешительные)
- Strong Copyleft Licenses
- Weak Copyleft Licenses
- The Unlicense (лицензии на передачу кода в общественное достояние)

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

#toolchain #licenses

"админские забавы"

#lol #кулуарка

🛠 База DevSecOps & AppSec Toolchain

Итак, мы собрались тут за безопасной разработкой и инструментами AppSec. Давай посмотрим в целом на процесс и сами инструменты в нем, думаю, что пора начинать закидывать материалы, которые помогут вникать в сами этапы разработки в части технички от процессов.

DevSecOps как автоматизация производства безопасного ПО для:

- Выполнения требований регулятора,
- Снижения рисков ИБ (утечка, киберпреступления и тд) и угроз недопустимых событий
- Поддержки Time-to-Market TTM
- Контроль внешних библиотек и используемых компонент
- Повышения репутационного уровня и развития конкурентноспособности, в связи с нынешней ситуацией на рынке РФ
- Оптимизации решений по Secure SDLC
- Выполнение требований к проектам, минимизации потерь при разработке

Основная цель

Использование лучших практик по организации защиты информации и периметра, выстраивание процессного подхода и повышения Servise Relationships Management. Делаем потому что может дать снижение ФОТ на устранение сработок, а также сократить показатели прерывания процессов на тестирования ИБ до 20%.

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

- TTM разработанного функционала
- Повышения уровня осведомленности сотрудников
- Развитие гильдии Security Champions
- Повышения взаимодействия внутри команд разработки и ИБ
- Внедрение контроля разработки на всех стадиях жизненного цикла
- Оптимизация операционно-технических процессов
- Расследование инцидентов и проведение проверок по устранению последствий
- Выработка мер реагирования и стандартизации процесса (DMAIC)
- Повышение уровня зрелости DASA DevOps практик
- Application Security Testing Orchestration
- Shift-Left-подход и Secure-by-Design

Итого: это может дать возможность роста и развития направления по DevSecOps, что позволит повысить уровень риск-менеджмента и нивелирования возможных инцидентов со стороны разработки ПО, как in-house, так и от вендоров. Аналогично может дать возможность повышения уровня TTM в безопасном исполнении. Может позволить контролировать SDLC и далее обеспечить Secure SDLC

Это позволит в условиях текущей ситуации на рынке обеспечить с ростом вовлечения в процесс безопасность выпускаемых функциональных и не функциональных features. Это позволит контролировать средствами AppSec как триггеров выпускаемых features в PROD и автоматизации процессов ИБ.

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

#devsecops #appsec #toolchain #pmi #specialty #riskanalys #techsolution

🛠 .dockerignore: игнорирование при сборке образа

Салют,
Мы с тобой смотрели принцип игнорирования для .gitignore вот тут, а сейчас посмотрим принцип для .dockerignore. То есть мы посмотрим, что позволяет игнорировать docker при сборке образа.

Игнорирование аналогично .gitignore:

- Уменьшает размер
- Ускоряет сборку
- Повышает безопасность при правильных ограничениях и использования аналогов по типу хранения артефактов в packages

В .dockerignore это правила, которые поддерживают пути, шаблоны, инверсии исключений:
- Пути и файлы: some_docs/
- Шаблоны: *.log
- Игнорирование: `!config/default.json

dockerignore:

node_modules
build/
*.log // игнорирование всех логов
.env 
!.env.example // оставляем конкретный артефакт

Как собирать:

docker build -t with_ignore -f Dockerfile .
docker run --rm with_ignore

Итого: выводы аналогичны .gitignore, но шире, так как сборка уже выходит дальше, чем git repo. Для генерации данного файла существуют онлайн сервисы, на подобии этого dockerignore-generator. Автогенераторы позволяют обще собрать шаблон файла. Кстати, для helm-чартов аналогично используется по такому же принципу helmignore.

#toolchain #reco

Отлично звучит, в наших реалиях, для стартапа

#lol

🥶 DMAIC: как система ценности для оптимизации

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

Поговорим давай про систему для оркестрации хауса ИБ в процессах разработчиков. Я часто использую в своих выражениях обороты связанные с профильными штуками. Мы же с вами все имеем профессиональную деформацию, вот и я в свое время получив сертификацию DASA DevOps Product Manager начал обращать больше внимание на это.

В процессах разработки и отработке уязвимостей часто слышу:

- «Надо оптимизировать пайп, он с тормозами катится»
- «Снизить фолсы иначе снова будут вопросы»
- «Эти уязвимости не эксплуатируются, докажи нам»
- «Давай в технический долг и потом разберем»
- «Зачем нам этим заниматься? Мы же обновляемся»
- «Памагите» (😂)

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

Когда нет структуры, такие задачи превращаются в бесконечный рефакторинг ради рефакторинга, ну то есть "работа ради работы. На фоне этого нам надо оптимизировать бизнес-процессы, повысить качество и эффективность, а также минимизировать издержки.

Следовательно, DMAIC

Подход, используемый в управлении производством. Он позволяет последовательно решать проблемы и совершенствовать бизнес-процессы с помощью количественно-качественных метрик. Проверенная модель из

Lean Six Sigma,

которую можно отлично применять в DevSecOps.

Модель:

D — Define (Определи

ть

)

- сначала формулируем проблему и цель. Например: “сократить ложные срабатывания SAST на 30% без потери покрытия”

M — Measure (Измерить)

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

A — Analyze (Проанализировать)

- находим первопричины, где точка сбоя — инструмент, конфигурация, процесс триажа или вовсе человеческий фактор и тд

I — Improve (Улучшать)

- внедряем изменения: обновляем правила, автоматизируем, добавляем callback-actions, оптимизируем job анализаторов, пишем политики, модернизируем пайплайн и тд

C — Control (Контроль)

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

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

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

DMAIC помогает переводить улучшения из «кажется, стало лучше» в измеримую практику. Работает для чего угодно: от настройки пайплайнов до зрелости AppSec-процессов.

#pmi #devsecops #riskanalys #roadmap

Когда собираешь с нуля все вокруг себя

#lol #кулуарка

🤔 Kaizen Event: +10/10 к эффективности

Салют,
Ранее мы с тобой посмотрели, что такое DMAIC.

Теперь нам следует рассмотреть специальный инструмент используемый для достижения этой цели. Скажу так, что это классный инструмент, который можно использовать на практике, а также есть в нем тонкость, его можно использовать для исскуственных конфликтов.

Да, все правильно, для искусственных конфликтов тоже идеально подходит. О чем я говорю? Как часто ты сталкиваешься с проблемами эскалаций, задержек и простого "не хочу". Так вот, если это использовать в правильным русле и с корректным подходом, то это позволит достичь поставленной цели без каки-либо негативных последствий.

Перед этим, предлагаю вспомнить, что такое DMAIC:

Подход, используемый в управлении производством. Он позволяет последовательно решать проблемы и совершенствовать бизнес-процессы с помощью количественно-качественных метрик

Следовательно, все мы знаем и слышали много раз, про вещи, которые меняют культуру (можно сказать так, что мы говорим, а по сути никто не дает тебе что-то рабочее) внутри команды и компании, и ты можешь на это повлиять, только я даю тебе инструмент и прошу быть аккуратным с ним. Кстати не только метрики позволяют дать оценки роста и решение проблем.

Почему мы на это смотрим?

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

Kaizen Event — как раз про достижения результатов и изменений, которые реально эффективны и дают показатели в которкий срок.

По сути это сфокусированный спринт улучшений, когда команда на несколько дней ставит мир на паузу, чтобы сделать один конкретный процесс лучше. Не «оптимизировать всё», а убрать реальную

Как это работает

- Выбираем точку боли: что мешает чаще всего? проблема повторяющихся уязвимостей из-за откатов версий? Фолсы? Вечная очередь при сканированиях? By-pass критериев качества ИБ? Берём самое раздражающее место — туда и бьём

- Измеряем текущее состояние на количественно-качественных характеристиках: среднее время проверки сборки — 19 мин. Хотим 12. Либо долгий триаж уязвимостей - автоматизируем контроль показателей ASPM и делаем уникальные политики для проекта

- Разбираем корневую причину: почему так происходит? Процесс? Не понимание того, что делают? Выпиливание инструментов? Здесь рождаются инсайты, а также видим уже что фиксить и идем договариваться

- Делаем улучшение сразу без бесконечных тикетов и совещаний.
Собрались → сделали → проверили

- Закрепляем результат, как пример создаём новый стандарт, метрику, автоматизацию и ид — чтобы улучшение не растворилось через месяц

Почему Kaizen Event реально работает?

- Фокус на конкретной боли, а не на всём подряд
- Быстрый результат → растёт вовлечённость
- Команда чувствует, что может менять систему и они что то значят, ростут их компетенций и соответствующий кост, а не просто “работать по процессу”

Такие Kaizen-сессии отлично заходят на темах вроде:

- Сокращение времени проверки пайплайна и получение callback от анализаторов с результатов по метаданным типа количество плотности уязвимостей
- Оптимизация правил для SAST/ SCA, автоматизация сценариев для DAST и иное
- Ускорение триажа фолсов исходя из группировки
- Анализ рисков по уязвимостям, которые реально аффектят систему
- Настройка фидбека между безопасниками и разработкой
- Внедрение Security Champions и процессов DevSecOps

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

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

#pmi #devsecops #riskanalys #roadmap #pmcases #humanres

🥶 DevSecOps и сертификация CI/CD по ГОСТ 56939

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

На сейчас пока я хотел бы поделиться одной из болей, которую обсуждали в сообществе findevsecops.ru @fintechassociation, а именно мы поговорим про сертификацию.

Зачем бизнесу?

- Экономия ресурсов — исправлять уязвимости на ранних этапах дешевле и проще
- Снижает риски инцидентов, в следствии потенциального прямого и косвенного урона в виде финансовых потерь, то есть повышает доверие к компании на рынке
- Защищенность ПО от уязвимостей и киберугроз, то есть как и на каких этапах учитывать ИБ
- Развитие сотрудников и качества, стабильности разработки, то есть повышает конкуретноспособность
- Важна при работе с государственным сектором и крупными заказчиками от их требований, если компания разрабатывает или вносит изменения в СЗИ, а также работает с объектами КИИ, ГИС и/или ИСПДн
- Стандарт помогает быстро и уверенно проходить контроль со стороны заказчиков и/или независимых аудиторов
- Подтверждает, что процессы отвечают требованиям к защищённой разработке (если проходим 2024 и не просто закрываемся бумажками в большей части ИСП РАН спрашивает конкретику, но все мы знаем как проходит сертификация)

Основные поинты согласно приказу 240

- Орган по сертификации ИСП РАН: в порядке расписаны сроки,
где большую часть времени занимает работа по сертификации
- Заявка с указанием основной информации и приложение
с руководством безопасной разработке во ФСТЭК России
- Сертификация проводится на базе изготовителя с проверкой соответствия, в том числе оценка документации и оборудования
- Заключение о соответствии процессов (Заявка на рассмотрении в течение 15 рабочих дней):
-- При несоответствии, изготовитель устраняет их и уведомляет для повторной сертификации. 
-- При соответствия подготавливается проект сертификата, который рассматривается ФСТЭК России.

Ключевые маркеры ГОСТ 56939-2024

- Стандарты ГОСТ 56939 и ГОСТ 15408 являются основой для подтверждения безопасности процесса разработки
- Сертификат выдается компании, а не только на конкретное приложение
- Сертификация действует до 5 лет и может охватывать не один, а несколько продуктов, - все компоненты, зависимости, библиотеки и инструменты, участвующие в разработке
- Органы сертификации могут в любой момент проверить произвольное приложение из конвейера или готовый продукт. Это исключает возможность «подготовить только один проект для отчёта».
- В фокусе — не только код, но и сам процесс: сборка, тестирование, управление версиями, деплой. Проверка может охватывать сразу несколько CI/CD конвейеров, используемых в организации.
- Формальные документы (процедуры, политики, регламенты) должны соответствовать тому, как на самом деле устроен процесс разработки.
- Все программные компоненты и артефакты (исходники, библиотеки, сборки) должны храниться в проверенном и контролируемом хранилище, чтобы обеспечить воспроизводимость и защищённость.
- Сертификацию начинают с конкретного продукта, и только затем переходят к оценке самого процесса разработки. Исключения возможны, но крайне редки.
- Продукты и процессы должны быть связаны с конкретными техническими требованиями и угрозами. Это фиксируется в проектной документации и проверяется на соответствие.
- Для сертификации потребуется собрать более 100 требований и подтвердить их выполнением через ~120 артефактов — это технические документы, тесты, отчёты, описания процессов и систем.

Итого: по ГОСТ 56939-2024 становится более внятным, каждый день, что требуется от людей и каким образом это влияет на бизнес, так как уровень активностей связанных с инфобезом и последствиями их отсутвтия влияют не просто на работу структур, а именно на возможность монетизации, самой unit-экономики продуктов. Поэтому посмотрев это мы можем примерно понять ценность, а по факту явных требований не видели, только рекомендации в большинстве случаев от регулятора (либо я просто слепой)

#devsecops #pmi #specialty #gost #compliance