TL, д-р
В последние годы технологическая индустрия горячо отстаивает концепцию «сдвига влево» в разработке программного обеспечения, выступая за скорейшую интеграцию методов обеспечения безопасности в жизненный цикл разработки. Это движение направлено на то, чтобы дать разработчикам ответственность за обеспечение безопасности их кода с самого начала проекта. Однако, хотя намерения, стоящие за этим подходом, благородны, реальность рисует более тонкую картину — ту, в которой упрощенное представление о том, чтобы полагаться исключительно на разработчиков, будет поддерживать их. безопасность цепочки поставок программного обеспечения оказывается неадекватным. В этой статье я представлю дополнительный балансирующий подход: ограждения SDLC, управляемые CISO – автоматические меры контроля, которые управляют или обеспечивают соблюдение политики безопасности SDLC.
Кто оставил мой сыр?
Парадигма сдвига влево, по сути, направлена на решение проблем безопасности на начальных этапах разработки, ожидая, что разработчики будут активно встраивать меры безопасности в свой код. Это привлекательная идеология, согласно которой перед разработчиками стоит задача выявлять уязвимости и внедрять меры безопасности по мере написания и развертывания своего кода.
Однако этот идеалистический подход сталкивается с серьезными проблемами при практической реализации. Несмотря на то, что разработчики хорошо разбираются в программировании, им может не хватать всесторонних знаний в области методов обеспечения безопасности и передовых практик. Их основное внимание сосредоточено на удовлетворении функциональных требований, и ожидать от них исчерпывающего понимания постоянно меняющегося ландшафта кибербезопасности нереально.
Кроме того, временные ограничения и давление проекта часто приводят к компромиссу между безопасностью и соблюдением сроков. В спешке с оперативным предоставлением функций разработчики могут непреднамеренно упустить из виду потенциальные лазейки в безопасности или использовать менее безопасные методы кодирования, оставляя уязвимости неустраненными до более поздних этапов. В конце концов, их ключевые показатели эффективности ориентированы на скорость, и для большинства из них безопасность всегда будет на втором месте.
Введите ограничения CI/CD
Именно здесь становится очевидной необходимость внедрения «защитных ограждений» в конвейере непрерывной интеграции/непрерывного развертывания (CI/CD). Ограждения действуют как автоматические контрольные точки, встроенные в конвейер разработки, гарантируя, что меры безопасности не будут зависеть исключительно от ручного вмешательства, опыта или мотивации отдельных разработчиков.
Guardrails выполняют роль упреждающих контролеров, постоянно отслеживая и обеспечивая соблюдение стандартов, политик и правил безопасности на протяжении всего жизненного цикла разработки программного обеспечения (SDLC). Эти автоматические проверки могут охватывать различные аспекты безопасности, включая, помимо прочего, внесение в черный список плохих пакетов, остановку кода, который содержит критические уязвимости, не проходит тесты статического анализа кода или имеет проблемные зависимости, а также соблюдение стандартов соответствия или политики безопасности SDLC (например, код просмотр каждого коммита).
Используя концепцию «политика как код», можно создать практически любое правило, которое можно реализовать в качестве ограждения. Вот несколько примеров правил ограждений в соответствии с НИСТ 800-204D:
Примерные правила ограждений:
- Рабочая станция разработчика
- Проверка комплекта безопасности конечных точек рабочей станции разработчика
- SCM
- Проверка правил защиты ветвей: принудительное выполнение нескольких конкретных проверок
- Убедитесь, что файлы CI изменяются только разрешенным персоналом.
- Убедитесь, что секретное сканирование установлено и секреты не обнаружены.
- CI
- Убедитесь, что сканирование кода выполнено.
- Убедитесь, что результаты сканирования кода находятся под заранее заданной полосой.
- Зависимости
- Проверьте лицензию открытого исходного кода.
- Убедитесь, что уязвимости с открытым исходным кодом соответствуют политике организации.
- Артефакты
- Убедитесь, что артефакты подписаны правильным идентификатором.
- Проверьте финальные уязвимости артефакта.
Ограждения, а не поручни
Интегрируя защитные меры в конвейер CI/CD, организации могут систематически применять протоколы безопасности и создавать безопасный продукт, не полагаясь исключительно на разработчиков для обеспечения комплексных мер безопасности. Принимая во внимание, что разработчики могут обходить меры безопасности ради темпов разработки, подход ограждений делает эти решения невозможными или, по крайней мере, видимыми, поэтому их можно принять во внимание – как на уровне отдельной сборки (например, принять решение о надежности артефакта ) и на организационном уровне (понимание того, чего можно и чего нельзя ожидать от разработчиков организации). Автоматизированные инструменты могут отмечать или даже блокировать потенциальные уязвимости или проблемы несоответствия до того, как новая версия будет выпущена в производство или доставлена клиенту. В конце концов, решить проблему безопасности на этапе разработки, а не после поставки, действительно гораздо проще, быстрее и дешевле.
Крайне важно осознавать, что хотя сдвиг влево и поощряет участие разработчиков в практике обеспечения безопасности, он не должен освобождать других заинтересованных сторон — специалистов по безопасности, инженеров DevOps и команд обеспечения качества — от их ролей. Если вы занимаетесь безопасностью продуктов, AppSec, DevSecOps или CISO, то вы уже знаете, что «смещение ответственности влево» на разработчиков не снимает ответственность с ваших плеч. Поскольку большинство директоров по информационной безопасности и их команды не занимаются исследованиями и разработками, среды разработки программного обеспечения исторически находились вне их поля зрения. Традиционно они фокусируются на операционной безопасности, сетевой безопасности и межорганизационной связности. Подход «ограждения» — это способ «деликатно» вывести директоров по информационной безопасности на дикий запад среды разработки, вернув им контроль над тем, за что они отвечают.. Под «деликатно» я подразумеваю «совместно». Поскольку безопасность продукта — это совместная работа команд безопасности и разработчиков, сотрудничество между этими организациями имеет важное значение при проектировании и внедрении надежных защитных ограждений, которые защищают конвейер CI/CD от потенциальных угроз безопасности, не снижая при этом скорость разработки.
Интеграция смещающихся левых принципов с установлением барьеров в конвейере CI/CD является хорошим балансом. Разработчики по-прежнему несут ответственность за написание безопасного кода и понимание основных принципов безопасности, в то время как команда безопасности определяет стандарты, которым должен соответствовать продукт для выпуска. Затем защитные ограждения соответствующим образом автоматизируются в инструменты и процессы, которые действуют как сеть безопасности, постоянно отслеживая и укрепляя стандарты безопасности и политику SDLC. Ограждения — это важный шаг на пути к продуктам, которые безопасны по своей конструкции и по умолчанию.
Подводя итог
В заключение, несмотря на благие намерения, концепция сдвига влево не обеспечивает комплексную безопасность программного обеспечения исключительно за счет участия разработчиков. Чтобы повысить целостность и надежность конечного программного продукта, организации должны внедрить защитные ограждения в конвейере CI/CD. Такой комбинированный подход не только повышает уровень безопасности программного обеспечения, но и способствует созданию среды сотрудничества, в которой разработчики, специалисты по безопасности и инструменты автоматизации синергетически работают над достижением общей цели — создания безопасного программного обеспечения.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
