Главная / О компании / Новости / CodeScoring: российское решение для композиционного анализа кода

CodeScoring: российское решение для композиционного анализа кода

« Назад

CodeScoring: российское решение для композиционного анализа кода  07.06.2021 15:30

СмирновВ начале 2021 г. на рынке инструментов разработки появилось оригинальное решение CodeScoring для анализа и оценки кодовой базы на лицензионное соответствие, наличие известных уязвимостей и уровня технического долга от российской компании Профископ. Это первое отечественное решение для композиционного анализа исходного кода (SCA).
 

Об особенностях CodeScoring и решаемых им задачах с CEO и основателем компании Алексеем Смирновым побеседовала эксперт компании Web Control Дарья Орешкина.

Алексей Смирнов, CEO и основатель компании CodeScoring

– Что отличает ваш продукт от других SCA?

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

Дело в том, что традиционные SCAрешения, как и десять лет назад, ориентированы в первую очередь на идентификацию Open Source пакетов (OSS) и выдачу заказчику имеющейся по ним информации. Они просто сравнивают файлы на идентичность с известными пакетами и говорят, из каких компонентов состоит код заказчика, какие известные уязвимости присутствуют и какие лицензионные ограничения существуют. Мы же устанавливаем авторство, то есть ищем похожий код и идентифицируем не только идентичный, но и похожий код. Поэтому мы позиционируемся как Flexible SCA. Это позволяет нам видеть то, что ускользает от традиционных SCA.

Кроме того, по нашему мнению, возможности SCA сильно недооценены заказчиками. Такие инструменты используются главным образом как часть статического анализа для выявления известных уязвимостей в заимствованном коде OSS и применения к ним политик безопасности или для отслеживания лицензионной чистоты разработанного продукта. То есть цель – быстро получить ответ на вопрос, можно ли ПО выпускать или нужно что-то исправить. Однако при правильном подходе подобные решения открывают новые возможности и для повышения качества ПО, и для оптимизации процессов разработки, и для оценки квалификации авторов.

У каждого компонента есть автор, источником качества тоже является автор, он же несет ответственность за привнесенные заимствованием уязвимости и лицензионные ограничения. Недостаточно просто заблокировать релиз, нужно понимать, кто будет исправлять код. Именно поэтому CodeScoring, позволяющий не только делать анализ самого кода, но и связывать конкретный код с конкретным разработчиком, включая транзитивное заимствование, и при этом оценивать (скорить) этих авторов, является инновационным. Такого подхода сейчас в мире нет ни у кого.

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

– Как качество и сложность проектов связаны с безопасностью?

– Если говорить про сложность и безопасность, то здесь важно уточнить, что под сложностью мы имеем в виду цикломатическую сложность – количество линейно независимых маршрутов через программный код. Чем больше развилок, тем сложнее программа. В среде специалистов, профессионально занимающихся анализом кода (код-майнеров), достаточно известно исследование о том, что если цикломатическая сложность близится к числу 50, то вероятность внесения ошибки в программный код с каждым новым изменением близится к 100%. То есть чтобы ни делали программисты с таким кодом, они, скорее всего, сделают ошибку. Наличие такой ситуации в проекте – прямая угроза его безопасности.

– Специалисты по безопасности в той или иной мере анализируют выпускаемое ПО, но что может ускользать от внимания безопасников?

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

Ну и конечно же, вопросы внутреннего и внешнего заимствования оригинального кода, являющегося собственностью компании, вне зоны внимания традиционных SCA и систем статического анализа кода. Наш опыт работы с заказчиками говорит о том, что это неотъемлемая часть аудита кода, и мы это делаем.

– При сравнении различных SCA заказчики часто спрашивают, насколько полная у вас база уязвимостей. Как вы думаете, достаточно ли иметь самую большую базу уязвимостей, чтобы гарантировать безопасность используемых OSS-пакетов?

– Подключить много источников несложно, сложно с ними жить, потому что они разрозненные, содержат откровенно "грязную" информацию, которую надо регулярно актуализировать, отслеживать, очищать, классифицировать. Информация о большинстве уязвимостях публикуется в открытом доступе, и для ее получения не нужно покупать SCA. Но как мне найти в базе уязвимостей библиотеку, которая используется в моем проекте?

Есть подход к единому именованию приложений, которое называется Common Platform Enumeration (CPE). CPEшифр содержит название приложения, разработчика, версию, что дает возможность идентифицировать библиотеку. Однако давайте вспомним, какую информацию мы встречаем, когда открываем Github или пакетные индексы. Название и автора, версию и лицензию. По этим данным CPE найти проблематично, здесь нужны алгоритмы машинного обучения и нечеткий поиск. Именно эта задача является сложной, над ней работают многие, в том числе и мы. От качества ее решения в значительной степени зависит гарантия безопасности используемого OSS.

– Как вы думаете, почему существующие средства анализа кода делают отдельно для разработчиков и для служб ИБ?

– Традиционно в компаниях есть специализация, все работают в рамках своей ответственности, и системы делают примерно так же. SCA-решения и статический анализ ориентированы на специалистов ИБ, юристов и разработчиков. Системы оценки качества кода – отдельная группа, которая ориентируется на тестировщиков, разработчиков и их руководителей.

Сейчас мы переживаем переломный момент, когда наступает время коллективной ответственности, DevSecOps тому яркий пример. При наличии такой коллективной ответственности все участники процесса разработки должны взаимодействовать друг с другом, а значит, и инструменты должны быть общими. Сейчас появляется множество инструментов на стыке областей: безопасность и разработка, безопасность и эксплуатация. Мы следуем этому тренду.

– Что вы думаете про качество и безопасность Open Source, каковы тенденции рисков, связанных с применением открытого кода?

– За последние пять лет объем Open Source увеличился более чем в сто раз, и с каждым годом мы включаем все больше подходящего открытого кода в наш проект, чтобы успевать в гонке за скоростью разработки. Таким образом, мы частично перекладываем ответственность за свой проект на сообщество Open Source, которое, однако, сопровождает программное обеспечение лишь по мере сил и возможностей. Уровень качества и безопасности у Open Source очень разный. Есть хорошие живые проекты с частым обновлением, разрабатываемые крупными сообществами, с отсутствием зависимости от единого разработчика. А есть код, который может быть популярным, но разработан он всего одним автором. Рассчитывать, что такая библиотека будет развиваться и дальше, – большой риск. Практика показывает, что часто полезный, удобный и надежный компонент со временем становится большим якорем технического долга, постепенно переходящим в Legacy.

Иногда живые качественные проекты могут неожиданно изменить тип лицензии, и их использование становится вирусным. Подобные зависимости приходится своевременно вычищать из проекта, потому что человек или команда, которые их сопровождали, забросили или перевели код под другую лицензию. Это отдельная работа, которая не всегда включается в скоуп разработки. И чем больше Open Source зависимостей, тем больше таких рисков, тем дороже становится сопровождать подобный проект без средств автоматизации.

Источник ►