Работа разработчика программного обеспечения довольно сумасшедшая: вам нужно постоянно узнавать о новых технологиях, понимать темы в предметной области, над которой вы работаете, оценивать, сколько времени потребуется, чтобы создать то, что вы никогда раньше не создавали, объяснять проблемы людям, у которых есть абсолютно без понятия. Кроме того, вам необходимо защитить свою программную систему от злоумышленников. Но с злоумышленниками обычно не проблема - пока они не возникнут. Это означает, что может случиться так, что безопасности уделяется мало внимания, поскольку кажется, что она не обеспечивает прямой ценности. А когда ценность становится очевидной, уже слишком поздно.

Учитывая, что разработчики так заняты многими другими темами и могут иметь трудные времена, чтобы обосновать необходимость улучшений безопасности, улучшения безопасности должны быть частью обычного рабочего процесса. Вы хотите, чтобы что-то работало полностью автоматически, которое позаботится об этом за вас.

В области безопасности много разных тем и много разных инструментов. Одна группа инструментов выполняет так называемый анализ состава программного обеспечения - короче SCA. Прочитав эту статью, вы поймете, что такое SCA и как он вам помогает.

Проблема 1. Вредоносное стороннее программное обеспечение

Программное обеспечение, написанное для причинения вреда, может попасть в ваши зависимости. Либо злоумышленник с опечаткой и типосквоттингом, либо троянский конь. Троянский конь - это программа, которая кажется полезной, но делает кое-что еще.

Проблема 2: уязвимое стороннее программное обеспечение

Чем сложнее становится программное обеспечение, тем сложнее удерживать в уме все его важные аспекты. Это может привести к уязвимостям, особенно со многими участниками.

Проблема 3: Лицензии на стороннее программное обеспечение

Вы также можете столкнуться с юридическими проблемами. Как организация, вы хотите решить, какие лицензии приемлемы. Допустимые будут в списке разрешенных. Затем вы хотите регулярно автоматически проверять любую зависимость по этому списку разрешений.

Типичные лицензии: MIT, BSD, Apache 2.0, LGPL, GPL, MPL.

Зайдите на tldrlegal.com, чтобы получить краткий обзор.

Как работает SCA

Проверить наличие вредоносных и уязвимых сторонних пакетов очень просто: списки блокировки. Если известно, что какая-то версия пакета (или всего пакета) вызывает проблемы, она попадает в черный список. Инструменты SCA могут проверять черные списки и предотвращать установку проблемного программного обеспечения.

Для лицензий у вас должен быть способ извлекать лицензии из пакета. Некоторые важные моменты, которые следует учитывать:

  • Авторы пакета могут добавлять альтернативные лицензии
  • Авторы пакета могут добавить несколько лицензий, и все они должны быть выполнены.
  • Авторы пакетов не могут (технически) не давать никаких лицензий - это означает, что вы не можете их использовать!
  • Авторы пакетов могут давать несовместимые лицензии, например в Python существует как минимум 3 различных способа обозначения лицензии.

Предварительное условие: спецификация материалов (BOM)

Вам необходимо знать, какое стороннее программное обеспечение вы используете. Для этого вы создаете так называемую спецификацию материалов. Звучит модно, но на самом деле это просто список программного обеспечения, которое вы используете. Обычно в языках программирования уже есть решения для этого:

Пожалуйста, дайте мне знать, как это называется в других языках - тогда я расширю этот список.

Примеры для инструментов SCA

Бесплатные решения:

Коммерческие решения:

  • Блэкдак
  • Dependabot: Я видел это несколько раз на Github.
  • Snyk для уязвимостей: в Github можно встретить довольно часто. Это бесплатно для программного обеспечения с открытым исходным кодом.

Резюме

Инструменты анализа состава программного обеспечения (SCA) могут вам очень помочь и обычно остаются в фоновом режиме. Интегрируйте их в свой конвейер непрерывной интеграции (CI), запускайте их регулярно как запланированную задачу. В большинстве случаев вам не нужно ничего делать. Но когда инструмент жалуется, это важно.

Что дальше?

В этой серии статей о безопасности приложений (AppSec) мы уже объяснили некоторые приемы злоумышленников 😈, а также приемы защитников 😇:

И вот-вот это:

  • CSRF 😈
  • DOS 😈
  • Вводные данные 😈
  • Криптоджекинг 😈
  • Единый вход 😇
  • Двухфакторная аутентификация 😇
  • Резервные копии 😇
  • Шифрование диска 😇

Дайте мне знать, если вас интересуют другие статьи о AppSec / InfoSec!