Угроза открытости

Аналитика от мировых исследователей кибербезопасности показывает то, что мы видим сейчас и на казахстанском рынке, – увеличение числа всевозможных стартапов, резкая нехватка разработчиков, а главное, необходимость выпускать продукты все быстрее, дабы опережать соперников. Это приводит к росту числа компаний-разработчиков, полагающихся модули на open source.

Open source – золотая жила для разработчиков, но невозможно не учитывать проблемы среды, где более 80% кода в новых приложениях может поступать из существующих репозиториев. Например, платформа Apache Log4j используется в 58% всех организаций и приложений в мире. Когда эксплойт был обнаружен, фиксировали более 1000 попыток его использования в секунду. Уязвимость Log4Shell – очевидное доказательство того, что модель контроля «многих глаз», предлагаемая open source, не соответствует цели.

Какие риски стоит учесть, если вы активно используете open source в своей работе?

Известные и задокументированные уязвимости.
Компоненты с открытым исходным кодом могут содержать уязвимости, добавленные разработчиками еще до исправления. Далее уязвимость в модуле попадает в конечное ПО – и вуаля: конфиденциальность, целостность или доступность системы и данных пользователей под угрозой.

Компрометация легитимных пакетов ПО.
Злоумышленники атакуют всю цепочку поставки «опенсорсного» ПО, включая инфраструктуру распространения, чтобы внедрить вредоносный код в компонент. Если захватить учетные записи разработчиков или службы поддержки модуля open source, вы всегда будете получать зараженное ПО с вредоносным кодом под видом легитимных пакетов.

Имена модулей как часть обмана.
Злоумышленники могут создавать компоненты с именами, похожими на имена легитимных компонентов с открытым исходным кодом или системных компонентов. Используя опечатки, названия с орфографической ошибкой в имени исходного компонента, но от имени легитимного автора (чья «учетка» уже захвачена), злоумышленник добивается того, чтобы пользователи загружали и использовали вредоносные компоненты, которые они считают легитимными, пока автор не в курсе.

Устаревшее или неподдерживаемое ПО.
Зачастую для этого нет разумных причин, но тем не менее разработчики часто используют устаревшую версию кода при наличии обновленных. Это может привести к тому, что будут упущены важные патчи безопасности и, как следствие, останутся эксплуатируемые преступниками уязвимости.

Что же делать, если ваши R&D/CTO не готовы отказаться полностью от модулей open source или снизить их применение кардинально?

1. Регулярно сканируйте код для обнаружения скомпрометированных пакетов. Предотвращение появления скомпрометированных пакетов кода в репозиториях – сложная проблема, поскольку не существует универсального решения. Специалисты помогут выбрать приоритеты мер безопасности, исходя из текущих рисков.

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

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