Алексей Смирнов, CEO компании Profiscope
Дарья Орешкина, директор по развитию компании Web Control
По итогам участия в Tech Week в июне 2021 г. компания Web Control получила много вопросов про новое российское SCA-решение CodeScoring от компании Profiscope, но краткий формат общения на выставке не позволил раскрыть все детали, и мы выполняем свое обещание ответить на вопросы в отдельной публикации. Директор по развитию Web Control Дарья Орешкина собрала вопросы и задала их основателю решения CodeScoring Алексею Смирнову.
– Большое количество российских компаний заинтересовано в регистрации в реестре отечественного ПО и коммерциализации своих разработок. Какую практическую измеримую пользу приносят SCA при решении этих задач и почему вы подчеркиваете важность лицензионной чистоты?
– Надеюсь, про необходимость соблюдения авторского права объяснять не нужно, не говоря уже о проявлении уважения к разработчикам программного обеспечения и результатам их труда. С появлением реестра отечественного программного обеспечения в 2015 г. культура соблюдения авторского права в России в ИКТсекторе действительно стала развиваться. Если 10–15 лет назад разработчики принимали решение об использовании сторонних, в том числе и Open Source, компонентов по личным моральным-этическим соображениям, то сегодня практика соблюдения лицензий на вспомогательные компоненты выходит на новый уровень. Почему? Здесь есть несколько причин:
- Принимающая сторона стала следить за тем, что же она принимает.
- Цифровое пиратство как модный тренд постепенно уходит из жизни, а на смену ему приходит другое модное понятие – осознанное потребление.
- Появилась судебная практика, то есть "зарубежные лицензии", как их раньше называли, получили юридический статус и подобные случаи уже рассматриваются в арбитражных судах, пусть и с очень слабой подготовкой судебных экспертов.
В своих разъяснениях к подаче заявки в реестр Минцифры явно указывает на необходимость отслеживания применения сторонних компонентов (авторских произведений) в составе заявляемого программного обеспечения. Прямым текстом указывается запрет использования лицензий Copyleft-группы (GNU GPL, MPL и иных), которые являются свободными лицензиями, подразумевающими, что создаваемый продукт требует лицензирования под той же лицензией и не предполагает коммерческого использования. Уже только это требование вызывает проблемы у компаний, формирующих заявления. У продуктов сотни OSS-заимствований, чтобы проверить каждый на лицензию, потребуется время, а если найдется компонента с подобной лицензией, то время уйдет еще и на то, чтобы ее заменить на менее свободный, но более открытый аналог.
И это только начало, потому что не все лицензии сopyright-группы одинаково полезны. Есть такое понятие, как лицензионная совместимость (License Compliance), о которой люди, осуществляющие подготовку для внесения продукта в реестр, не задумываются или просто не знают. Ее суть заключается в том, что не все лицензии программного обеспечения можно применять в едином произведении (вашем программном продукте), и тонкости лицензий может выявить либо опытный юрист в этой области, либо специализированное программное обеспечение.
Но и здесь не стоит расслабляться, так как сторонние компоненты очень часто зависят от других сторонних компонент, в то же время получается, что ваш продукт состоит и из них. Такие элементы называются транзитивными зависимостями. Конечно, они тоже обладают своими лицензиями и проблемами совместимости. В нашей практике аудита регулярно выявляются популярные компоненты Open Source с "хорошей" лицензией, позволяющей коммерческое распространение, но после изучения транзитивных зависимостей выясняется, что эта "хорошая" лицензия установлена авторами проекта неправомерно и, следовательно, ваше применение такого компонента в проекте не снимает с вас ответственности.
– На данный момент Минцифры не проверяет ни лицензионную совместимость, ни транзитивные зависимости. Зачем об этом задумываться сегодня?
– Минцифры сейчас не проверяет транзитивные зависимости, и, возможно, на данном этапе это хорошо. Ко всему нужно приходить постепенно. Давайте на секунду представим масштабы изменений, если сейчас российский ИКТ-сегмент начнет заниматься вопросом лицензионной чистоты в полной мере. Ведь культура пиратства у многих в крови, так что боюсь, что накопленный таким образом технический долг из сторонних компонентов уже превышает не один годовой объем сегмента в стране. Важно то, что о соблюдении авторского права начали всерьез задумываться и Министерство играет определяющую роль в этом вопросе. Уже сегодня необходимо закладывать правильную основу программных продуктов – какие компоненты будут включаться и как должны быть выстроены процессы разработки для дальнейшего беспрепятственного развития.
Предлагаю посмотреть на опыт зарубежных компаний. Например, когда 15–20 лет назад в компаниях уровня Microsoft или Yahoo в "боевые" сборки программного обеспечения просачивались некорректные сторонние компоненты, все процессы разработки попросту останавливались и не было возможности что-либо "выкатить в прод" до момента исправления. Подчеркну, это компании, применяющие передовые мировые практики, но даже они теряли внушительные бюджеты. Что же говорить о ситуациях, когда коммерческий продукт выстроен на сторонних компонентах, на которых создаваться не имел права? Потери для бизнеса будут просто катастрофическими.
– Во многих компаниях разработка по происходит силами подрядчиков. Для заказчика такое по является черным ящиком. В чем ценность SCA при приемке и сдаче по в эксплуатацию?
– В практике аудита программного обеспечения мы часто сталкиваемся со случаями, когда крупный на первый взгляд проект выполняется малочисленной командой исполнителей, в сжатые сроки, с небольшим бюджетом. А на самом деле это проект с десятикратным бюджетом, сложнейшими функциональными требованиями и невысокой компетенцией заказчика по заглядыванию в черный ящик. Как правило, обоснование таких крупных проектов происходит "по линейке", то есть чем больше кода сдано, тем он дороже. Поэтому исполнитель этим пользуется и включает в сдаваемую кодовую базу большое количество сторонних компонентов (часто не соблюдая лицензии и, конечно же, не отслеживая вносимые уязвимости). Заказчики проводят приемку "на голубом глазу" и не видят подвоха.
Важно понимать, что использование открытых компонентов само по себе не является преступлением, это стандартная практика, но, чтобы уберечься от ситуации "раздутия" кодовой базы в целях поднятия стоимости, заказчику достаточно использовать инструменты композиционного анализа программного обеспечения (Software Composition Analysis), которые позволяют находить подобные включения чужого кода в принимаемые решения и выявлять риски в аспектах безопасности и лицензионной чистоты.
– Многие уже слышали про инструменты статического и динамического анализа и считают, что проверок SAST и DAST достаточно. зачем инвестировать в SCA?
– Анализ композиции программного кода (SCA) – это сегмент рынка инструментов тестирования безопасности приложений (AST), к которым относятся так называемое тестирование белого и черного ящика, Static Application Security Testing (SAST) и Dynamic Application Security Testing (DAST). Статический подход используется для проверки оригинальной кодовой базы проекта по настроенным правилам, динамический – проверяет сборку в режиме исполнения приложения. SAST-инструменты целесообразно применять для проверки проприетарного кода, который обычно составляет 20% кодовой базы проекта. У кого-то больше, у кого-то меньше. Для проверки оставшейся части кодовой базы, состоящей из Open Source, целесообразно использовать инструменты SCA, которые предназначены для анализа компонентов Open Source.
Инструменты SCA выполняют автоматическое сканирование кодовой базы приложения, включая связанные артефакты, такие как контейнеры и сборки, для обнаружения всех компонентов Open Source, поиска данных об их соответствии лицензионным требованиям и выявления уязвимостей безопасности. Обеспечивать безопасность разработки они начинают на этапе проектирования ваших решений пока они не "добрались" до этапа постановки в CI/CD-конвейер.
Инструменты SAST и DAST рекомендуется применять совместно для избежания крупных потерь. Тем не менее на сегодняшний день существует более 100 млн версий сторонних компонент, которые разработчики могут установить в проект, и напрямую безопасность их применения не проверяется устоявшимися подходами. Поэтому здесь важно сформулировать следующую формулу успеха безопасности: SAST, DAST & SCA.
Напомню, что сегодня сторонние компоненты могут составлять до 80–90% проектной базы и за ними обязательно нужно следить не меньше, чем за собственным кодом. Только при таком сочетании подходов к анализу проектов может быть обеспечена полная и, что важно, замкнутая инструментальная экосистема проверки на ошибки и безопасность. Конечно, нельзя исключать вопрос последующего ручного тестирования, но на то он и последующий.
Во избежание потерь важно с самого начала следить за всем тем, что ложится в основу программного продукта, как и из чего он производится. SCAрешения, в частности CodeScoring, встраиваются в конвейер DevSecOps и позволяют реализовывать корпоративные политики безопасности и лицензионной чистоты на наиболее ранних этапах разработки.
Источник: InformationSecurity