Разработка программного обеспечения — это практика, которой занимается все больше и больше людей во всем мире. Существуют как компании, так и частные лица, создающие программное обеспечение, некоторые из которых являются проприетарными, некоторые бесплатными или с открытым исходным кодом, а некоторые представляют собой объединение того и другого. Поскольку угрозы безопасности пользователей или их программного обеспечения не материализуются из эфира, как только что-то объявляется завершенным и отправляется в производство, кажется, самое время поговорить о методах обеспечения безопасности, которые помогут управлять рисками безопасности, которые могут проникнуть в производство. ваше программное обеспечение в процессе разработки. Существует несколько структур SSDLC (Secure Software Development Life Cycle), в том числе от OWASP, CISA и NIST (ССДФ). В этой статье мы позаимствуем кое-что у них всех, чтобы выделить несколько практик, направленных на то, чтобы помочь вам управлять рисками, присущими разработке программного обеспечения. Не живите с чувством ложной безопасности, думая, что с вами этого не может случиться. Полугодовой отчет Check Point по кибербезопасности за 2023 год показывает рост глобальных кибератак на 8%. в течение 2022 года, и эта тенденция, похоже, не изменится.
Каков жизненный цикл разработки программного обеспечения?
Разработчики программного обеспечения стремятся создавать программное обеспечение быстро, точно и безопасно. Конечно, вы не всегда можете получить все три. Со временем процесс разработки был разделен на несколько отдельных этапов, которые подходят для любой разработки программного обеспечения. Эти фазы можно разделить на:
- Анализ требований – что мы собираемся строить и почему
- Планирование – как мы собираемся это строить в общих чертах
- Разработка программного обеспечения – как мы собираемся его строить в конкретных терминах, таких как архитектурный дизайн
- Разработка программного обеспечения — написание и компиляция программного обеспечения
- Тестирование - убедиться, что все работает так, как запланировано
- развертывание – отправьте или опубликуйте его, чтобы конечный пользователь мог его использовать
Есть еще несколько версий этого цикла, но в целом они очень похожи. Важно помнить, что цикл не является разовым: обычно он не заканчивается после отправки клиенту или публикации в облаке. Почти всегда возникают проблемы, с которыми вам нужно разобраться, и которые могут потребовать перепроектирования (возвращения к исходной точке), ошибок, которые нужно исправить, функций, которые вы хотите добавить, и так далее. Вы также можете работать над несколькими этапами параллельно или останавливаться на середине шага, чтобы вернуться назад. Поскольку ни один из шагов по своей сути не ориентирован на безопасность, это заставляет систему безопасности постоянно догонять процесс разработки, а при сегодняшних лихорадочных скоростях разработки этого недостаточно.
Важность защиты вашего SDLC
Разработка безопасного программного обеспечения направлена на учет вопросов безопасности на всех этапах процесса, а не как на дополнение к процессу. Таким образом, безопасность всегда должна учитываться независимо от того, на каком этапе процесса вы работаете: обдумываете требования проекта, планируете архитектуру, учитываете необходимые строительные блоки и инфраструктуру и садитесь за разработку кода. Этот подход иногда называют безопасность со сдвигом влево подхода.
Здесь сдвиг влево означает распределение проблем безопасности на протяжении всего процесса разработки и вовлечение разработчиков в проектирование, реализацию и тестирование безопасности.
Разработчикам, которые никогда по-настоящему не задумывались о проблемах безопасности, может быть страшно внезапно столкнуться с этим. Значительно легче справиться, если требования разделены на несколько четко определенных передовых практик. Вы можете думать об этом как о покупке новой IDE.
Чем более четко определены требования и чем больше средств автоматизации и комплексных инструментов вы можете использовать, тем проще станут задачи.
Лучшие практики безопасности SDLC
Вот несколько рекомендаций, которые помогут вам защитить процесс разработки в произвольном порядке:
Обучение – Многие разработчики будут чувствовать себя неспособными справиться с задачей применения соображений безопасности и тестирования кода, который они пишут. Большинство разработчиков знают, что попадание испорченных входных данных в ваш сервер может привести к удаленной активации кода, что очень похоже на известные «таблицы удаления». Однако меньше людей знакомы с тестированием переполнения буфера или сканированием уязвимостей на предмет третичных (или дальнейших) зависимостей. Разработчики могут закрыть эти пробелы в знаниях с помощью обучения. Разработчики лучше подготовлены к включению проблем безопасности в ежедневное программирование и тестирование, если они имеют более глубокое понимание проблем безопасности и потенциальных уязвимостей. Разработчику, который написал код и хорошо знаком с его функциями, также имеет гораздо больше смысла учитывать пробелы в безопасности и соответствующим образом планировать тестирование.
Сканирование – Вы можете использовать множество типов сканирования, чтобы сделать ваш код в целом более безопасным. Статический, динамический и интерактивный анализ — вот лишь некоторые из них. Статический анализ ищет очевидные ошибки кодирования или возможные уязвимости безопасности в исходном коде. Его можно использовать для поиска потенциальных уязвимостей, небезопасных методов написания кода и нарушений стандартов кодирования. Он не учитывает события времени выполнения, поскольку проверяет только синтаксис кода. Динамический анализ ищет любые недостатки безопасности, ошибки кодирования и другие проблемы в приложении во время его работы. Его можно использовать для выявления утечек памяти, некачественных операций и, возможно, нестабильных входных данных или процессов. Имейте в виду, что, поскольку этот тип тестирования проводится в определенное время с использованием определенных входных данных, качество тестов полностью зависит от людей, которые их разработали. Цель состоит в том, чтобы обнаружить проблемы до того, как это сделают ваши пользователи. Интерактивный анализ проверяет приложение на наличие потенциальных недостатков безопасности и других критических проблем. Он может искать возможные уязвимости, проблемы с удобством использования и проблемы с пользовательским интерфейсом. Чем более комплексные инструменты сканирования вы используете, тем лучше вы защищены, но компромисс, конечно, заключается в скорости разработки. Поскольку каждое приложение уникально, вам предстоит найти баланс между нужным объемом сканирования и желаемой скоростью разработки. Кроме того, мы рекомендуем создать полный SBOM вашего приложения и применять к этому источнику данных различные сканирования и отчеты. Наличие наследия SBOM вашего приложения — хороший способ сохранить очень подробную информацию о компонентах и пакетах, которая может оказаться неоценимой по многочисленным причинам безопасности.
Кодовые обзоры – Проверка исходного кода на предмет каких-либо недостатков безопасности, ошибок в кодировании и других недостатков программного обеспечения до его объединения с активной ветвью разработки называется проверкой кода. Обычно эту проверку проводит разработчик, обладающий большим опытом, чем тот, кто написал код. Такие проверки могут помочь гарантировать, что код написан хорошо, а приложение безопасно. Кроме того, они поддерживают соблюдение единого стандарта и соглашений о кодировании (таких как имена функций и переменных) во всей базе кода.
Разрешить интеграцию кода в основную ветку после того, как его проверят как минимум две пары глаз, считается лучшей практикой. Разработчик, написавший код, — это, конечно, первая пара глаз. Даже высококвалифицированным инженерам, например руководителям групп, может быть полезно, чтобы кто-то другой оценил их код. По крайней мере, это гарантирует, что с каждым разделом кода будет знакомо более одного человека. Имейте в виду, что во время сильного стресса или критической ситуации люди могут подумать об отказе от этого элемента. Если возможно, рассмотрите возможность добавления этого правила в качестве жестко запрограммированного элемента вашего CI/CD, чтобы его нельзя было обойти.
Тестирование – Нам не нужно говорить вам, насколько важно тестировать ваш код, чтобы обнаружить недостатки безопасности до того, как они станут проблемой. Большинство проектов кода сложны и взаимосвязаны, поэтому невозможно предугадать, как один-единственный небольшой пробел может в конечном итоге повлиять на безопасность всей кодовой базы.
При написании автоматических тестов учитывайте функциональность недавно созданного кода, а также любые существенные взаимодействия серверной и клиентской частей с другими частями базы кода.
Такие уязвимости, как SQL-инъекция, межсайтовый скриптинг, небезопасное хранение данных и неадекватное распределение памяти (что может привести к переполнению буфера), являются примерами проблем безопасности, которые обычно устраняются при тестировании. Тестирование должно устранять утечки памяти, низкую или ненадежную производительность и удобство использования. Тестирование должно быть автоматическим и интегрированным в конвейер CI/CD, чтобы ни одна новая версия или обновление не могли быть опубликованы без прохождения как модульных, так и интеграционных тестов.
Независимая проверка на перо – Никто не может продумать все, и у нас, как у разработчиков, иногда возникают «слепые пятна» в отношении написанного нами кода. Подобно проверке кода, независимое тестирование на проникновение позволяет применить свежий подход и по-новому взглянуть на то, что мы сделали, и меры предосторожности, которые мы приняли для защиты нашего приложения и наших пользователей. Такие тесты рекомендуется проводить не реже одного раза в год и должны включать оценку инфраструктуры, а также уязвимостей приложений.
Безопасно используйте открытый исходный код – Почти все разрабатываемое сегодня программное обеспечение в той или иной степени включает в себя ПО с открытым исходным кодом. Компоненты с открытым исходным кодом являются одними из основных причин импорта уязвимостей в ваше приложение напрямую или через временные зависимости. Кроме того, не только используемые вами библиотеки могут подвергнуть вас опасности, но также неспособность обновлять старые библиотеки или быть в курсе последних опубликованных CVE, что может повлиять на вас. Мы рекомендуем создать список одобренных пакетов с открытым исходным кодом для использования организацией и постоянно проверять и обновлять его. Запрещение разработчикам добавлять любой пакет, который они хотят, даже в качестве теста, может помочь сократить количество уязвимостей, с которыми вам придется иметь дело.
Убедитесь, что уязвимости не превращаются в эксплойты. – Почти нет кодовой базы, лишенной уязвимостей. При любом приличном сканировании их обнаружится от сотен до тысяч. Устранить их всех невозможно. Также важно помнить, что уязвимости не являются эксплойтами. Убедитесь, что у вас есть процесс фильтрации, чтобы убедиться, что любая обнаруженная вами уязвимость не является угрозой, которую можно использовать, и постоянно обновляйте этот список. Таким образом, вы можете успокоить третьих лиц или пользователей, обеспокоенных последней версией CVE, что она не оказывает абсолютно никакого влияния на ваше приложение.
Безопасность начинается с вашего мышления
Вероятно, существует столько же различных способов разработки программного обеспечения, сколько существует разработчиков, фреймворков и языков программирования. Другими словами, нелегко найти лучшие практики для обеспечения безопасности вашего процесса разработки, которые были бы актуальны независимо от того, какой язык, область или IDE вы используете. Помимо множества инструментов, как проприетарных, так и бесплатных, требующих вашего внимания как «следующего незаменимого инструмента безопасности», самым важным инструментом безопасности, который вы можете использовать, является ваше мышление.
Подумайте о выборе дизайна, архитектуры и хранилища. Рассматривали ли вы возможность экспоненциального роста вашей пользовательской базы? Правильно ли вы сегментировали права доступа для различных частей вашей кодовой базы и инфраструктуры? Рассматривали ли вы как целенаправленную атаку на ваши данные или секреты, так и «косвенную» атаку на цепочку поставок программного обеспечения?
Все эти и многие другие вопросы следует рассмотреть еще до того, как вы приступите к планированию своего приложения, и их следует регулярно перепроверять по мере роста и развития кодовой базы и приложения.
Считается аксиомой, что наиболее уязвимой частью любого программного обеспечения является человек, который его запускает (или пишет). Не позволяйте вашему приложению, программному обеспечению или библиотеке кода стать частью растущей статистики новой волны кибератак. При правильном планировании, инструментах и автоматизации вы сможете найти правильный баланс между управлением киберрисками, безопасностью жизненного цикла разработки и созданием хорошо документированного, комплексного и эффективного кода.