Here is the original English version of this interview.
В этом году компания спикеров Moscow Python Conf++ подобралась что надо (то есть как, подобралась — Программный комитет подобрал). Но кому интересно изучать достижения, куда интереснее, что спикер думает по поводу волнующих нас самих вопросов. Чтобы это узнать, получить инсайдерскую информацию или совет более опытного разработчика, и нужно общаться на конференциях. Но я воспользовался положением и взял небольшое интервью у нашего докладчика Кашала Даса (Kushal Das).
Отличительная черта выступлений Кушала в том, что он регулярно обнародует «секретные» способы сломать Python-код и в противовес показывает, как написать код так, чтобы АНБ не смогло его взломать. На нашей конференции Кушал расскажет, как безопасно разрабатывать и деплоить Python-код, поэтому о безопасности я его и расспрашивал.
— Кушал, расскажите, пожалуйста, немного о себе и о своей работе с Python и тому подобными вещами.
Кушал Дас: Я живу в Индии, сейчас работаю технологом по общественным интересам в американской некоммерческой организации Freedom of the Press Foundation, где помогаю поддерживать проект SecureDrop. SecureDrop — это информационная платформа с открытым исходным кодом. Основной язык здесь Python.
Помимо этого, я занимаюсь другими open source проектами, в том числе самим языком Python. Я один из Core-разработчиков CPython, а также член Совета директоров Python Software Foundation.
Я работаю с Python с 2005 года, и почти вся моя карьера связана с этим языком, а также с Linux. Это два основных направления мои интересов. Еще я вхожу в группу Core-разработчиков проекта Tor Project. Как многие уже знают, Tor помогает сохранять конфиденциальность в интернете.
— Tor — потрясающий проект, им пользуются разработчики по всему миру, чтобы получить доступ к API и документации, заблокированным, к примеру, из-за местных законов. Ваше выступление будет построено вокруг безопасности, поэтому у меня есть несколько вопросов.
Прежде всего, есть мнение, что для обычного разработчика без специальной подготовки безопасность сама по себе слишком сложна. Считается, что мы, как отрасль, должны обеспечить инструменты и экосистему, чтобы создаваемое нами ПО было безопасным по умолчанию.
Как вы думаете, что все-таки лучше: обучать людей безопасности или предоставлять им какие-то инструменты?
Кушал Дас: Думаю, и то, и другое. Действительно, безопасность — сложный вопрос. Однако, если начинающий программист проходит базовые тренинги или работает в команде, то учится избегать большинство распространенных проблем.
Чаще всего реальные ошибки в системе безопасности, такие как взлом, утечка или кража данных, возникают из-за неправильной конфигурации, отсутствия обновлений или некорректного, порой хулиганского кода.
Думаю, большинства основных ошибок можно избежать, если обучать как новичков, так и «старожилов» отрасли. Кроме того, некоторые вещи, недоступные человеческому глазу, можно выявлять с помощью новых инструментов, новой автоматизации, новых процессов.
Очень простой пример — проверки зависимостей, которые теперь есть в GitHub. Если Python-приложение содержит ошибки или использует какую-то старую версию независимого модуля, и есть определенная уязвимость, описанная в CVE, GitHub может сказать вам как разработчику: «Эй! Здесь требуется обновление!» — и бот автоматически попытается сделать PR, чтобы обновить модуль.
Таким образом, обучение и инструменты лучше сочетать, но лично я все равно предпочел бы как можно больше обучения. Именно люди вводят данные и допускают ошибки. Технологии все такие ошибки исправить не смогут.
— Да, к сожалению, это так. Современная разработка программного обеспечения в значительной степени полагается на открытые репозитории, такие как Python Package Index, node.js, npm и т.п. При современном уровне развития это обычно происходит как pip install или poetry add.
С вашей точки зрения, насколько высоки риски безопасности для обычного Python backend-разработчика в компании среднего размера, если он пользуется только этими инструментами? Приемлемы ли такие риски, или разработчикам надо учитывать даже тривиальные уязвимости?
Кушал Дас: Это по настоящему важный вопрос, потому что во всех репозиториях, которые мы поддерживаем, где можно скачать модули для разных языков, мы стараемся сделать этот процесс простым и доступным для разработчиков.
Для Python, например, существует Python security mailing list, который оповещает о проблемах с новейшими загруженными модулями для Python. Известны случаи так называемого тайпсквоттинга, когда название пакета похоже на очень известный пакет, и разработчики используют неправильный по неосторожности. Со стороны Python о подобных вещах заботится PyPI.
Кроме того, при установке любого пакета с помощью pip, можно действительно проверить его и убедиться, что это то что нужно, а также проверить безопасность загрузки. Например, есть PEP 458, который советует защищать загрузки с PyPI подписыванием пакетов.
Работы по развитию инструментов безопасности все еще продолжаются. Я бы рекомендовал разработчикам, начинающим работу с любым новым неподписанным модулем, выяснять, кто автор, сколько людей участвует в разработке, где хостится, в каких крупных проектах используется, что в исходном коде, есть ли жалобы на проблемы или ошибки и т. д.
Это всего 15-30 минут поиска, но они дают массу преимуществ. Если ни один человек в мире, кроме автора, не использует этот пакет, возможно, и вам не стоит его использовать. Если этот конкретный модуль применяется в других пакетах или ПО, то он, скорее всего, будет более безопасным для вашего кода.
— Да, современному разработчику необходимо задумываться, прежде чем использовать какие-либо пакеты и зависимости, с точки зрения безопасности, поддержки, популярности и многих других вещей.
Если говорить о публичных пакетах, зависимостях и репозиториях, недавно я обнаружил встроенный мониторинг безопасности в экосистеме node.js и npm, с проверкой данных при npm install something.
NPM проверяет безопасность данных и показывает результаты. Например, выводит сообщение: «Среди пакетов, которые вы только что установили, есть два с высоким риском безопасности и десять со средним риском. Вы можете выполнить следующие команды, чтобы исправить или обновить их, или отказаться от установки». Это похоже на встроенные инструменты. Что вы думаете о таких решениях, и можно ли ожидать чего-то подобного для PyPI?
Кушал Дас: Я никогда не пользовался NPM, за исключением, может быть, одного или двух раз в жизни, когда нужно было протестировать что-то. Поэтому не могу напрямую прокомментировать, насколько это хорошо, но, похоже, речь идет о том, чтобы дать разработчику более наглядный пользовательский интерфейс.
В целом, все это часть истории про взаимодействие с пользователем, когда задача разработчиков и дизайнеров — выявить, как лучше всего представить данные с учетом того, что их реально просматривает конечный разработчик, третье лицо, которое будет устанавливать все эти инструменты и модули. Потому что, когда информации слишком много, мы обычно ее прощелкиваем или пропускаем, не читая. Истина где-то посередине.
Насчет будущих планов Python- и pip-разработки — я не могу их комментировать, они мне неизвестны. Однако я думаю, или скорее надеюсь, что кто-то уже подал запрос на подобную функцию, чтобы авторы pip могли учесть его в своих планах. Сейчас команда поддержки немного больше, чем было раньше, — около семи человек с правом принимать коммиты.
— Спасибо, я надеюсь, что со временем люди будут больше думать о безопасности и встраивать больше проверок в нашу экосистему. Давайте немного поговорим о вашем предстоящем выступлении на Moscow Python Conf++. Оно построено вокруг встроенной проверки безопасности зависимостей и пакетирования.
Мы не будем здесь спойлерить, но с точки зрения эксперта по безопасности, с вашей точки зрения, что еще разработчики должны учитывать при проверке безопасности приложения?
Мы уже обсудили, как обезопасить работу с зависимостями и пакеты. Что еще нужно проверять обычному разработчику? На что следует обращать внимание?
Кушал Дас: Думаю, одним из главных пунктов должны быть обновления. Убедитесь, что хотя бы с этим у вас порядок, и все, от чего вы зависите, обновляется, включая ОС, будь то Linux, Mac, Windows или даже iOS. Как вариант, убедитесь, что вы, по крайней мере, смоделировали процессы, чтобы понять, что еще может пойти не так.
Проблема новичков (и со мной такое случалось) в большинстве случаев заключается в том, что мы слепо доверяем пользовательскому вводу. Нужно меньше полагаться на то, что ввод действительно корректен, и что это не вызовет никаких других проблем. Всё нужно перепроверять.
Кроме того, если что-то открыл — убедись, что не забыл закрыть. Представьте себе обычную дверь: когда мы входим в офис, мы проверяем, не забыли ли закрыть за собой дверь. Так же и в программировании, когда мы открываем файлы, сокеты или еще что-то, или доступ к чему-то, необходимо убедиться после завершения работы, что все чисто и закрыто.
С точки зрения программирования, я думаю, это два основных момента, о которых многие забывают.
— Да, есть много вещей, о которых люди забывают, и теперь, я думаю, последний вопрос. Исходя из вашего личного опыта, какие ошибки, связанные с безопасностью, чаще всего допускают Python backend-разработчики среднего уровня подготовки? Пользовательский ввод? Зависимости? Безопасное пакетирование приложения? Что встречается чаще?
Кушал Дас: Проблемы, которые я видел, были в основном связаны с неправильным вводом.
В 2011 году я разрабатывал инструмент для проекта Fedora и забыл вычистить свои временные файлы. В данном конкретном случае это были дампы, и их отсутствие в новой среде вызвало непредвиденные проблемы для инфраструктуры, — она упала из-за моего, мягко выражаясь, нехорошего кода.
Это продолжение все той же темы, когда необходимо убедиться, что код «вычищен», если вы что-то создаете или открываете. Так что это был серьезный урок для меня. Когда ты думаешь: «Ага, я сделал это! Все работает на моем ноутбуке!», то не факт, что это будет работать в реальном релизе или продакшне.
Мы почему-то часто думаем, что среда будет идентична нашей локальной, но она таковой никогда не бывает. Даже крупным компаниям часто трудно определить реальную среду на стороне клиента. Важно просто помнить об этом.
И еще — делайте больше комментариев к своему коду, пишите документацию. Это совет не только для новичков, но и для опытных разработчиков. Если вы не заглядывали в код в течение нескольких месяцев или нескольких лет, потом бывает очень трудно понять, почему вы что-то когда-то написали.
Кушал Дас выступит на Moscow Python Conf++. Большую оффлайн-конференцию мы были вынуждены перенести на осень, но 27 марта провели мини-онлайн-конференцию, материалами которой скоро поделимся, оставайтесь на связи.
В этом году компания спикеров Moscow Python Conf++ подобралась что надо (то есть как, подобралась — Программный комитет подобрал). Но кому интересно изучать достижения, куда интереснее, что спикер думает по поводу волнующих нас самих вопросов. Чтобы это узнать, получить инсайдерскую информацию или совет более опытного разработчика, и нужно общаться на конференциях. Но я воспользовался положением и взял небольшое интервью у нашего докладчика Кашала Даса (Kushal Das).
Отличительная черта выступлений Кушала в том, что он регулярно обнародует «секретные» способы сломать Python-код и в противовес показывает, как написать код так, чтобы АНБ не смогло его взломать. На нашей конференции Кушал расскажет, как безопасно разрабатывать и деплоить Python-код, поэтому о безопасности я его и расспрашивал.
— Кушал, расскажите, пожалуйста, немного о себе и о своей работе с Python и тому подобными вещами.
Кушал Дас: Я живу в Индии, сейчас работаю технологом по общественным интересам в американской некоммерческой организации Freedom of the Press Foundation, где помогаю поддерживать проект SecureDrop. SecureDrop — это информационная платформа с открытым исходным кодом. Основной язык здесь Python.
Помимо этого, я занимаюсь другими open source проектами, в том числе самим языком Python. Я один из Core-разработчиков CPython, а также член Совета директоров Python Software Foundation.
Я работаю с Python с 2005 года, и почти вся моя карьера связана с этим языком, а также с Linux. Это два основных направления мои интересов. Еще я вхожу в группу Core-разработчиков проекта Tor Project. Как многие уже знают, Tor помогает сохранять конфиденциальность в интернете.
— Tor — потрясающий проект, им пользуются разработчики по всему миру, чтобы получить доступ к API и документации, заблокированным, к примеру, из-за местных законов. Ваше выступление будет построено вокруг безопасности, поэтому у меня есть несколько вопросов.
Прежде всего, есть мнение, что для обычного разработчика без специальной подготовки безопасность сама по себе слишком сложна. Считается, что мы, как отрасль, должны обеспечить инструменты и экосистему, чтобы создаваемое нами ПО было безопасным по умолчанию.
Как вы думаете, что все-таки лучше: обучать людей безопасности или предоставлять им какие-то инструменты?
Кушал Дас: Думаю, и то, и другое. Действительно, безопасность — сложный вопрос. Однако, если начинающий программист проходит базовые тренинги или работает в команде, то учится избегать большинство распространенных проблем.
Чаще всего реальные ошибки в системе безопасности, такие как взлом, утечка или кража данных, возникают из-за неправильной конфигурации, отсутствия обновлений или некорректного, порой хулиганского кода.
Думаю, большинства основных ошибок можно избежать, если обучать как новичков, так и «старожилов» отрасли. Кроме того, некоторые вещи, недоступные человеческому глазу, можно выявлять с помощью новых инструментов, новой автоматизации, новых процессов.
Очень простой пример — проверки зависимостей, которые теперь есть в GitHub. Если Python-приложение содержит ошибки или использует какую-то старую версию независимого модуля, и есть определенная уязвимость, описанная в CVE, GitHub может сказать вам как разработчику: «Эй! Здесь требуется обновление!» — и бот автоматически попытается сделать PR, чтобы обновить модуль.
Таким образом, обучение и инструменты лучше сочетать, но лично я все равно предпочел бы как можно больше обучения. Именно люди вводят данные и допускают ошибки. Технологии все такие ошибки исправить не смогут.
— Да, к сожалению, это так. Современная разработка программного обеспечения в значительной степени полагается на открытые репозитории, такие как Python Package Index, node.js, npm и т.п. При современном уровне развития это обычно происходит как pip install или poetry add.
С вашей точки зрения, насколько высоки риски безопасности для обычного Python backend-разработчика в компании среднего размера, если он пользуется только этими инструментами? Приемлемы ли такие риски, или разработчикам надо учитывать даже тривиальные уязвимости?
Кушал Дас: Это по настоящему важный вопрос, потому что во всех репозиториях, которые мы поддерживаем, где можно скачать модули для разных языков, мы стараемся сделать этот процесс простым и доступным для разработчиков.
Для Python, например, существует Python security mailing list, который оповещает о проблемах с новейшими загруженными модулями для Python. Известны случаи так называемого тайпсквоттинга, когда название пакета похоже на очень известный пакет, и разработчики используют неправильный по неосторожности. Со стороны Python о подобных вещах заботится PyPI.
Кроме того, при установке любого пакета с помощью pip, можно действительно проверить его и убедиться, что это то что нужно, а также проверить безопасность загрузки. Например, есть PEP 458, который советует защищать загрузки с PyPI подписыванием пакетов.
Работы по развитию инструментов безопасности все еще продолжаются. Я бы рекомендовал разработчикам, начинающим работу с любым новым неподписанным модулем, выяснять, кто автор, сколько людей участвует в разработке, где хостится, в каких крупных проектах используется, что в исходном коде, есть ли жалобы на проблемы или ошибки и т. д.
Это всего 15-30 минут поиска, но они дают массу преимуществ. Если ни один человек в мире, кроме автора, не использует этот пакет, возможно, и вам не стоит его использовать. Если этот конкретный модуль применяется в других пакетах или ПО, то он, скорее всего, будет более безопасным для вашего кода.
— Да, современному разработчику необходимо задумываться, прежде чем использовать какие-либо пакеты и зависимости, с точки зрения безопасности, поддержки, популярности и многих других вещей.
Если говорить о публичных пакетах, зависимостях и репозиториях, недавно я обнаружил встроенный мониторинг безопасности в экосистеме node.js и npm, с проверкой данных при npm install something.
NPM проверяет безопасность данных и показывает результаты. Например, выводит сообщение: «Среди пакетов, которые вы только что установили, есть два с высоким риском безопасности и десять со средним риском. Вы можете выполнить следующие команды, чтобы исправить или обновить их, или отказаться от установки». Это похоже на встроенные инструменты. Что вы думаете о таких решениях, и можно ли ожидать чего-то подобного для PyPI?
Кушал Дас: Я никогда не пользовался NPM, за исключением, может быть, одного или двух раз в жизни, когда нужно было протестировать что-то. Поэтому не могу напрямую прокомментировать, насколько это хорошо, но, похоже, речь идет о том, чтобы дать разработчику более наглядный пользовательский интерфейс.
В целом, все это часть истории про взаимодействие с пользователем, когда задача разработчиков и дизайнеров — выявить, как лучше всего представить данные с учетом того, что их реально просматривает конечный разработчик, третье лицо, которое будет устанавливать все эти инструменты и модули. Потому что, когда информации слишком много, мы обычно ее прощелкиваем или пропускаем, не читая. Истина где-то посередине.
Насчет будущих планов Python- и pip-разработки — я не могу их комментировать, они мне неизвестны. Однако я думаю, или скорее надеюсь, что кто-то уже подал запрос на подобную функцию, чтобы авторы pip могли учесть его в своих планах. Сейчас команда поддержки немного больше, чем было раньше, — около семи человек с правом принимать коммиты.
— Спасибо, я надеюсь, что со временем люди будут больше думать о безопасности и встраивать больше проверок в нашу экосистему. Давайте немного поговорим о вашем предстоящем выступлении на Moscow Python Conf++. Оно построено вокруг встроенной проверки безопасности зависимостей и пакетирования.
Мы не будем здесь спойлерить, но с точки зрения эксперта по безопасности, с вашей точки зрения, что еще разработчики должны учитывать при проверке безопасности приложения?
Мы уже обсудили, как обезопасить работу с зависимостями и пакеты. Что еще нужно проверять обычному разработчику? На что следует обращать внимание?
Кушал Дас: Думаю, одним из главных пунктов должны быть обновления. Убедитесь, что хотя бы с этим у вас порядок, и все, от чего вы зависите, обновляется, включая ОС, будь то Linux, Mac, Windows или даже iOS. Как вариант, убедитесь, что вы, по крайней мере, смоделировали процессы, чтобы понять, что еще может пойти не так.
Проблема новичков (и со мной такое случалось) в большинстве случаев заключается в том, что мы слепо доверяем пользовательскому вводу. Нужно меньше полагаться на то, что ввод действительно корректен, и что это не вызовет никаких других проблем. Всё нужно перепроверять.
Кроме того, если что-то открыл — убедись, что не забыл закрыть. Представьте себе обычную дверь: когда мы входим в офис, мы проверяем, не забыли ли закрыть за собой дверь. Так же и в программировании, когда мы открываем файлы, сокеты или еще что-то, или доступ к чему-то, необходимо убедиться после завершения работы, что все чисто и закрыто.
С точки зрения программирования, я думаю, это два основных момента, о которых многие забывают.
— Да, есть много вещей, о которых люди забывают, и теперь, я думаю, последний вопрос. Исходя из вашего личного опыта, какие ошибки, связанные с безопасностью, чаще всего допускают Python backend-разработчики среднего уровня подготовки? Пользовательский ввод? Зависимости? Безопасное пакетирование приложения? Что встречается чаще?
Кушал Дас: Проблемы, которые я видел, были в основном связаны с неправильным вводом.
В 2011 году я разрабатывал инструмент для проекта Fedora и забыл вычистить свои временные файлы. В данном конкретном случае это были дампы, и их отсутствие в новой среде вызвало непредвиденные проблемы для инфраструктуры, — она упала из-за моего, мягко выражаясь, нехорошего кода.
Это продолжение все той же темы, когда необходимо убедиться, что код «вычищен», если вы что-то создаете или открываете. Так что это был серьезный урок для меня. Когда ты думаешь: «Ага, я сделал это! Все работает на моем ноутбуке!», то не факт, что это будет работать в реальном релизе или продакшне.
Мы почему-то часто думаем, что среда будет идентична нашей локальной, но она таковой никогда не бывает. Даже крупным компаниям часто трудно определить реальную среду на стороне клиента. Важно просто помнить об этом.
И еще — делайте больше комментариев к своему коду, пишите документацию. Это совет не только для новичков, но и для опытных разработчиков. Если вы не заглядывали в код в течение нескольких месяцев или нескольких лет, потом бывает очень трудно понять, почему вы что-то когда-то написали.
Кушал Дас выступит на Moscow Python Conf++. Большую оффлайн-конференцию мы были вынуждены перенести на осень, но 27 марта провели мини-онлайн-конференцию, материалами которой скоро поделимся, оставайтесь на связи.
