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

Предлагаю посмотреть на опыт зару- бежных компаний. Например, когда 15–20 лет назад в компаниях уровня Microsoft или Yahoo в "боевые" сборки программного обеспечения просачива- лись некорректные сторонние компо- ненты, все процессы разработки попро- сту останавливались и не было воз- можности что-либо "выкатить в прод" до момента исправления. Подчеркну, это компании, применяющие передовые мировые практики, но даже они теряли внушительные бюджеты. Что же гово- рить о ситуациях, когда коммерческий продукт выстроен на сторонних компо- нентах, на которых создаваться не имел права? Потери для бизнеса будут просто катастрофическими. – Во многих компаниях разра- ботка по происходит силами под- рядчиков. Для заказчика такое по является черным ящиком. В чем ценность SCA при приемке и сдаче по в эксплуатацию? – В практике аудита программного обеспечения мы часто сталкиваемся со случаями, когда крупный на первый взгляд проект выполняется малочислен- ной командой исполнителей, в сжатые сроки, с небольшим бюджетом. А на самом деле это проект с десятикратным бюджетом, сложнейшими функциональ- ными требованиями и невысокой компе- тенцией заказчика по заглядыванию в черный ящик. Как правило, обоснование таких крупных проектов происходит "по линейке", то есть чем больше кода сдано, тем он дороже. Поэтому исполнитель этим пользуется и включает в сдаваемую кодовую базу большое количество сто- ронних компонентов (часто не соблюдая лицензии и, конечно же, не отслеживая вносимые уязвимости). Заказчики про- водят приемку "на голубом глазу" и не видят подвоха. Важно понимать, что использование открытых компонентов само по себе не является преступлением, это стандарт- ная практика, но, чтобы уберечься от ситуации "раздутия" кодовой базы в целях поднятия стоимости, заказчику достаточно использовать инструменты композиционного анализа программного обеспечения (Software Composition Ana- lysis), которые позволяют находить подобные включения чужого кода в при- нимаемые решения и выявлять риски в аспектах безопасности и лицензионной чистоты. – Многие уже слышали про инструменты статического и дина- мического анализа и считают, что проверок 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 и позволяют реализовывать корпоратив- ные политики безопасности и лицен- зионной чистоты на наиболее ранних этапах разработки. l • 67 Безопасная разраБотка www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru Реклама