Упреждающее обеспечение безопасности внешнего интерфейса с помощью программного обеспечения с открытым исходным кодом (OSS)
Почему важна безопасность программного обеспечения с открытым исходным кодом?
Опрос 2021 года сообщает, что девять из 10 компаний используют его, а предприятия по всему миру используют OSS. Большинство развернутых веб-систем в значительной степени зависят от библиотеки с открытым исходным кодом и, таким образом, подвержены различным уязвимостям, которые затрагивают Интернет.
Разработчики внешнего интерфейса иногда виноваты в том, что сильно полагаются на библиотеки ОС и зависимости во всем, от аутентификации до пользовательского интерфейса.
Таким образом, незначительная уязвимость может привести к разрушению всей экосистемы, использующей эту зависимость. Например, вот список некоторых зависимостей модулей узла React.
Список на самом деле намного больше (фактическое количество модулей — 1006). В большинстве случаев мы редко осознаем, что на самом деле зависим от такого количества модулей, когда пишем фрагмент кода.
Давайте рассмотрим несколько различных способов улучшить веб-безопасность вашей библиотеки программного обеспечения с открытым исходным кодом (OSS).
✔️ Используйте инструменты для проверки уязвимостей безопасности
Используйте инструменты для проверки уязвимостей безопасности в вашей зависимости. Вы, наверное, уже знаете об аудите npm, который поставляется вместе с последней версией npm.
Вот выдержка из блога npm:
npm audit — это новая команда, которая выполняет мгновенную проверку безопасности дерева зависимостей вашего проекта. Отчеты об аудите содержат информацию об уязвимостях безопасности в ваших зависимостях и могут помочь вам устранить уязвимость, предоставляя простые в использовании команды npm и рекомендации по дальнейшему устранению неполадок
Запустите «аудит npm» на корневом уровне проекта, и вы получите такой результат, как👇
Также у нас есть инструмент командной строки с открытым исходным кодом от OWASP под названием Проверка зависимостей, который можно использовать для мониторинга нашей кодовой базы.
Кроме того, существуют коммерческие организации, такие как Сник, которые проводят бесплатный анализ безопасности кода с использованием проприетарной уязвимости.
✔️ Жесткие правила и стандарты безопасности
Жесткие правила безопасности и стандарты безопасности перед использованием зависимости
Вот несколько вопросов, которые вы должны задать себе, прежде чем принять решение об импорте модуля в свой проект:
- Находится ли библиотека с открытым исходным кодом в активном состоянии разработки или устарела?
- Библиотека протестирована и готова к работе?
- Есть ли популярная альтернатива библиотеке?
- Есть ли серьезные проблемы в системе отслеживания проблем, о которых еще не позаботились?
Необходимо применить политику, требующую от разработчиков доказать, что зависимость не имеет известных уязвимостей. Открытый проект безопасности веб-приложений — хорошее место, чтобы быть в курсе известных уязвимостей.
✔️ Протестируйте свою библиотеку и зависимости
Тщательно протестируйте все свои библиотеки и зависимости OSS на наличие взломанного кода и возможных точек вторжения. Надлежащее тестирование и проверка кода могут уберечь вас от неприятностей, даже если в одной из зависимостей будет обнаружена уязвимость. Зависимость, безопасная в одной среде, может быть небезопасной в другой среде.
✔️ Сосредоточьтесь на большем количестве встроенных инструментов
Создавайте собственные инструменты вместо неподдерживаемых (устаревших) библиотек. Вы все еще используете неподдерживаемые библиотеки OSS с истекшим сроком действия? Это, наверное, не очень хорошая идея. Подумайте о создании собственного объекта кода и сопоставьте путь обслуживания для этой сборки.
Таким образом, мы можем перепрофилировать устаревший код, а затем вернуть его сообществу OSS.
Ссылки и ссылки
eslinst https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes, owasp https://owasp.org/www-project-top-ten/, zdnet https://www.zdnet.com/, MDN https://developer.mozilla.org/en-US/docs/Web/Security
