Журнал "Information Security/ Информационная безопасность" #1, 2021

нается с инструментов SCA – анализа композиции кода Open Source, который должен стать первым шагом на пути к "безопасности по природе". Такие инструменты могут применяться на раз- личных фазах разработки. Обычно про- верки встраивают на входе в репозито- рий или в скрипты сборки, но они могут встраиваться в IDE разработчика и пре- доставлять разработчикам обратную связь уже на стадии первичного коди- рования. SCA – это универсальный инструмент декомпозиции, инвентари- зации и контроля компонентов исходного кода, его можно использовать при любом уровне зрелости процессов обеспечения безопасной разработки. На начальных уровнях зрелости его применяют для анализа исходного кода во время стати- ческого тестирования и проверки всего кода Open Source. На более высоком уровне зрелости такие инструменты пре- доставляются каждому разработчику, они интегрируются в IDE разработчика, и анализ компонента Open Source про- исходит в момент добавления его в локальный репозитарий разработчика. Конечно же, кроме SCA, на этапе Continuous Integration должны использо- ваться различные инструменты и подхо- ды, такие как плагины Security IDE, Security Code Review, парная работа разработчиков, статический и динами- ческий анализ кода, фаззинг-тестиро- вание, подписание кода, мониторинг инфраструктуры, антивирусная защита инфраструктуры и станций разработчи- ка. Но, по моему мнению, невозможно выстроить адекватные процессы управ- ления безопасностью, не поняв, из чего состоит система, то есть без полноцен- ной инвентаризации исходного кода. Continuous Deployment На этапе Continuous Deployment во время предрелизного тестирования очевидна потребность в тесте на проникновение. Пентестинг – это одна из немногих практик, которую сложно или практически невоз- можно полностью автоматизировать и реа- лизовать на более ранних этапах разра- ботки. Тем не менее даже здесь можно порекомендовать включить профессио- нальных пентестировщиков в команду раз- работки для проведения тестирования уже в Staging-среде на этапе Continuous Inte- gration, а использование инструментов оркестрации релизов позволит значительно снизить транзакционные издержки при сме- щении Security Quality Gate на эту стадию.. Release on Demand На этапе Release on Demand безопас- ность готового продукта поддерживается посредством непрерывного мониторинга безопасности с помощью SIEM-решений и обработки данных командами ИБ. На этом этапе задействуются SOC, реаги- рование на инциденты, непрерывный мониторинг угроз, внешний аудит уязви- мостей. Кроме специализированных есть инструменты, которые решают ряд смеж- ных задач. В качестве примера такого комплексного инструмента можно назвать российский продукт CodeScoring, который не только выполняет традиционные функ- ции SCA-инструмента для ИБ и юристов, но и контролирует вопросы качества и эффективности для разработчиков. Он одновременно обеспечивает контроль использования Open Source, его без- опасность и контролирует использование интеллектуальной собственности компа- нии через автоматическое отслеживание использования программных компонен- тов собственной разработки, а также дает оценку качества кода в разрезе команд и потоков создания ценности, как и качество и полноту самих команд. CodeScoring может быть использован на всех этапах конвейера DevOps: l на этапе Continuous Exploration он контролирует технический долг и ана- лизирует состояние команды; l на этапе Continuous Integration/Contin- uous Deployment он идентифицирует лицензионные нарушения и контроли- рует количество и качество заимство- ванного кода; l на этапе Release on Demand CodeScor- ing предупреждает о новых уязвимостях, обнаруженных в компонентах Open Source уже после выхода продукта, и контроли- рует сложность решения с точки зрения управления рефакторингом продукта. В заключение Безопасность по природе (Security by Nature) является фундаментом, обеспечи- вающим дальнейшую прочность и надеж- ность продукта. Сегодня она становится частью культуры разработки организации, помогает избежать дополнительных затрат на безопасность, связанных с задержкой поставки ПО, переделкой кода и устранением уязвимостей, которых все так боятся. Этому способствуют, конечно же, и требования регуляторов обеспече- нию соответствующего уровня доверия к процессу разработки, и рост инцидентов кибербезопасности, и необходимость сокращения стоимости релиза, что, в том числе, является результатом своевре- менного контроля качества кода, неотъем- лемой частью которого является контроль его безопасности. Я уверен, что нельзя рассматривать требования безопасности кода в отрыве от остальных требований к качеству разработки. Только при целост- ном и согласованном подходе к качеству, надежности и безопасности кода можно говорить о продуктах, качественных по природе. При использовании передовых практик DevOps и инструментов автома- тизации интеграция в разработку требо- ваний к его безопасности происходит органично и необременительно. l • 41 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru Реклама Ваше мнение и вопросы присылайте по адресу is@groteck.ru