К основному содержимому
#Security

The Untold Story of Log4j and Log4Shell Christian Grobmeier GitHub (Рубрика Security)

#Security #Engineering #Software #Management #OpenSource

С большим интересом посмотрел историю про один из самых крупных факапов в истории безопасности, которую рассказывал непосредственный участник событий - Кристиан Гробмайер, мейнтейнер Apache Log4j, участник Apache Software Foundation. Человек, который в декабре 2021 внезапно оказался ответственным за "половину интернета".

Интересно, что я помню масштаб той истории и ее стремительное развитие - это было эпично. Но что же произошло? В 2021 в библиотеке Log4j нашли уязвимость максимального уровня 10 из 10 Log4Shell (CVE-2021-44228) - возможность удалённого выполнения кода через обычную строку логирования (${jndi:…}). Эксплуатация была элементарной, а Log4j был буквально везде: enterprise-системы, облака, гос-сервисы, игры. Например, в процессе работы над инцидентом Кристиана позвал его сын и показал, что даже его Minecraft сервер пал жертвой этой уязвимости ... А дальше был кризис

  • Несколько волонтёров, что поддерживали библиотеку на энтузиазме
  • Ноль сна и куча давления в стиле "чините быстрее"
  • Давление со стороны компаний и СМИ,
  • При этом мало поддержки и ноль вопросов о том, а как ребята себя чувствуют и нужна ли помощь

В общем, этот инцидент показал не баг в одной библиотеке, а системную проблему всей open-source-экосистемы. Если говорить про инсайты в общем, то они примерно такие и актуальны до сих пор

1️⃣ Open source ≠ безопасно по умолчанию Открытый код не означает автоматически защищённый код. Безопасность - это люди, процессы и поддержка, а не лицензия. 2️⃣ Масштаб библиотеки = масштаб риска Маленькая зависимость → тысячи продуктов → глобальный инцидент. Большинство компаний даже не знали, что у них есть Log4j, пока не стало поздно. Отсюда резкий интерес к SBOM (Software Bill of Materials) и прозрачности цепочки поставок. 3️⃣ Самая опасная уязвимость - незнание Мейнтейнеры часто не security-эксперты. Без обучения secure coding разработчики часто становятся точками отказа 4️⃣ Один-два мейнтейнера - это single point of failure (||если докапываться, то два - это уже не single||) Критичные библиотеки не могут держаться на энтузиазме пары людей. Деньги важны, но ещё важнее - участие компаний-потребителей. 5️⃣ Культура важнее технологий Агрессия, давление и обвинения делают экосистему слабее. Поддержка и сотрудничество - наоборот.

🌝 Что это значит для инженеров

  • Минимизируйте зависимости. Каждая библиотека - потенциальная атака.
  • Автоматизируйте обновления и CVE-алерты (Dependabot, SCA).
  • Не доверяйте входным данным никогда, даже "внутренним".
  • Отключайте опасные фичи по умолчанию (типа jdni)
  • Используйте defense-in-depth.
  • Генерируйте SBOM - знайте, из чего вы собрали продукт.
  • Нашли проблему в OSS - помогите, а не просто «репортните и забудьте».

🔥 Что это значит для тимлидов и CTO

  • Безопасность зависимостей = бизнес-риск, а не "техническая деталь"
  • У вас должен быть ответственный за OSS-цепочку и реакцию на CVE
  • SBOM - must-have, а не nice-to-have
  • Закладывайте время инженеров на вклад в критичные open-source-проекты.
  • Инвестируйте в обучение secure development
  • Планируйте регулярные апдейты зависимостей как часть roadmap
  • Готовьтесь к 0-day заранее, а не в Slack-панике

Итого, Log4Shell показал простую вещь - наш софт настолько безопасен, насколько безопасны его самые маленькие зависимости. А для того, чтобы они были лучше стоит не только использовать эти библиотеки, но и поддерживать их самим.

#Security #Engineering #Software #Management #OpenSource