Безопасность — неотъемлемая часть процесса разработки ПО с привлечением практик, которые обеспечивают конфиденциальность, целостность и доступность приложений. CTO Perforce Software Род Коуп рассуждает на портале Information Age о том, почему у предприятий возникают сложности с обеспечением защиты ПО в ходе разработки, и приводит советы, как ее улучшить.

Безопасность разработки ПО должна стать приоритетом

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

Подвижки в лучшую сторону появились на фоне набирающей популярности методологии DevOps и ее производной — DevSecOps. Вместе с ними пришло понимание, что современная разработка должна идти параллельно с поэтапным мониторингом кода и тестированием типа «Shift Left», который проводится на самых ранних этапах жизненного цикла ПО. Для выполнения этих операций требуются автоматизированные инструменты тестирования и проверки кода, которые проделывают большую часть работы в фоновом режиме, экономя время разработчиков.

Польза автоматизированного тестирования

Автоматизация во всех смыслах хороша, но здесь есть один нюанс: она генерирует огромный объем шума (выходных данных сомнительной ценности) в тестовых данных. Важно сделать упор на тесты, которые окажут реальное влияние на бизнес, и совместить автоматизированное непрерывное тестирование с интеллектуальной аналитикой. Машинное обучение все чаще встречается в автоматизированных инструментах для тестирования, в будущем его роль значительно вырастет. Некоторые сегменты рынка, особенно те, которые предъявляют особые требования к защите ПО или вынуждены соблюдать требования контролирующих органов, начали внедрять стандарты кодирования, которые позволяют разработчикам создавать безопасный, надежный и совместимый код.

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

Безопасность Open Source

Как и проприетарное ПО, программы на базе открытого кода содержат ошибки или имеют проблемы с безопасностью. Возьмем, например, OpenSSL. Несмотря на то, что эта криптографическая библиотека — одно из наиболее популярных в мире решений для обеспечения безопасности типа Open Source, в нем периодически всплывают критические проблемы. Это значит только одно: для безопасной работы Open Source-программ требуется тщательное управление и поддержка, причем делать это нужно систематически, а не от случая к случаю. Другим примером является Git — популярный инструмент контроля версий, ориентированный на разработчиков. Предприятиям нужно применять его с осторожностью, поскольку их уровень требований к безопасности гораздо выше, чем у Open Source-сообщества.

Еще одна опасность Open Source кроется в том, что он обходится дешевле проприетарного софта, поэтому часто минует централизованную процедуру закупок. Организациям необходимо найти способы обеспечить соответствие Git и другого ПО с открытым кодом политикам безопасности. При выборе требуемых стратегий в области применения Open Source следует руководствоваться различными экспертными оценками, а не дешевизной поддержки того или иного решения. В некоторых случаях обратной стороной экономии являются серьезные проблемы с безопасностью. Решить их поможет правильный выбор Open Source-провайдера, число которых постоянно растет. Нужно обходить стороной вендоров, технологический стек которых состоит из компонентов с несовместимыми SLA, или если имеются сомнения по поводу выполнения ими своих обязательств. Не лучшим выбором окажутся поставщики, которые задействуют большое количество третьих сторон или же они недостаточно гибкие, чтобы быстро адаптироваться к последним технологическим новшествам.

Безопасность приложений

Моделирование угроз — еще один метод защиты приложений, который позволяет выявить потенциальные угрозы, а также их приоритетность с точки зрения злоумышленника. Чтобы смоделировать его действия, можно задать следующий вопрос: какие данные он будет искать? Одной из популярных моделей по выявлению угроз является STRIDE, которую можно использовать в тандеме с системой оценки рисков DREAD — это помогает вычислить вероятность угрозы, возможные последствия и степень допустимости риска. Что касается веб-приложений, то Open Project Application Security Foundation (OWASP) публикует список 10 самых распространенных и наиболее опасных угроз, из которого можно почерпнуть полную и качественную информацию. Каждая угроза в нем классифицируется по агентам, уровню эксплуатируемости, распространенности, степени обнаружения, техническому воздействию и оказываемому влиянию на бизнес.

Список OWASP также помогает прояснить ситуацию с безопасностью API. Особое внимание уделяется их защите на всех этапах жизненного цикла, начиная со стадии разработки. API особенно уязвимы к атакам — проблемы могут возникнуть с момента их публикации, когда уже не остается времени для их устранения или его критически мало. К сведению: частота атак на API совпадает с частотой атак при запуске новых веб-сайтов.

Совершенствование API должно начинаться с культуры разработки ПО. Людям следует осознавать свою роль в снижении риска и установлении приоритетов безопасности. Это относится как к внутренним, так и к внешним контрибуторам кода (у которых может быть мало опыта разработки — написать API может и хакер). Внедрение автоматизированных процессов, которые затем будут последовательно применяться для проверки всех имеющихся и будущих API, поможет обеспечить надлежащую стратегию безопасности и выбрать надежный шлюз для публикации API (лучше выбрать тот, который поддерживает несколько типов API).

Выводы

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