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

исправляет историю так, чтобы ничего не светилось. Ну и конечно же, вопросы внутреннего и внешнего заимствования оригиналь- ного кода, являющегося собственностью компании, вне зоны внимания тради- ционных SCA и систем статического ана- лиза кода. Наш опыт работы с заказчи- ками говорит о том, что это неотъемле- мая часть аудита кода, и мы это делаем. – При сравнении различных SCA заказчики часто спрашивают, насколько полная у вас база уязвимостей. Как вы думаете, достаточно ли иметь самую боль- шую базу уязвимостей, чтобы гарантировать безопасность используемых OSS-пакетов? – Подключить много источников несложно, сложно с ними жить, потому что они разрозненные, содержат откро- венно "грязную" информацию, которую надо регулярно актуализировать, отсле- живать, очищать, классифицировать. Информация о большинстве уязвимостях публикуется в открытом доступе, и для ее получения не нужно покупать SCA. Но как мне найти в базе уязвимостей библиотеку, которая используется в моем проекте? Есть подход к единому именованию приложений, которое называется Com- mon Platform Enumeration (CPE). CPE- шифр содержит название приложения, разработчика, версию, что дает воз- можность идентифицировать библиоте- ку. Однако давайте вспомним, какую информацию мы встречаем, когда откры- ваем Github или пакетные индексы. Название и автора, версию и лицензию. По этим данным CPE найти проблема- тично, здесь нужны алгоритмы машин- ного обучения и нечеткий поиск. Именно эта задача является сложной, над ней работают многие, в том числе и мы. От качества ее решения в значительной степени зависит гарантия безопасности используемого OSS. – Как вы думаете, почему суще- ствующие средства анализа кода делают отдельно для разработ- чиков и для служб ИБ? – Традиционно в компаниях есть спе- циализация, все работают в рамках своей ответственности, и системы делают примерно так же. SCA-решения и статический анализ ориентированы на специалистов ИБ, юристов и разра- ботчиков. Системы оценки качества кода – отдельная группа, которая ори- ентируется на тестировщиков, разра- ботчиков и их руководителей. Сейчас мы переживаем переломный момент, когда наступает время коллек- тивной ответственности, DevSecOps тому яркий пример. При наличии такой кол- лективной ответственности все участ- ники процесса разработки должны взаи- модействовать друг с другом, а значит, и инструменты должны быть общими. Сейчас появляется множество инстру- ментов на стыке областей: безопасность и разработка, безопасность и эксплуа- тация. Мы следуем этому тренду. – Что вы думаете про качество и безопасность Open Source, каковы тенденции рисков, свя- занных с применением открытого кода? – За последние пять лет объем Open Source увеличился более чем в сто раз, и с каждым годом мы включаем все больше подходящего открытого кода в наш проект, чтобы успевать в гонке за скоростью разработки. Таким образом, мы частично перекладываем ответствен- ность за свой проект на сообщество Open Source, которое, однако, сопро- вождает программное обеспечение лишь по мере сил и возможностей. Уро- вень качества и безопасности у Open Source очень разный. Есть хорошие живые проекты с частым обновлением, разрабатываемые крупными сообще- ствами, с отсутствием зависимости от единого разработчика. А есть код, кото- рый может быть популярным, но разра- ботан он всего одним автором. Рассчи- тывать, что такая библиотека будет раз- виваться и дальше, – большой риск. Практика показывает, что часто полез- ный, удобный и надежный компонент со временем становится большим якорем технического долга, постепенно пере- ходящим в Legacy. Иногда живые качественные проекты могут неожиданно изменить тип лицен- зии, и их использование становится вирусным. Подобные зависимости при- ходится своевременно вычищать из про- екта, потому что человек или команда, которые их сопровождали, забросили или перевели код под другую лицензию. Это отдельная работа, которая не всегда включается в скоуп разработки. И чем больше Open Source зависимостей, тем больше таких рисков, тем дороже ста- новится сопровождать подобный проект без средств автоматизации. l • 43 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru Shazam для кода Продукты технологического бизнеса часто являются черным ящиком для управленцев. Распознать неизвестное помогают решения "Shazam для кода", таковым является и CodeScoring, применяющий современные подходы из области Code Mining, используя алгоритмы машинного обучения и анализа текстов на синтетических и естественных языках. Ваше мнение и вопросы присылайте по адресу is@groteck.ru Реклама