Я исследую более длинную статью о некоторых конкретных программных решениях. Это заставило меня понять, что есть смысл в создании контрольного списка того, на что обращать внимание при поиске на github программного обеспечения с открытым исходным кодом для использования с вашей платежной платформой. При этом я думаю, что могу сделать несколько безопасных предположений:
Лицензия
Возможно, самая большая проблема - это лицензия, по которой выпущено программное обеспечение. Удивительное количество программного обеспечения на github не имеет явной лицензии. Если вы видите программное обеспечение без лицензии, вам следует держаться от него подальше. Тот факт, что он опубликован в Интернете, не означает, что вы имеете право использовать его! Программное обеспечение без лицензии - это фактически программное обеспечение, которое вы не имеете права использовать . Для личного веб-сайта это может быть нормально. Для коммерческого проекта это большая проблема.
Серии лицензий GPL известны как лицензии с авторским левом. Эти лицензии, как правило, налагают на вас обязательства делиться проприетарным кодом, который вы связываете с ними при определенных обстоятельствах. Эти обстоятельства зависят от лицензии: в случае обычной GPL распространение комбинированного программного обеспечения за пределами вашей организации вызывает необходимость выпуска исходного кода для применения; тогда как для AGPL простое предложение коммерческой услуги с использованием кода AGPL означает, что вы должны сделать свой исходный код свободным.
Всегда просматривайте файл README или LICENSE, чтобы убедиться, что условия лицензии соответствуют утверждениям github. Если вы не можете найти условия, будьте осторожны!
Существует гораздо больше разрешительных лицензий с открытым исходным кодом, таких как лицензии BSD, Apache 2.0, MIT и т. д. Для каждой из них вы, как правило, можете использовать программное обеспечение для коммерческого использования при соблюдении некоторых основных требований, таких как предоставление авторских прав оригинальным авторам. Для каждого из них вам необходимо внимательно прочитать лицензию и убедиться, что вы делаете все необходимое для соблюдения условий лицензии, в противном случае вы не имеете права использовать программное обеспечение.
Я не юрист, но знаю, что нужно проконсультироваться с одним из них при использовании открытого исходного кода для коммерческих приложений.
Источник доступен?
Тот факт, что что-то публикуется на github, не означает автоматически, что его исходный код доступен для просмотра. Мне удалось найти симулятор платежного HSM, в котором на github публиковались только файлы Java JAR, то есть скомпилированный объектный код. Имея доступ к исходному коду не является гарантией безопасности . Но наличие источника, по крайней мере, означает, что у вас есть возможность проверить его на наличие уязвимостей и явно вредоносного кода.
Если у вас есть доступ только к скомпилированному коду, вы должны подумать, почему? Если кто-то не желает публиковать исходный код, но готов опубликовать объектный код, в лучшем случае он действительно не имеет в глубине души интересов сообщества открытого исходного кода. В худшем случае они прячут там вредоносный код , ожидая, когда кто-нибудь укусит. В частности, если код предназначен для чего-то эзотерического, например интерфейса к платёжному HSM, вероятность возникновения этой проблемы повышается, поскольку единственные люди, использующие код, могут быть интересны злоумышленнику.
Программное обеспечение редко бывает без ошибок, и важно, чтобы вы могли исправить ошибки в программном обеспечении, от которого зависите. Для коммерческого программного обеспечения вы можете запросить обновление у поставщика. Разрешение не гарантируется, но это то, за что вы платите. Для программного обеспечения с открытым исходным кодом у вас есть возможность исправить это самостоятельно или поработать с сообществом для исправления. Но для скомпилированных BLOB-объектов у вас может не быть возможности включить исправления.
Управление уязвимостями
Для работы в области PCI наличие развитой программы управления уязвимостями по сути является обязательным требованием. Имея дело с программным обеспечением с открытым исходным кодом, вы должны учитывать управление уязвимостями как для программного обеспечения, которое вы собираетесь использовать, так и для любых зависимостей этого программного обеспечения.
Цель управления уязвимостями - значительно снизить риски, связанные с использованием программного обеспечения. Если библиотека с открытым исходным кодом и ее зависимости хорошо известны, то управлять уязвимостями довольно просто.
Проблемы с открытым исходным кодом постоянно обнаруживаются. Об этих уязвимостях сообщают через программы ответственного раскрытия информации и каталогизируют в таких базах данных, как Национальная база данных уязвимостей, управляемая NIST. Здесь назначаются те номера CVE, которые вы видите. Существуют сканеры, которые определяют версии используемого вами программного обеспечения. Некоторые даже можно использовать бесплатно! Эти сканеры сопоставляют версии программного обеспечения с NVD, чтобы находить известные уязвимости и сообщать об этих уязвимостях.
При использовании исключительно хорошо известных компонентов, таких как Eclipse Jetty, любые проблемы, известные в открытом доступе, будут быстро видны вам через ваше программное обеспечение для управления уязвимостями. Но если вы используете какое-то необычное программное обеспечение с github, о форках или проблемах не сообщалось, и, следовательно, без публичной видимости, вы в основном будете сами по себе.
Высококачественные чудаки
Итак, вы нашли редкость. Программное обеспечение с открытым исходным кодом, которое решает именно вашу проблему, но, похоже, никто другой не использует. Повторная реализация этой функции потребует у вас достаточно времени и усилий, поэтому вы бы предпочли просто использовать найденный код. Как довести это до приемлемого уровня риска?
Проверьте лицензию, чтобы убедиться, что у вас есть право на ее разветвление, изменение и распространение. Предполагая, что вы можете разветвить программу, сделайте это. Поддерживайте собственную версию программного обеспечения и приносите ее домой. Относитесь к этому новому форку как к своему собственному программному обеспечению, соблюдая условия лицензии. Если вам нужно, опубликуйте изменения обратно в сообщество. Если вы должны указать в своей документации ссылку на оригинальных авторов, создайте для этого процесс.
Что значит относиться к нему как к собственному программному обеспечению? Запустите его через процесс, совместимый с PCI DSS. Попросите разработчиков проверить код на предмет проблем безопасности. Запустите код с помощью инструментов статического и динамического анализа и очень серьезно отнеситесь к его результатам. Устраните эти находки путем исправления кода, а не путем принятия риска. После этого не принимайте вслепую изменения в своем форке, не применяя такой же уровень строгости.
- Если вы читаете это здесь, вы, вероятно, профессионал в области информационной безопасности; и
- Если вы ищете программное обеспечение с открытым исходным кодом для платежной платформы, вы занимаетесь коммерческой деятельностью.
Лицензия
Возможно, самая большая проблема - это лицензия, по которой выпущено программное обеспечение. Удивительное количество программного обеспечения на github не имеет явной лицензии. Если вы видите программное обеспечение без лицензии, вам следует держаться от него подальше. Тот факт, что он опубликован в Интернете, не означает, что вы имеете право использовать его! Программное обеспечение без лицензии - это фактически программное обеспечение, которое вы не имеете права использовать . Для личного веб-сайта это может быть нормально. Для коммерческого проекта это большая проблема.
Серии лицензий GPL известны как лицензии с авторским левом. Эти лицензии, как правило, налагают на вас обязательства делиться проприетарным кодом, который вы связываете с ними при определенных обстоятельствах. Эти обстоятельства зависят от лицензии: в случае обычной GPL распространение комбинированного программного обеспечения за пределами вашей организации вызывает необходимость выпуска исходного кода для применения; тогда как для AGPL простое предложение коммерческой услуги с использованием кода AGPL означает, что вы должны сделать свой исходный код свободным.
Всегда просматривайте файл README или LICENSE, чтобы убедиться, что условия лицензии соответствуют утверждениям github. Если вы не можете найти условия, будьте осторожны!
Существует гораздо больше разрешительных лицензий с открытым исходным кодом, таких как лицензии BSD, Apache 2.0, MIT и т. д. Для каждой из них вы, как правило, можете использовать программное обеспечение для коммерческого использования при соблюдении некоторых основных требований, таких как предоставление авторских прав оригинальным авторам. Для каждого из них вам необходимо внимательно прочитать лицензию и убедиться, что вы делаете все необходимое для соблюдения условий лицензии, в противном случае вы не имеете права использовать программное обеспечение.
Я не юрист, но знаю, что нужно проконсультироваться с одним из них при использовании открытого исходного кода для коммерческих приложений.
Источник доступен?
Тот факт, что что-то публикуется на github, не означает автоматически, что его исходный код доступен для просмотра. Мне удалось найти симулятор платежного HSM, в котором на github публиковались только файлы Java JAR, то есть скомпилированный объектный код. Имея доступ к исходному коду не является гарантией безопасности . Но наличие источника, по крайней мере, означает, что у вас есть возможность проверить его на наличие уязвимостей и явно вредоносного кода.
Если у вас есть доступ только к скомпилированному коду, вы должны подумать, почему? Если кто-то не желает публиковать исходный код, но готов опубликовать объектный код, в лучшем случае он действительно не имеет в глубине души интересов сообщества открытого исходного кода. В худшем случае они прячут там вредоносный код , ожидая, когда кто-нибудь укусит. В частности, если код предназначен для чего-то эзотерического, например интерфейса к платёжному HSM, вероятность возникновения этой проблемы повышается, поскольку единственные люди, использующие код, могут быть интересны злоумышленнику.
Программное обеспечение редко бывает без ошибок, и важно, чтобы вы могли исправить ошибки в программном обеспечении, от которого зависите. Для коммерческого программного обеспечения вы можете запросить обновление у поставщика. Разрешение не гарантируется, но это то, за что вы платите. Для программного обеспечения с открытым исходным кодом у вас есть возможность исправить это самостоятельно или поработать с сообществом для исправления. Но для скомпилированных BLOB-объектов у вас может не быть возможности включить исправления.
Управление уязвимостями
Для работы в области PCI наличие развитой программы управления уязвимостями по сути является обязательным требованием. Имея дело с программным обеспечением с открытым исходным кодом, вы должны учитывать управление уязвимостями как для программного обеспечения, которое вы собираетесь использовать, так и для любых зависимостей этого программного обеспечения.
Цель управления уязвимостями - значительно снизить риски, связанные с использованием программного обеспечения. Если библиотека с открытым исходным кодом и ее зависимости хорошо известны, то управлять уязвимостями довольно просто.
Проблемы с открытым исходным кодом постоянно обнаруживаются. Об этих уязвимостях сообщают через программы ответственного раскрытия информации и каталогизируют в таких базах данных, как Национальная база данных уязвимостей, управляемая NIST. Здесь назначаются те номера CVE, которые вы видите. Существуют сканеры, которые определяют версии используемого вами программного обеспечения. Некоторые даже можно использовать бесплатно! Эти сканеры сопоставляют версии программного обеспечения с NVD, чтобы находить известные уязвимости и сообщать об этих уязвимостях.
При использовании исключительно хорошо известных компонентов, таких как Eclipse Jetty, любые проблемы, известные в открытом доступе, будут быстро видны вам через ваше программное обеспечение для управления уязвимостями. Но если вы используете какое-то необычное программное обеспечение с github, о форках или проблемах не сообщалось, и, следовательно, без публичной видимости, вы в основном будете сами по себе.
Высококачественные чудаки
Итак, вы нашли редкость. Программное обеспечение с открытым исходным кодом, которое решает именно вашу проблему, но, похоже, никто другой не использует. Повторная реализация этой функции потребует у вас достаточно времени и усилий, поэтому вы бы предпочли просто использовать найденный код. Как довести это до приемлемого уровня риска?
Проверьте лицензию, чтобы убедиться, что у вас есть право на ее разветвление, изменение и распространение. Предполагая, что вы можете разветвить программу, сделайте это. Поддерживайте собственную версию программного обеспечения и приносите ее домой. Относитесь к этому новому форку как к своему собственному программному обеспечению, соблюдая условия лицензии. Если вам нужно, опубликуйте изменения обратно в сообщество. Если вы должны указать в своей документации ссылку на оригинальных авторов, создайте для этого процесс.
Что значит относиться к нему как к собственному программному обеспечению? Запустите его через процесс, совместимый с PCI DSS. Попросите разработчиков проверить код на предмет проблем безопасности. Запустите код с помощью инструментов статического и динамического анализа и очень серьезно отнеситесь к его результатам. Устраните эти находки путем исправления кода, а не путем принятия риска. После этого не принимайте вслепую изменения в своем форке, не применяя такой же уровень строгости.
