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