Comments 9
Последний вопрос забавен в отрыве от необходимости аудита исходников (что из них действительно собирается целевое приложение) со стороны депозитория. Без этого нечего опасаться, что исходники утекут: в депозитории может, к примеру, храниться ключ от зашифрованного архива (копеечная услуга). Ну и возможность, что разработчик вместо актуальных исходников подсунет устаревшие или мусор, тоже не исключается.
Вероятно, можно даже построить схему так, чтобы депозиторий проверил исходники (на изолированном компе), заинтересованные стороны подписали бы архив, а незашифрованные данные были бы затёрты. Но это для случая совсем уж серьёзного недоверия разработчика депозиторию :-)
Вероятно, можно даже построить схему так, чтобы депозиторий проверил исходники (на изолированном компе), заинтересованные стороны подписали бы архив, а незашифрованные данные были бы затёрты. Но это для случая совсем уж серьёзного недоверия разработчика депозиторию :-)
Аудит важная вещь. Некоторые предоставляют его при определенном уровне (вот тут, например, есть список https://www.escrowtech.com/technical-verification.php). От простой проверки читаемости, до сборки кода.
Скажу, что идея с архивом и ключом мне нравится. Будет работать при определенных условиях.
Вижу несколько моментов. При использовании архива обязанность за сохранность кода переходит к клиенту. Не каждый готов ее брать на себя, с учетом того, что сервис аудита уже оплачен. Плюс надо назначить ответственного за хранение и новых версий тоже. Средства шифрования должны быть разрешены к использованию в стране, и должны быть инструменты для шифровки дешифровки.
Скажу, что идея с архивом и ключом мне нравится. Будет работать при определенных условиях.
Вижу несколько моментов. При использовании архива обязанность за сохранность кода переходит к клиенту. Не каждый готов ее брать на себя, с учетом того, что сервис аудита уже оплачен. Плюс надо назначить ответственного за хранение и новых версий тоже. Средства шифрования должны быть разрешены к использованию в стране, и должны быть инструменты для шифровки дешифровки.
Ну, можно наоборот: ключ у клиента, архив у депозитария. Всё равно место на диске (или вообще на лентах, это архив с крайне редким извлечением) много дешевле, чем сопутствующие услуги. Или (чтобы предусмотреть ситуацию «клиент потерял ключ») ещё как разделить (в голову приходят всякие схемы восстановления ключа – типа части ключа хранятся у пяти людей так, что любые трое могут его восстановить – не помню, как алгоритм называется, так что найти не могу, но на поржать – www.problems.ru/view_problem_details_new.php?id=60384 )
С учетом того, что все алгоритмы и так известны, а разбираться в чужих исходниках удовольствие сомнительное, то ценность стороннего кода невелика.
По исходнику можно найти катастрофическое количество дыр в безопасности. Можно похоронить всю компанию, чьи исходники утекли (если понятие дыр в безопасности применимо для данного класса продуктов), т.к. найденные дыры нельзя будет быстро пофиксить. Представьте какой-нибудь whatsup
Да, но ведь безопасность продукта не определяется закрытостью кода. И наоборот — защита исходников не инструмент обеспечения безопасности.
Конечно, так должно быть в идеальном мире, но на самом деле нет.
Чтобы так было исходник продукта должны открыть все желающим изучить его, объявить багбаунти и фиксить все баги, что нашли.
И чтобы так было качество кода продукта должно быть высоким, о безопасности должны постоянно думать.
Это всё часто не нужно коммерческим компаниям.
Чтобы так было исходник продукта должны открыть все желающим изучить его, объявить багбаунти и фиксить все баги, что нашли.
И чтобы так было качество кода продукта должно быть высоким, о безопасности должны постоянно думать.
Это всё часто не нужно коммерческим компаниям.
Мой случай частный, конечно, но все компании, с которыми я работал имели строгие политики по безопасности кода. Плюс есть стандарты, соответствие которым требуют заказчики.
Сокрытие кода не инструмент повышения безопасности, так как есть методики поиска дыр и в скомпилированном варианте. То же дизасемблирование.
Открытие исходников также не инструмент повышения безопасности. Исследовать его будут единицы. Я бы приглашал по контракту конкретных специалистов на на анализ возможных дыр. Взгляд со стороны всегда полезен.
Баг баунти хороший дополнительный способ. Он, кстати, чаще используется, чем видно в публичном поле. В схеме вендор — клиенты.
Но это все если отходить от темы эскроу. Риск выявления проблем с безопасностью кода из-за утечки исходников из депозитария крайне низкий.
И спасибо за комментарии! Это всегда делает тему живой
Сокрытие кода не инструмент повышения безопасности, так как есть методики поиска дыр и в скомпилированном варианте. То же дизасемблирование.
Открытие исходников также не инструмент повышения безопасности. Исследовать его будут единицы. Я бы приглашал по контракту конкретных специалистов на на анализ возможных дыр. Взгляд со стороны всегда полезен.
Баг баунти хороший дополнительный способ. Он, кстати, чаще используется, чем видно в публичном поле. В схеме вендор — клиенты.
Но это все если отходить от темы эскроу. Риск выявления проблем с безопасностью кода из-за утечки исходников из депозитария крайне низкий.
И спасибо за комментарии! Это всегда делает тему живой
Риск выявления проблем с безопасностью кода из-за утечки исходников из депозитария крайне низкий.
Это что значит? Что исходники с низкой вероятностью утекут? Это один вопрос. А вот если утекут, то для многих продуктов риск обнаружения уязвимостей хакерами — крайне высокий. Не увидел в вашем рассказе про идеальный мир и розовых поней в нём, какого-либо опровержения этому.
Это что значит? Что исходники с низкой вероятностью утекут?
Я имею ввиду, что если взять вероятность утечки исходников умножить на вероятность того, что они будут исследованы хакерами, на вероятность того, что будет найдена используемая уязвимость, то общая вероятность угрозы будет крайне низкой.
Общая безопасность информационной системы зависит от многих факторов. Это может быть ПО, к которму нет доступа извне. Или само ПО может мониториться на предмет подозрительной активности внутри сети.
Все же мне кажется, что пример про уязвимости в утекшем коде больше теоретический. Я буду рад увидеть реальные примеры.
Единственное, что я сам нашел — это найденную уязвимость в утекшем коде Boeing 787 https://www.wired.com/story/boeing-787-code-leak-security-flaws/.
Эта уязвимость не могла использоваться на практике из-за наличия других инструментов защиты.
Sign up to leave a comment.
Дополнение к теме code escrow – депонированию исходного кода