Журнал "Information Security/ Информационная безопасность" #3, 2023
покрытия кода не только юнит-тестами, но и в рамках других технологий. Авто- матизированная система сборки и тести- рования продукта. Мониторинг и свое- временное реагирование на появляю- щиеся уязвимости и новые виды атак и угроз. Владимир Пономарев, Гарда Технологии: О безопасности нужно думать с самого начала. 1. Анализ рисков и угроз на этапе проектирования. 2. Безопасность должна быть неотъем- лемой частью процесса разработки. Для нас это DevSecOps. 3. Управление и развитие. Важно, чтобы SDL приносил пользу, но и не ограничивал. Тут как с любым делом – стоит только начать. Роман Карпов, Axiom JDK: 1. Ответственность за результат про- веденных исследований и уверенность в качестве продукта, что дает гарантии клиентам в защищенности систем на его основе на всех этапах жизненного цикла. 2. Постоянное совершенствование практик безопасной разработки. 3. Развитие опыта сотрудников в обла- сти безопасной разработки, повышение профессионализма и культуры разра- ботки как внутри нашей инженерной команды, так и ИТ-специалистов на рынке в целом, в других ИТ-компаниях и ИТ-подразделениях заказчиков. Сергей Деев, МТС RED: 1. Эксперты в службе ИБ и в блоке разработки, способные распознать уязвимости в ПО и сборочной инфра- структуре, приоритизировать их и при- нять необходимые меры к их устране- нию. 2. Процессы управления безопасной разработкой. 3. Инструменты, позволяющие не толь- ко выявлять уязвимости в ПО и обес- печивать безопасность сборочной инфраструктуры, но и решать эти задачи, сохраняя эффективность бизнес-про- цессов в компании (скорость выпуска релиза, гибкие методологии разработки и т.д.). Сергей Сергеев, КСБ-СОФТ: 1. Культура безопасности поможет взаимодействию команд разработки и безопасности, что приведет к росту осведомленности разработчиков о пра- вилах безопасности и улучшению защи- щенности продукта на ранних стадиях жизненного цикла. 2. Выстроенный процесс Vulnerability Management поможет грамотно осу- ществлять контроль жизненного цикла уязвимостей. 3. Композиционный анализ поможет выявлять уязвимости в заимствованных компонентах с открытым исходным кодом, используемых разработчиками при создании собственного ПО. Сергей Трандин, Базальт СПО: 1. Интеграция средств проверки в основную инфраструктуру разработки. 2. Использование проверенных инстру- ментов контроля. 3. Выпуск сертифицированных про- дуктов на основе отдельной ветки про- екта "Сизиф", организованной в соот- ветствии с требованиями безопасной разработки. Александр Дубинин, YADRO: 1. Инженерная культура. SDL – одна из проекций инженерных принципов, позволяющих создавать качественные продукты. 2. Подтвержденная тестами надеж- ность и стабильность продуктов. 3. Качество кода и архитектуры, под- держиваемость, возможность дальней- шего развития. Оксана Новослугина, СПб ИАЦ: 1. Главная задача – минимизировать риски с точки зрения безопасности и улучшить качество выпускаемой про- дукции. 2. Максимально усложнить эксплуа- тацию уязвимостей. 3. Сократить сроки устранения и вне- сения изменений в продукт. Роман Борзов, Андрей Кузнецов, Фобос-НТ: Ключом к улаживанию такого проти- воборства является повышение уровня доверия между аудиторами, разработчи- ками и создаваемой SDL-командой. Это достигается за счет проведения встреч с командами разработки, на которых демонстрируются примеры применения лучших практик, их польза для процесса разработки в части качества исходного кода и для компании в части безопасно- сти итогового продукта, что в целом повышает репутацию компании на рынке. Лука Сафонов, Синклит: Противоборство с командой решается поддержкой руководства организации. Если принято волевое решение, деваться некуда. Естественно, у команд всегда присутствует большая доля скепсиса: трудозатраты повышаются, времени, чтобы пилить фичи, становится меньше. Но если показать реальную пользу от процесса SDL, продемонстрировать, как ошибка в коде может привести к полной компрометации в системе, подсказать разработчику, как искать проблемы и как их избегать, негатив уходит и начи- нается конструктивное взаимодействие. Алексей Смирнов, CodeScoring: У нас в команде таких вопросов не возникает, поскольку наш продукт сам является SDL-инструментом и все кон- структивно воспринимают безопасность. Но в полях мы действительно видим большое количество встречных отговорок от безопасности. Самая популярная – "нужно исправлять баги от заказчика, нет времени настраивать SDL". Важно объяснить, что функциональные ошибки и ошибки безопасности – одного поля ягоды. К тому же исправление багов без- опасности зачастую более увлекательная инженерная задача, чем исправление функциональности. Сергей Груздев, Аладдин Р.Д.: Дам сначала совет начинающим. Пер- вым делом необходимо провести аудит актуального процесса разработки в команде, оценить его с разных сторон: уровень взаимодействия и коммуника- ции внутри и между командами, доста- точно ли знаний и опыта для внедрения концепции безопасной разработки. Если говорить конкретнее, нужно детально понять, насколько сложными инструментами обеспечения безопасной разработки команда владела ранее, спо- собна овладеть сейчас и в перспективе (это относится как к разработчикам, так и к тестировщикам). При плохом уровне взаимодействия ошибки не будут исправ- ляться. Исходя из моего опыта могу сказать, что весь процесс организации без- опасного процесса разработки зани- мает от А до Я около шести месяцев. Сейчас для автоматизации разработки софта и написания кода мы используем хорошо известные и проверенные вре- менем инструменты: систему непре- рывной интеграции Jenkins, собствен- ные скрипты на Python, а также разно- образные средства тестирования без- опасности, такие как Svace, AFL++, Crusher, Блесна. Главный залог успеха в процессе "раз- руливания" – командоформирующие мероприятия, объединение команды, налаживание коммуникации. Карина Нападовская, Лаборатория Касперского: Противоборство было, есть и будет всегда! Я стараюсь подключать грамот- ных аудиторов, проводить встречи с регу- лятором для того, чтобы разработчики могли задать волнующие их вопросы и по-другому взглянули на ситуацию, увидев пользу от новых практик и инстру- ментов. Только показав, что их труд не напрасен, можно добиться результата. опишите ваш успешный опыт "разруливания" противоборства с командами разработчиков на старте процесса внедрения SDL и дайте советы начинающим. • 45 Безопасная разраБотка www.itsec.ru
Made with FlippingBook
RkJQdWJsaXNoZXIy Mzk4NzYw