управление открытым исходным кодом: как безопасно использовать библиотеки с открытым исходным кодом?

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

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

Тем не менее, код с открытым исходным кодом имеет риски - даже самая широко распознаваемая база кода. Никто не может гарантировать, что открытый исходный код не будет иметь ошибок, и что он примет процесс управления открытым исходным кодом, который соответствует требованиям корпоративного приложения в процессе разработки. Даже если в проекте с открытым исходным кодом есть активное сообщество пользователей, у него могут быть новые и старые уязвимости. Например, в этом году Framework Web Application Ruby On Rails сталкивалась с несколькими уязвимостями безопасности, причем около 200 000 веб -сайтов могут быть атакованы удаленным выполнением кода. Хуже того, эти ошибки появились в 2007 году, что означает, что все версии этой структуры имели такие проблемы в течение более 6 лет. В этой статье мы представим диапазон рисков, представленных открытым исходным кодом для корпоративных приложений и способов снижения рисков с использованием методов управления открытым исходным кодом.

#### открытый исходный код и уязвимые компоненты

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

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

Это серьезная проблема, чтобы иметь эти уязвимые компоненты в новых приложениях, поэтому он появляется в последнем списке уязвимого уязвимого приложения OWASP. В предыдущей версии списка OWASP он принадлежит к более общей записи «Ошибка безопасности», но теперь это автономная запись - Статья 9: «Использование компонентов с известными уязвимостями».

Например, OWASP отметил, что в 2011 году два компонента с уязвимостью достигли 22 миллионов загрузок. Первое - обойти аутентификацию Apache CXF: структура Apache CXF не может предоставить токен идентификации, поэтому злоумышленник может иметь полные разрешения на выполнение любого веб -сервиса. Второе - это язык экспрессии, подвергшиеся злоупотреблению, весной, рамки Java с открытым исходным кодом, которая позволяет злоумышленникам выполнять произвольный код для управления всем сервером. Каковы последствия этого? Пока корпоративные приложения используют эти проблематичные рамки, они могут стать игр в руках злоумышленников.

#### Внедрение безопасности программного обеспечения с помощью управления открытым исходным кодом

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

Однако не все проекты с открытым исходным кодом используют понятный механизм нумерации версий, поэтому отчеты об уязвимости не всегда указывают точно на уязвимые версии компонентов. К счастью, веб -сайты, такие как CVE и NVD, предоставляют услуги, которые облегчают поиск и запрос этой информации.

Чтобы улучшить управление открытым исходным кодом, команда разработчиков должна сначала создать и поддерживать последний список сторонних кодов, включая весь код зависимости и источники. Назначьте человека, ответственного за каждый источник, отслеживать списки рассылки, новости и обновления. Это не должно быть просто пассивным занятием; Поскольку не все новые уязвимости сообщаются в централизованном информационном центре, необходимо контролировать списки рассылки общественной безопасности. Некоторые команды могут обнаружить, что они должны уменьшить количество источников кода, которые они используют для повышения эффективности управления; И, безусловно, разработать стратегию управления использованием кода, такую ​​как бизнес -кейсы, оценки рисков и приемлемые разрешения.

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

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