Обеспечение безопасности вашей цепочки поставок программного обеспечения начинается с обнаружения и управления вашей «фабрикой программного обеспечения»
В современной среде разработки ПО команды работают с децентрализованными активами, такими как репозитории кода, конвейеры сборки и образы контейнеров. Хотя эта распределенная модель обеспечивает гибкость и ускоряет производство, она также фрагментирует активы и усложняет управление и контроль безопасности, особенно по мере того, как облачные приложения становятся все более распространенными.
В результате команды по безопасности часто теряют драгоценное время, отслеживая владельцев кода для бесхозных производственных рабочих нагрузок, когда возникают проблемы безопасности или когда несанкционированные программные артефакты попадают в производство. Цепочка поставок программного обеспечения стала критической поверхностью для атак, и важно собирать сигналы безопасности на ранних этапах — от разработки до сборки — чтобы избежать слепых зон и гарантировать, что все активы на протяжении жизненного цикла разработки программного обеспечения (SDLC) контролируются.
Команды DevSecOps обычно не имеют автоматизированных инструментов для постоянного отображения этого меняющегося ландшафта разработки, где часто вводятся новые пути кода и инструменты. Информация часто остается разрозненной на разных платформах, что затрудняет доступ к ней в целях безопасности. Платформы и инструменты разработки часто различаются на этапах разработки, интеграции и развертывания по мере продвижения программного обеспечения по этапам.
Хотя поставщики решений по управлению безопасностью приложений (ASPM) и наблюдаемости объединяют результаты сканирования безопасности, они часто не обеспечивают полного представления, связывающего пути кода с производством.
Наличие устаревших активов усугубляет проблему. Определение того, какие репозитории все еще активны в производстве, может быть непосильной задачей, особенно для крупных организаций. Слияния и поглощения еще больше усложняют ситуацию, добавляя различные платформы и стандарты разработки.
Команды DevSecOps часто прибегают к ручным процессам, таким как заполнение манифестов или маркировка контейнеров, что утомительно, подвержено ошибкам и часто отходит на второй план в пользу более срочных задач.
Подумайте об этом как о защите постоянно меняющегося поля боя, где командам безопасности нужна точная карта для защиты своих активов. Эти активы постоянно движутся в процессе разработки, и новые цели должны быть идентифицированы и защищены. Для решения этой проблемы требуется непрерывный механизм обнаружения для картирования изменений по мере их возникновения.
Лучшие практики и фреймворки поддерживают этот подход. Например, Агентство кибербезопасности и безопасности инфраструктуры (CISA) обязывает организации проверять происхождение компонентов программного обеспечения и вести полную инвентаризацию в рамках своей деятельности процесс самоаттестации, Аналогичным образом, NIST Secure Software Development Framework (SSDF) и Модель зрелости DevSecOps OWASP (DSOMM) подчеркивают важность постоянного обнаружения и видимости.
В оставшейся части этой статьи мы изложим план решения этих проблем и рассмотрим, как Scribe Security помогает организациям эффективно реализовать эти возможности.
План эффективного открытия от писца
Discovery генерирует карту, смоделированную в графе, предоставляя обзор активов, взаимосвязей и состояния безопасности вашего завода. Это позволяет:
- Полная прозрачность и контроль собственности.
- Расширенные возможности запросов.
- Мониторинг ключевых показателей эффективности и показателей зрелости безопасности.
- Более быстрое выявление и определение приоритетности факторов риска.
- Начальное сканирование
Первоначальное сканирование направлено на создание высокоуровневой карты активов, фокусируясь на выявлении тех, которые требуют дальнейшего анализа. Полное глубокое сканирование может занять много времени, и многие активы, например, не связанные с производством или устаревшие, могут быть неактуальны. Это первоначальное сканирование обычно собирает основные данные, такие как имена репозиториев, идентификаторы и статистику активности, но не включает полный список коммитов или участников.
Один из методов — сканирование «справа налево». Получая доступ к производственным средам (например, через API кластера K8s), сканер может идентифицировать работающие образы контейнеров — критически важные активы, отражающие ценность бизнеса. Оттуда сканирование отслеживает реестр контейнеров и соответствующие репозитории. Сканирование обычно останавливается здесь, поскольку обычно нет прямой связи между реестром и предыдущим конвейером SDLC.
Дополнительные сканирования можно запускать «слева направо», выявляя репозитории кода, конвейеры сборки и реестры на разных этапах SDLC (например, разработка, интеграция, тестирование).
Результатом является список приоритетных активов на всех платформах, готовый к глубокому сканированию для отслеживания родословной от кода до производства и оценки состояния безопасности SDLC. Приоритезация основана на таких факторах, как релевантность производству, уровень активности и новизна. Иногда институциональные знания о значимости активов помогают направлять этот процесс.
Первоначальное сканирование может быть запланировано периодически или вызвано событиями, такими как отправка кода. Последующие сканирования могут применять автоматические критерии выбора, такие как использование глобусов для глубокого сканирования недавно обнаруженных активов.
- Глубокий анализ
После того, как соответствующие активы расставлены по приоритетам, глубокое сканирование собирает подробные атрибуты, которые устанавливают связи между активами, такие как идентификаторы ветвей, идентификаторы коммита и коммитера, а также идентификаторы запуска конвейера. Продолжительность этого сканирования может варьироваться в зависимости от области действия активов и ограничений скорости API.
К концу этого этапа начинает формироваться граф взаимосвязи активов с кластерами связанных активов вокруг репозиториев кода (содержащих информацию о сборке) и сред выполнения (с активами реестра). Однако полная родословная все еще неполна, поскольку реестры обычно не хранят информацию о конвейерах, которые проталкивают артефакты сборки.
- Соединение кластеров
После того, как инвентаризация установлена, родословную можно завершить, инструментируя инструмент CLI в конвейере для сбора сведений о происхождении сборки или обрабатывая журналы CI. Инструментирование является самым надежным методом, записывающим ключевые атрибуты, такие как идентификаторы репозитория кода, идентификаторы конвейера и запуска, а также идентификаторы образов. Он эффективно связывает ранее изолированные кластеры и создает полную сквозную родословную от кода до производства.
Дополнительным подходом является обработка журнала CI, которая извлекает соответствующие атрибуты, но требует больше ресурсов и зависит от существующего журнала. Хотя этот метод предлагает более быструю реализацию, объединение обоих подходов дает наилучшие результаты — инструментирование критических конвейеров и использование анализа журнала для недавно обнаруженных, которые затем можно оценить для дальнейшего инструментирования.
Этот подход к кластеризации также предполагает объединение отдельных линий в единую структуру для сложных продуктов, таких как веб-приложения, состоящие из нескольких компонентов, например, микросервисов.
- Спецификация программного обеспечения (SBOM)
До этого момента основное внимание уделялось соединению активов разработки на разных платформах, устанавливая четкую родословную от кода до производства для соответствующих активов. Теперь внимание переключается на состав самих программных артефактов. На этом этапе SBOM генерируется из этих артефактов и связанных с ними репозиториев кода, добавляя их в существующий инвентарь.
Благодаря синтезу репозитория кода и артефактных SBOM в единую SBOM с логикой для корреляции зависимостей и исключения ненужных, таких как библиотеки разработки и тестирования, результатом является более точная и полная SBOM, чем любой из источников мог бы предоставить по отдельности.
- Состояние безопасности и ключевые показатели эффективности DevSecOPs
Постоянное отображение инвентаря активов и их взаимосвязей дает наилучшую возможность оценить состояние безопасности этих активов. Ключевые факторы включают разрешения на доступ для человеческих и нечеловеческих идентификаторов, проверку подписи кода, рискованные или уязвимые зависимости и настройки безопасности на различных платформах и счетах.
Эти данные можно объединить в различные измерения для измерения KPI для выпусков продуктов, времени развертывания в производстве и зрелости DevSecOps. В частности, это позволяет командам оценивать принятие мер безопасности, таких как подписание кода и соблюдение настроек безопасности, помогая отслеживать прогресс и обеспечивать надежные методы безопасности.
- Визуализация и запросы к SDLC и графику цепочки поставок программного обеспечения
Одним из ключевых преимуществ процесса обнаружения является возможность визуализировать цепочку поставок SDLC и программного обеспечения в виде динамического графика или «карты сражений». Такая визуализация обеспечивает комплексное представление всего жизненного цикла разработки, упрощая отслеживание активов и их взаимосвязей.
Настоящая сила заключается в возможности запрашивать график, что позволяет командам задавать важные вопросы, например:
- «Какой компонент не прошел проверку безопасности во время сборки или развертывания?»
- «Какие рабочие нагрузки в производстве остаются неиспользуемыми?»
- «Кто внес изменения, приведшие к уязвимости?»
- «Кому принадлежит актив, который необходимо исправить?»
Запросы по родословной помогают командам определить первопричину проблем, что является явным преимуществом по сравнению с ручной документацией. Поддерживаемые вручную сопоставления прав собственности быстро устаревают, что часто приводит команды DevSecOps к неэффективным поискам нужных заинтересованных сторон. Напротив, запрашиваемый граф гарантирует, что права собственности и подотчетность всегда актуальны, сокращая время, затрачиваемое на отслеживание ответственности за код или инфраструктуру.
- Варианты развертывания инструментов обнаружения
Организации имеют различные потребности в развертывании инструментов обнаружения, и предоставление гибких вариантов развертывания необходимо для удовлетворения различных требований безопасности. Некоторые команды предпочитают удаленный доступ через платформу SaaS, упрощая управление и масштабирование. С другой стороны, команды с более строгими протоколами безопасности могут выбрать локальное развертывание сканера для поддержания более строгого контроля над конфиденциальными учетными данными, такими как токены API платформы разработки. Выбор между SaaS и локальным развертыванием зависит от таких факторов, как состояние безопасности организации, потребности в соответствии и контроль над данными.
Заключение
Обеспечение безопасности вашей цепочки поставок программного обеспечения — это постоянная битва; ни одна организация не должна вступать в нее без четкой карты. Внедряя надежный процесс обнаружения, вы получаете полную видимость по всему вашему SDLC и цепочке поставок, гарантируя, что каждый актив учтен, от разработки до производства. С такими инструментами, как план Scribe Security, вы можете построить связанную родословную, сгенерировать точные SBOM, оценить состояние вашей безопасности и визуализировать критические отношения в вашей экосистеме разработки. Этот уровень понимания позволяет командам DevSecOps быстро выявлять уязвимости, отслеживать их происхождение и поддерживать актуальное понимание своего программного ландшафта — что необходимо для того, чтобы оставаться впереди в сегодняшней быстро меняющейся и сложной среде разработки.
Писец предлагает комплексное решение для обнаружения и управления как важнейшего инструмента обеспечения безопасности вашей цепочки поставок программного обеспечения:
- Первоначальное и глубокое сканирование – Определяет и приоритизирует активы, такие как репозитории кода, конвейеры и образы контейнеров в разных средах, создавая инвентарь соответствующих компонентов.
- Непрерывная родословная – Объединяет изолированные кластеры активов с помощью инструментов CLI и журналов CI, формируя полную линию связи от кода до производства.
- Спецификация программного обеспечения (SBOM) – Генерирует точные SBOM путем синтеза данных артефактов и репозитория, исключая ненужные зависимости.
- Оценка состояния безопасности – Постоянно оценивает контроль доступа, сигнатуры кода и уязвимые зависимости для измерения ключевых показателей эффективности безопасности.
- Визуализация и запросы – Визуализирует весь SDLC и позволяет выполнять запросы для отслеживания уязвимостей, потерянных рабочих нагрузок и владения активами.
- Гибкое развертывание – Поддерживает как SaaS-, так и локальные развертывания для удовлетворения различных потребностей в безопасности и контроля конфиденциальных данных.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
