Здравствуйте, уважаемые читатели!
Автор предлагает Вашему вниманию три интервью с представителями современных, крупных, интересных проектов о методике разработки программного обеспечения и, в частности, об использовании статических анализаторов кода. Автор надеется, что читателям будет интересно прочитать данный текст. Участники: Acronis, AlternativaPlatform, НПО-Эшелон.
С уважением,
Александр Тимофеев
Участники и структура статьи
За интервью автор обратился в три компании:
— Acronis с продуктом Acronis Backup, предназначенном для создания резервных копий данных и последующего восстановления
— AlternativaPlatform с проектом «ТанкиОнлайн», многопользовательской игрой
— НПО «Эшелон» с рядом продуктов для ревизии кода, связанной с безопасностью
Вопрос были одинаковые для всех компаний, за исключением изменений для НПО «Эшелон», чтобы интервью лучше отразило специфику данной компании.
Интервью с Acronis
Спикер — Кирилл Коротаев, вице-президент по разработке продуктов Acronis Backup
1) обзорная информация об основном и самом масштабном продукте компаниипроекта (суть продукта, на каком языке написан продукт, сколько человек трудится над его написанием, каковы обычные темпы внесения изменений в код проекта в строчках или килобайтах кода, например, в суткинеделюмесяц, какая CVS используется)
Суть продукта Acronis Backup, который мы разрабатываем, состоит в создании резервных копий данных пользователей на их компьютерах, ноутбуках, серверах. Чтобы предоставить людям возможность восстановить в последующем свои данные из этих резервных копий. Восстановление может потребоваться, например, если компьютер вышел из строя. Или если будет нужна более ранняя версия файла или документа. Или же если файл был утерян.
Весь наш проект написан на C++ процентов на 99%. Трудятся над ним примерно 70 разработчиков. В среднем делается от 100 до 300 правок (коммитов) в код проекта в неделю. Используемая система контроля версий — SVN (Subversion).
2) кто и как анализирует код проекта? как организован цикл тестирования? насколько широк штат тестировщиков? как компания реагирует на появление информации об ошибке — есть ли разработанный протокол для таких ситуаций?
Есть архитекторы, есть лидеры, которые знают код тех частей проекта, за которые они отвечают, соответственно, они анализируют этот код и знают, как его улучшать. Каждый коммит проходит через систему code review — то есть любое изменение сначала анализируется людьми, которые отвечают за свой участок кода.
В данный момент количество тестировщиков у нас сопоставимо с количеством разработчиков. Для тестирования применяются автоматические и ручные тесты. У нас есть, например, build validation тесты — набор тестов, проверяющих каждый новый билд. И в идеале после каждого коммита в код должен собираться новый билд и сразу же проверяться.
Процесс реакции на найденную ошибку устроен следующим образом. Любая ошибка (issue), найденная отделом тестирования, заносится в систему Jira (более продвинутый платный вариант BugZilla). И всё это интегрировано с SVN – когда, например, делается коммит, который чинит конкретный issue, в Jira добавляется ссылка на данный коммит. Также информация об ошибке может прийти и от пользователей нашего продукта. Сначала они связываются с нашей техподдержкой (саппортом). Если саппорт выявляется какие-то баги, которые нужно проанализировать, то опять же информация о них сначала попадает в Jira. И ошибки чинятся в ближайших апдейтах продукта.
3) используются ли инструменты для статического анализа кода? если используются, то какие? если используются, то просьба к эксперту привести пример наиболее примечательной и интересной ошибки, которую помогли найти анализаторы. Каковы обычные результаты и статистика от использования анализаторов? Насколько часто и по какому плану проводятся проверки? Каков сценарий реагирования на ошибку, найденную анализатором?
Мы используем либо использовали ранее разные статические анализаторы — например, и бесплатный опенсорсный cppcheck, и PVS-Studio. Имеет смысл их использовать, конечно, в любом проекте. Но разные анализаторы кода очень не похожи друг на друга и ловят разные классы ошибок — поэтому я за разнообразие в используемых средствах.
Находятся такие вот интересные потенциальные баги. Из более сложных — например, PVS-Studio находит неправильное использование автопоинтеров стандартных из библиотеки STL. Или, например, находит такую интересную ошибку — если Вы один sizeof от какой-то структуры или параметра умножаете на другой sizeof, то PVS-Studio правильным образом замечает, что, вообще говорят, странно, что один sizeof умножается на другой. Тут, понимаете, даже размерность логически получается в квадрате.
Иногда статические анализаторы умеют понимать, что поинтер не проверен на null перед использованием. Но это более сложные проверки, потому что не всегда очевидно, а может ли поинтер быть null в этом месте кода. Раз в день проверять код статическими анализаторами — вполне себе хорошая задача. И при этом автоматически забивать баги в ту же Jira — это полезно для разрабатываемого продукта.
4) мнение эксперта относительно будущих методик создания крупных программных продуктов. Отдельно — что эксперт ожидает и хотел бы увидеть от инструментов статического анализа кода?
Автоматизированные инструменты развиваются и будут развиваться. Например, сейчас нету ни одной автоматической системы, которая выбирала бы тесты на базе внесенных изменений. Например, чтобы выбрать те тесты, которые нужно прогнать, ради конкретного изменения в коде.
Что касается будущего статических анализаторов, то я думаю, что количество ситуаций, которые они будут обрабатывать, будет расти. При этом статические анализаторы будут смещаться в сторону более сложного анализа. И даже гарантии соответствия кода, например, какому-нибудь протоколу.
5) обращение эксперта к коллегам по цеху и читателям
Пишите качественный код, тестируйте его и применяйте самые разные методики. В том числе, и статические анализаторы.
Интервью с AlternativaPlatform
Спикер — Алексей Квиринг, технический директор ООО «ТанкиОнлайн»
1) обзорная информация об основном и самом масштабном продукте компаниипроекта (суть продукта, на каком языке написан продукт, сколько человек трудится над его написанием, каковы обычные темпы внесения изменений в код проекта в строчках или килобайтах кода, например, в суткинеделюмесяц, какая CVS используется)
На данный момент у нас есть один такой продукт — онлайн игра ТанкиОнлайн. Серверная часть написана на Java. Клиентская часть — на AS3. У нас около 20 программистов. В неделю добавляется примерно 5К строчек. В качестве CVS используем GIT.
2) кто и как анализирует код проекта? как организован цикл тестирования? насколько широк штат тестировщиков? как компания реагирует на появление информации об ошибке — есть ли разработанный протокол для таких ситуаций?
У нас типичный процесс для Git-a. Весь код проходит обязательный Code Review. Также внедрена непрерывная интеграция, build сервер постоянно проверяет код, запускает тесты.
Тестирование проходит в несколько этапов — сначала автоматическими тестами, потом сами разработчики тестируют руками (играют), потом команда тестеров. Если все нормально, то подключаются тестеры из сообщества. И только после этого изменения попадают в production. Команда тестеров у нас небольшая — три человека. Но мы активно используем тестеров из сообщества, у нас несколько десятков добровольных помощников.
Если ошибка все же пробралась в production, то она исправляется сразу после обнаружения. Обычно все такие ошибки исправляются за пару дней.
3) используются ли инструменты для статического анализа кода? если используются, то какие? если используются, то просьба к эксперту привести пример наиболее примечательной и интересной ошибки, которую помогли найти анализаторы. Каковы обычные результаты и статистика от использования анализаторов? Насколько часто и по какому плану проводятся проверки? Каков сценарий реагирования на ошибку, найденную анализатором?
На уровне компании мы не используем такие инструменты. В прошлом, ради интереса я запускал пару инструментов для анализа, но ничего фатального они не нашли (JetBrain IDEA checker).
Я думаю что статический анализ очень хорош для сложных языков, таких как С и C++. Но для более простых, таких как Java его актуальность не очень большая. В Java как класс отсутствую проблемы, связанные с памятью. Синтаксис простой и понятный, разночтения не допускаются, компилятор проверяет многие вещи на этапе компиляции. Среды разработки обеспечивают удобные инструменты для рефакторинга, что исключает случайные ошибки при ручном изменении кода.
Есть одна область, в которой я бы использовал статический анализатор для Java. Это проверка программы на корректность многопоточного исполнения. Но на данный момент таких инструментов просто нет. В целом, если статический анализатор качественный и реально ищет ошибки — то это полезная вещь для проекта.
4) мнение эксперта относительно будущих методик создания крупных программных продуктов. Отдельно — что эксперт ожидает и хотел бы увидеть от инструментов статического анализа кода?
Будущее за системами автоматического тестирования, непрерывной интеграции и анализаторами кода. От статического анализа я ожидаю анализ многопоточных приложений и анализ правильности архитектурных решений.
5) обращение эксперта к коллегам по цеху и читателям
Не бояться внедрять новые технологии в цикл производства. Учиться у более опытных программистов. Пересматривать свои старые решения. И все обязательно получится.
Интервью с НПО «Эшелон»
Спикер — Андрей Фадин (a.fadin@cnpo.ru), главный конструктор компании НПО «Эшелон»
1) обзорная информация о Вашей компании и её деятельности, связанной с программным обеспечением.
Компания НПО «Эшелон» является как разработчиком средств анализа защищенности, так и активным пользователем этих продуктов в рамках проектов сертификации средств защиты информации и коммерческого аудита кода.
В число средств анализа защищенности, разработанных нашей компанией, входят:
- АК-ВС 2 — облачная среда проведения сертификационных испытаний исходных текстов по требованиям контроля отсутствия недекларированных возможностей (до 1 уровня контроля включительно);
- AppChecker — проведение сигнатурно-эвристического анализа программного кода с целью выявления программных закладок, критических уязвимостей ПО и других проблем связанных с дефектами программного кода;
- ПИК — средство фиксации и сравнения контрольных сумм файлов, папок и машинных носителей информации;
- Сканер-ВС — набор инструментальных средств и среды проведения сетевого и локального аудита защищенности, включающий сканеры безопасности, средства анализа трафика, поиска остаточной информации на носителях и ряд других компонент.
Команда анализа защищенности кода и тестирования на проникновение «Эшелон» — это объединение квалифицированных специалистов в области информационных технологий и информационной безопасности, созданное на кадровой, исследовательской, инженерной базе АО «НПО «Эшелон» и ведущего технического вуза страны, МГТУ им. Н. Э. Баумана.
Мы работаем с большинством популярных языков программирования, таких как: PHP, Java, C#, C/C++, Perl, Python, JavaScript, включая их новейшие стандарты.
Аудит программного кода, проводимый специалистами компании НПО «Эшелон» позволяет решить следующие задачи:
контроль качества внутреннего и внешнего (outsourced) кода, обнаружение типовых дефектов (ошибок кодирования или проектирования);
выявление умышленных программных закладок в коде;
контроль заимствованного кода (анализ внешних зависимостей ПО от open-source и других внешних компонент)
Для программного обеспечения, прошедшего аудит, возможна сертификация по требованиям безопасности информации в испытательной лаборатории НПО «Эшелон».
2) обзорная информация о том, как работают Ваши эксперты (не закрытая и не секретная информация) — кто и как анализирует код проектов, как организован цикл тестирования, каков обычный протокол при обнаружении важного момента в коде?
Команда аудиторов кода формируется из двух основных типов специалистов:
Первый тип специалистов, это — эксперты испытательной лаборатории НПО «Эшелон», имеющие опыт организации взаимодействия с разработчиками крупных программных проектов (операционные системы, межсетевые экраны), а также коллективной работы по рецензированию больших объёмов кода.
Второй тип специалистов — это разработчики (сотрудники департаментов Research&Development компании «Эшелон»), имеющие высокие технические компетенции в различных языках программирования, их фреймворках и типовых библиотеках. По возможности стараемся привлекать к аудиту кода непосредственно разработчиков средств статического анализа, это позволяет им напрямую, на своём опыте оценить удобство работы наших средств анализа. Кроме того, поскольку у разработчиков — больше навыков по созданию новых сигнатур для статанализаторов, имеет смысл подключать разработчиков для своевременного обновления базы дефектов, если этого требует специфика исследуемого программного проекта.
В целом процесс разработки и тестирования связан со следующими стадиями:
1. Декомпозиция кода проекта на компоненты (если идет анализ стороннего проекта)
2. Построение модели угроз, анализ этих компонент и интерфейсов их взаимодействия на предмет критичности с точки зрения обеспечения информационной безопасности.
3. Запуск средств статического и динамического анализа с учетом результатов п.2
4. Избирательное рецензирование кода, на основе результатов п.3 и п.2
5. Подготовка протокола выявленных потенциально опасных конструкций и обсуждение данных результатов с командой разработчиков программного проекта.
Стадии 3, 4 и 5 как правило повторяются 3-4 раза, поскольку по результатам анализа каждой из потенциально опасных конструкций как правило либо происходит доработка программного проекта с целью устранения дефекта (что влечет за собой повтор стадий, начиная с 3), либо устанавливается, что данный фрагмент кода является ошибочным предположением эксперта, либо ложным срабатыванием статического анализатора (что влечет за собой повтор стадий, начиная с 4).
3) информация об инструментах статического анализа — какие статические анализаторы используются; пример наиболее примечательной и интересной ошибки, которую помогли найти анализаторы; каковы обычные результаты и статистика от использования анализаторов; каков сценарий реагирования на момент в коде, найденный анализатором?
В своей работе аудиторы используют как наши собственные разработки (АК-ВС2, AppChecker), так и open-source средства (CppCheck, PMD), а также приобретенные сторонние коммерческие продукты (СиПроВер CppCat).
Сценарий реагирования был описан в п.2. Что касается статистики использования анализаторов, как правило доля ложных срабатываний анализатора (false-positives) на крупных проектах превышает 50% и для составления итового списка выявленных потенциально опасных конструкций так или иначе-требуется привлечение эксперта. Однако поскольку он рецензирует не полный объем кода, а лишь его критичные участки, в среднем не превышающие 5% от общего объема кода, достигается серьезная экономия времени на анализе кода.
Во избежание нарушения соглашений о неразглашении коммерческой тайны, к сожалению, не можем рассказать о найденных ошибках в конкретных продуктах. Но, из нашего опыта, большинство интересных ошибок были связаны:
- с жёстко закодированными паролями (Use of Hard-coded Password, CWE-259) и другими данными аутентификации (Use of Hard-coded Credentials, CWE-798);
- с “пасхальными яйцами” и другой скрытой функциональностью (Hidden Functionality, CWE-912);
- достаточно часто “всплывают” ошибки связанные с “гонками” и разделяемыми ресурсами (Race Condition, CWE-362).
4) мнение эксперта относительно будущих методик создания программных продуктов, а также что эксперт ожидает и отдельно хотел бы увидеть от инструментов статического анализа кода.
На наш взгляд, в будущем верификация программного обеспечения всё более тесно будет связана с процессами его разработки, как в рамках систем непрерывной интеграции (Continuous Integration), так и в рамках их непрерывного развёртывания (Continuous Delivery).
Тесная интеграция с этими системами в будущем позволит полностью контролировать разработку и поставку ПО, таким образом в рамках этих процессов стат. анализатор начинает играть роль своеобразной IPS, блокируя на уровне коммитов и релизов код, не прошедший требования стандартов качества (quality gate). С этой точки зрения любая CI/CD система представляет собой также интересный источник событий для систем управления безопасностью (SIEM).
Большие перспективы также имеет внедрение стат. анализаторов в парадигму разработки на основе моделей (model-driven development), тесная интеграция с CASE-средствами позволит проверять ошибки на уровне синтаксиса, на уровне компонент ПО и их интерфейсов и даже на уровне бизнес-требований, чтобы, например, аналитик, мог еще на этапе проектирования системы обосновать перед заказчиками, необходимость добавления той или иной роли в управлении доступом.
5) обращение эксперта к коллегам по цеху и читателям
Уважаемые коллеги, в прошедшем десятилетии при обеспечении информационной безопасности на предприятии, в первую очередь делался акцент на безопасности сетей (network security), а также на безопасности узлов и рабочих мест (endpoint security).
Однако если говорить о решении таких задач как выявление уязвимостей нулевого дня (zero-days), обнаружения закладок и «имплантов» (фрагментов кода и конфигурации, внедренных в программное обеспечение в целях государственного или промышленного шпионажа), мы сталкиваемся с тем, что классические средства защиты информации уровня сети или узла (система обнаружения вторжений, антивирусные средства) не способы эффективно справиться с данными угрозами.
При решении этих вопросов необходим комплексный подход, связанный с одной стороны с централизацией управления информационной безопасностью на предприятии (SIEM-системы), а с другой стороны — использующий структурную декомпозицию программного обеспечения на компоненты с контролем их происхождения, а также статический анализ содержимого компонент и материалов их производства (в том числе исходных текстов).
Заключение
Автор благодарит пресс-службы и экспертов компаний-участников исследования за оперативную работу и полноту ответов на вопросы интервью. А также благодарит компанию ООО «СиПроВер», разрабатывающую современный статический анализатор кода PVS-Studio, которая выступила спонсором данной статьи. И без содействия которой данная статья вряд ли бы увидела свет.
Автор: gateway219
