Как оставаться на вершине безопасности в 2023 году

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

В этой беседе узнайте от ведущих технических специалистов о том, как они сохранят безопасность и производительность в 2023 году.

Динамики:

• Рамадасс Прабхакар, старший вице-президент и технический директор WP Engine
• Лоуренс Эдмондсон, технический директор Barbarian
• Серджи Исаси, вице-президент по продукту, производительность приложений в Cloudflare
• Тим Нэш, консультант по безопасности WordPress на timnash.co.uk
• Джимми Сквайрс, технический директор Space150

Стенограмма:

РАМАДАС: Всем привет. Добро пожаловать в четвертое издание Decode. Было замечательно видеть рост числа посетителей с каждым годом. За последние пару лет в отрасли безопасности произошли значительные изменения. Мы видели регулярные сводки новостей о нарушениях безопасности и безопасности, поскольку эта тема часто обсуждается как с клиентами, так и с разработчиками. Итак, сегодня мы собрали замечательную группу отраслевых экспертов, увлеченных вопросами безопасности, которые готовы ответить на наши вопросы и поделиться с нами своими знаниями. Итак, давайте начнем с краткого представления наших участников дискуссии. Лоуренс, к вам.

ЛОУРЕНС ЭДМОНДСОН: Большое спасибо, что пригласили нас. С вами Лоуренс Эдмондсон, технический директор Barbarian. Barbarian — цифровое агентство полного цикла. Мы находимся в Нью-Йорке.

РАМАДАС: Спасибо, Лоуренс. Тебе слово, Серджи.

СЕРДЖИ ИСАСИ: Спасибо. Я вице-президент по продукту в Cloudflare. Cloudflare, мы создаем продукты, которые позволяют нашим клиентам и партнерам, таким как WPE, подключаться к Интернету безопаснее и быстрее, и я нахожусь в Сан-Франциско.

ВЕДУЩИЙ: Спасибо, Сергей. И Тим, к вам.

ТИМ НЭШ: Я работаю консультантом по безопасности WordPress здесь, в Великобритании. И я в основном провожу свою жизнь, пугая разработчиков.

МОДЕРАТОР: Спасибо. И Джимми.

ДЖИММИ СКВАЙРЕС: Да, спасибо. Я работаю в Space 150, цифровом агентстве с полным спектром услуг из Миннеаполиса и техническом директоре.

ВЕДУЩИЙ: Спасибо, что согласились быть сегодня на нашей панели. Итак, я хотел бы начать с разговора о чем-то уникальном, что вы делаете сегодня в области безопасности в своей организации или в своих командах. Так что, пожалуй, начнем с Серги.

SERGI ISASI: Да, я воспроизведу вступление Тима, где он пугает разработчиков. Одна из вещей, которую мы пытаемся сделать больше в Cloudflare, — это дать нашим клиентам больше информации об их трафике и снизить операционную нагрузку. Итак, исторически, если вы хотели выяснить, что может повлиять на вашу сеть, какие атаки вы могли наблюдать, вы развертывали WAF, переводили его в режим журнала, а затем аналитик по безопасности просматривал журналы и посмотреть, что он обнаружил. А ресурсов для этого сейчас намного меньше.

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

ВЕДУЩИЙ: Замечательно. Звучит на самом деле очень мощно. Я с нетерпением жду, чтобы услышать больше об этом. Итак, Тим, а ты сам?

ТИМ НЭШ: Итак, я работаю с множеством разных клиентов, как с агентствами, так и с небольшими отдельными веб-сайтами. И я провожу много обзоров кода и обзоров сайтов. И вплоть до этого года я не видел такого роста числа людей, которым действительно не все равно, что люди были бы счастливы получить отзыв и просто выполнять работу, которую вы им говорите. Поэтому, если вы дадите им кучу рекомендаций, они просто выполнят их. Но потом, если я вернусь на сайт в следующем году, я просто дам им еще кучу рекомендаций. Так что за последний год я очень сильно заметил, что люди стали достаточно заботливы, чтобы задавать вопросы. А так по мне, аудиты кода выкинули в большую, длинную вот строку 6, 4, 2 этого файла, мля, нужно делать вот так.

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

ВЕДУЩИЙ: Нет, это прекрасно. Мне очень нравится, что фокус смещается с того, чтобы дать вам рыбу, на то, чтобы научить вас ловить рыбу. Так что это действительно...

ТИМ НЭШ: Я пытался избежать этой аналогии любой ценой из-за ее клише.

МОДЕРАТОР: Спасибо.

ТИМ НЭШ: просто молодец.

ВЕДУЩИЙ: Хорошо, Джимми.

ДЖИММИ СКВАЙРЕС: Да, я думаю, что их так много, что я решил сосредоточиться на одной действительно конкретной вещи, чтобы поговорить об этом ответе. И это действительно ограничивает ваши возможности, когда вы имеете дело с токенами API и доступом. Я думаю, что взлом репозитория Heroku, GitHub в прошлом году был действительно хорошим напоминанием о том, что вы контролируете очень многое. Поэтому, когда мы работаем с нашими разработчиками, напоминаем им о важности этой политики ограниченного доступа на любой платформе или системе, с которой вы можете работать. Часто разработчику действительно нужен довольно широкий открытый доступ на ранних стадиях разработки просто для простоты. И иногда те вещи, которые нам, вероятно, стыдно признать, не затягиваются до уровня, которым они должны быть до производства. Так что начните заранее, действительно учитывая эти области безопасности.

ВЕДУЩИЙ: Спасибо, Джимми. И Лоуренс, я знаю, что вы также много работаете с разработчиками. Так что же вы все ищете в этом фронте для этого?

ЛОУРЕНС ЭДМОНДСОН: Да, конечно. Просто чтобы развить то, что сказал Джимми, конечно, мы оба работаем в рекламе. Поэтому я думаю, что мы видим много одинаковых проблем, когда вы работаете в рекламе и работаете в среде продукта. Что касается нас, мы затрагиваем множество различных технологий, множество различных технологических стеков. Мы должны быть технически агностиками. Итак, мы видим, что потребители теперь взаимодействуют разными способами через мобильные и социальные сети. Несколько лет назад настольные компьютеры были основным средством доступа к сайтам и контенту. Теперь это полностью перевернуто. Он перешел от настольных компьютеров к мобильным, а теперь и к социальным сетям.

Таким образом, ваши уровни API и ваши уровни приложений должны быть заблокированы таким образом, чтобы с ними было связано немного здоровой паранойи. Итак, мы видим, что спектр атак растет, поэтому мы постоянно ищем новые способы заставить DevOps думать как программисты, чтобы они понимали возможные способы взлома. Вот чем мы занимаемся сегодня.

ВЕДУЩИЙ: Спасибо за это. И вы упомянули, как увеличивается вектор атаки. И это то, что мы здесь, в WP Engine, рассматривали в большей степени с точки зрения того, как вы принимаете механизм глубокоэшелонированной защиты. Так что не доверяйте ни одному уровню безопасности. Итак, как вы включаете это в свой код и в то, как вы пишете программное обеспечение. Так что спасибо за это. Как вы все говорили об изменяющейся тенденции, которая происходит там, нарушениях, которые произошли в прошлом году. Итак, когда вы смотрите на 2023 год, на какие основные темы или угрозы вы все обращаете внимание? И, может быть, Серджи, ты нас начнешь. Ага.

СЕРДЖИ ИСАСИ: Конечно. И это прозвучит глупо, потому что сейчас 2023 год, и я собираюсь сказать слово DDOS, но это все еще актуально. И это действительно интересный сдвиг за последние девять-двенадцать месяцев в мире DDOS. В наши дни Volumetric не очень похож на вектор DDOS. Там намного меньше отражения. И с точки зрения злоумышленника, запустить DDOS проще, потому что у вас есть много готовых инструментов, верно? Мы почти вернулись к временам TD со сценариями, но у вас также гораздо меньше скомпрометированных систем для атаки. Так что, если вы пытаетесь сделать отражение, не так много инфраструктуры, которой управляет кто-то, кто, возможно, не пропатчил свою систему, поэтому вы можете взять один пакет и превратить его в 10. На самом деле это уже не так важно.

Таким образом, они переходят на уровень 7. И уровень 7 является более дорогим для запуска, так как вам нужно много ресурсов ЦП, чтобы сделать это, но также намного дороже смягчить последствия. Поэтому, если у вас есть какая-то система защиты от DDOS, вам действительно нужно принять соединение, проверить его, а затем начать сбрасывать его вместо чего-то, что вы могли бы сбросить на более низком уровне. Что мы обнаружили и предотвратили крупнейшую зарегистрированную DDOS 7-го уровня, о которой сообщалось только в прошлом месяце. Основная тема этих атак — более мощные устройства.

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

Еще одна вещь, о которой мы немного говорим в эти дни, но она немного тише, это то, что мы перешли от скомпрометированных аппаратных устройств к скомпрометированным учетным записям в облачных сервисах. Облачные сервисы имеют практически неограниченный ЦП. Поэтому, если я смогу получить доступ к нескольким учетным записям отдельных лиц или компаний и раскрутить все, что захочу, в этой облачной системе, я смогу запустить чрезвычайно крупную атаку. И это то, что мы видим в рекордных атаках. Так что да, 2023 год, все еще DDOS, все еще что-то, но теперь на уровне 7 по сравнению с нижними уровнями.

МОДЕРАТОР: Спасибо. Это пугает, но в то же время я думаю, что это указывает на то, как мы продолжаем улучшать наши протоколы безопасности, и область нашего внимания продолжает расширяться. Я знаю, Лоуренс, в прошлом мы с вами болтали об ИИ как о буме и угрозе. Я хотел бы услышать некоторые ваши мысли о генеративном ИИ и о том, как, по вашему мнению, это на самом деле повлияет на область безопасности в 2023 году.

ЛОУРЕНС ЭДМОНДСОН: Так что я очень взволнован, очень оптимистичен в отношении ИИ. Мы в Варваре, но в то же время очень страшно. Возможность злонамеренного использования чего-то вроде chatGPT. Так, например, вы можете сделать так, чтобы Chat GPT комментировал ваш код. И на самом деле он делает довольно приличную работу, в зависимости от того, на каком языке и насколько запутан ваш код, он делает довольно хорошую работу. Итак, я думаю, что следующее, что мы увидим, это Chat GPT, и это может быть уже в процессе, потому что каждый день Chat GPT делает это. Как и сегодня, я только что увидел, что он может отвечать в Slack и находить ответы в Slack.

Так что я думаю, что следующее, с точки зрения безопасности, в Chat GPT — это то, что Chat GPT находит эксплойты и фактически пишет код — вредоносный код, чтобы действительно использовать обнаруженные уязвимости. Итак, мы видим это, особенно потенциал для этого в памяти. Таким образом, атаки на память не всегда оставляют следы. Итак, традиционные вирусы и антивирусные сканеры работают над поиском сигнатур атаки. При атаках на память вы атакуете приложение. Вы делаете что-то вроде переполнения буфера. Вы хотите скомпрометировать приложение во время выполнения. Я думаю, что Chat GPT действительно готов это сделать. И я думаю, что это всего лишь вопрос времени, когда мы увидим первый крупномасштабный эксплойт ChatGPT.

ТИМ НЭШ: Как бы вы себе это представляли? Потому что очевидно, что ChatGPT по своей сути представляет собой просто набор запросов API к серверу. И вы отправляете запрос, в котором говорится, эй, сгенерируйте мне какой-нибудь вредоносный код. Это возвращает его обратно. Я имею в виду, что многие люди уже генерируют вредоносный код. Как бы вы тогда сделали это хуже, чем уже существующий вредоносный код?

ЛОУРЕНС ЭДМОНДСОН: Вот именно. Уже есть большой репозиторий, из которого можно поучиться. Итак, ChatGPT, то, что он делает, он на самом деле смотрит — вам нужно обучить модель. Поэтому со временем инженеры обучают модель распознавать, когда кто-то говорит это, это на самом деле то, что они имеют в виду. Так что понимайте контекст. Так что это именно так, но по-другому. Это обучение модели написанию кода и тому, что он на самом деле означает. А некоторые языки очень легкие. Итак, PHP, довольно легко писать код на PHP. Эти интерпретируемые языки намного проще. Это намного сложнее, но вместо того, чтобы делать что-то вроде Java, которую нужно компилировать, понимаете, о чем я?

Поэтому я думаю, что простым способом сделать это было бы создать модель на основе chatGPT 3, которую на самом деле вы обучаете на самом деле — вы проходите через синтаксис, вы проходите через все основные вещи информатики, а затем вы принимаете это. шаг вперед и вперед, хорошо, эти пакеты NPM имеют эти эксплойты. Ищите это и ищите способ на самом деле… у них есть эти уязвимости, извините, и ищите способ использовать эти уязвимости. Я гарантирую это, мы не так уж далеки от того, чтобы увидеть что-то подобное.

ВЕДУЩИЙ: Спасибо, Лоуренс. Я думаю, что это очень зарождающаяся область. Что интересно в этом пространстве, так это то, что с ИИ, в целом, у него есть баланс между тем, для чего вы можете его использовать, будь то фактическое использование этих сигнатур для предотвращения и извлечения уроков из него, чтобы увидеть, как вы можете помешать нам написание плохого кода или уязвимого кода. И в то же время, точно так же, как мы видели, что люди говорят о том, эй, я написал свой первый плагин за пять минут с помощью Chat GPT, я думаю — да, это больше о том, что это позволяет людям немного создавать вредоносные программы. Быстрее? Но я думаю, что у него есть оба аспекта.

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

ТИМ НЭШ: Ну, я имею в виду, что во многих отношениях Chat GPT является хорошим примером этого. Если бы я думал о векторе атаки, то, честно говоря, я не думал о массовом сканировании, скармливании ему множества вещей в качестве плохого актера. Я думал об этом как о среднем разработчике кода, который пытался сэкономить время и загружал материал в Chat GPT и выбрасывал его, и не обязательно полностью понимал весь код, который пишется, создается, не написал никаких тестов для смирись с этим. Это просто быстрая вещь, это просто быстрый сценарий, все в порядке. Он попадает в производство, это не нормально, и это все горит.

Теперь это то же самое, что каждый разработчик делает каждый божий день, независимо от того. Chat GPT не меняет этого, но позволяет сделать это немного проще. Это дает – барьеров меньше.

СЕРДЖИ ИСАСИ: Да, так что это не совсем то же самое, что копирование и вставка из Stack Overflow, о котором, я думаю, ты имеешь в виду, Тим, и это в основном все, что я делаю для кода. Но я думаю, что это повышение эффективности точно, как положительное, так и отрицательное. Но я действительно думаю, что это позволяет вносить более тонкие изменения и быстрее использовать то, что в большей степени основано на сигнатурах, движок не может догнать. Итак, когда вы занимаетесь обнаружением, вам действительно нужна система, которая говорит, похоже ли это на то, что я видел в прошлом, в отличие от прямого соответствия тому, что я видел в прошлом. И это на самом деле на стороне обнаружения, и, вероятно, лучше всего обслуживается ML или AI, или как вы хотите это называть.

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

ВЕДУЩИЙ: Замечательно. Спасибо. Спасибо, Серджи и Тим за добавленный контекст. Так что среди наших посетителей есть много разработчиков и агентств, которые присутствуют здесь сегодня. И многие люди думают о внедрении лучших практик, особенно когда сценарии меняются с точки зрения векторов угроз. Итак, какие передовые методы вы бы порекомендовали при создании сайта, приложения или платформы или просто при начале работы над новым проектом. Итак, на что люди должны обращать внимание?

СЕРДЖИ ИСАСИ: Итак, я могу начать. Это было бы больше на эксплуатационной стороне, чем на стороне разработки. Я думаю, одна из вещей, которую мы здесь проповедуем, это, во-первых, предположить, что произойдет что-то плохое. Итак, грядет прорыв, вы не можете просто так удивиться этому. Вероятно, это произойдет в какой-то момент. И наш ключ — так что, во-первых, создайте для него книгу выполнения. Поэтому, когда это произойдет, знайте, с кем связаться и каков будет ваш ответ, как при обнаружении, так и при реагировании, а также при общении с вашими клиентами, если это затронет их. И с этой точки зрения, то, что мы, я думаю, очень хорошо делаем в Cloudflare, и это было частью нашего бренда, и я думаю, что это очень хорошо нам послужило, — это быть искренними, открытыми и настолько коммуникативными, насколько это возможно. это случилось.

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

ВЕДУЩИЙ: Ага.

ДЖИММИ СКВАЙРЕС: Я думаю, что у нас есть еще кое-что — теперь, когда все, очевидно, удаленно, особенно в командах разработчиков, на самом деле тратят время в начале проекта, чтобы сделать некоторые доски и архитектурное планирование. Так легко сразу погрузиться в требования и сфоткать истории разработки, но провести время со своими коллегами, чтобы бросить вызов тому, как это можно использовать? Пробегитесь по сценариям. Мы много планируем сценариев, что приводит к большому количеству хороших разговоров о том, как мы хотим укрепить различные части приложения.

ЛОУРЕНС ЭДМОНДСОН: И именно об этом, я не знаю, знает ли кто-нибудь, но MPM на самом деле является крупнейшим репозиторием совместно используемых библиотек — это самый большой репозиторий библиотек приложений, но это означает, что он также представляет наибольший риск. Итак, одна вещь, о которой мы очень хорошо осведомлены, когда беремся за новый проект, если мы используем NPM, — это убедиться, что мы смотрим на уязвимости, что мы блокируем версии, которые мы отправляем в производство, что прежде чем мы Делаем обновление, мы удостоверяемся, что оно совместимо, но при этом очень безопасно. Открытых угроз нет, потому что мы видели множество уязвимостей, проникающих через NPM. Так что это только одна вещь, на которую нужно обратить внимание.

ТИМ НЭШ: Я думаю, что мы все зацикливаем.

ДЖИММИ СКВАЙРЕС: Давай, Тим.

ТИМ НЭШ: Я думаю, что мы сводим все это к идее, что на самом деле доверие полностью разрушается в течение многих лет циклов разработки. Люди только сейчас начинают это осознавать. И если вы разработчик PHP, работающий, например, в WordPress, вы сидите и вызываете действия и фильтры, но вы не должны доверять этим действиям и фильтрам. Любые поступающие данные вы должны проверять, вы должны их проверять. Его следует продезинфицировать. Но когда он выходит из базы данных, вы все равно не должны ему доверять.

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

ВЕДУЩИЙ: Ага.

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

ЛОУРЕНС ЭДМОНДСОН: Да.

ВЕДУЩИЙ: Ага. Вы абсолютно правы. Речь идет о том, чтобы не доверять никакому другому фрагменту кода, который проходит. Что касается того, о чем говорили Джимми и Серджи, то это наличие плана и с точки зрения архитектуры или с точки зрения эксплуатации, но объединение всего этого в вашу общую практику, будь то механизмы безопасного кодирования или наличие сценария инцидентов. Итак, Тим, мне очень интересно услышать от вас больше – вы много тренируетесь, вы много преподаете по всему миру. Какие типичные ошибки вы видите, когда люди начинают работать над проектами, или ошибки, которые вы, возможно, совершали? Я совершил их много.

ТИМ НЭШ: Я собирался сказать, что почти уверен, что виновен во всех ошибках, о которых собираюсь рассказать. А самое большое и самое простое — быть хорошим человеком. Большинство разработчиков исходят из благих намерений. Большинство людей предполагают, что вы собираетесь использовать их приложение так, как написали его приложение. Сейчас довольно часто мы не пишем документацию, поэтому пользователь вообще не представляет, как использовать приложение, но это отдельная тема. Плохой актер придет, возьмет любую ошибку и уйдет, это не ошибка, для плохого актера это фича. Это возможность. Он делает то, чего разработчик не ожидает, поэтому есть потенциальный путь к этому.

И в целом, то, что вы видите снова и снова, когда говорите: «О, смотрите, у вас есть набор модульных тестов». О, круто. Но вы проверили только положительные вещи, результат, который вы хотели. Вы не проверяли, что произойдет, если мы выйдем за эти границы. Вы только что проверили, чтобы убедиться, что все работает в соответствии с тем, что хочет ваш босс. Так что на самом деле у вас есть приемочные тесты, сомнительные приемочные тесты. А потом возвращается ко всем основам. Как разработчик, он отказался от этого, не доверяйте вещам. И если вы, в частности, разработчик WordPress, у WordPress действительно есть несколько действительно хороших вспомогательных функций для выполнения всех видов стандартных действий по обеспечению безопасности, которые мы просим людей делать.

И речь идет об обучении и обучении их использованию. Когда я проверяю код, снова и снова я вижу одни и те же проблемы. И если я увижу это один раз в фрагменте кода, я увижу его 1000 раз в одном и том же наборе кода. И это будет что-то вроде: да, мы просто позволили любому старому материалу появиться на странице. Мы не удосужились проверить, есть там что-нибудь или нет. Да, мы помещаем вещи в базу данных. О, смотрите, это может выглядеть как SQL-запрос, а может и нет.

Все подобные вещи легко исправить, и мы уже предоставили инструменты для исправления. И причина, по которой мы их не исправляем, часто даже не в том, что люди не знают, что они не должны допускать таких вещей, просто мы ленимся, мы делаем все быстро, мы берем код из Stack Overflow, мы заставляем Chat GPT делать что-то для нас, мы ничего не проверяем. И много проблем с безопасностью происходит из-за этого состояния, я должен спешить. Я должен спешить. Я должен спешить, я должен сделать это. Я перехожу к следующему, я перехожу к следующему.

Так странно, что многие разработчики просто давали им время и место и говорили, что это нормально — тратить время на то, чтобы проверить, что вы сделали, чтобы, когда дело дойдет до дела — и в тех случаях, когда я вступаю в игру, Я возвращаюсь и говорю, ну, все эти вещи и разработчики выглядят застенчивыми. Они собираются, да, мы все это знаем. У нас просто не было времени.

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

ВЕДУЩИЙ: Ага. И я думаю, что это действительно мощно, потратьте время. Чаще всего разработчики знают, что нужно исправить. Так что дайте им время. Так что мне очень нравится это сообщение. Джимми, я знаю, что ты внедрил это в свой рабочий процесс в своем агентстве. Вы хотите немного больше рассказать о методах безопасного рабочего процесса, которые вы внедрили?

ДЖИММИ СКВАЙРЕС: Да, абсолютно. И на самом деле, все начинается с того, что у Серджи есть план, на самом деле есть рекомендации и стандарты, которым должна следовать ваша команда разработчиков. Я знаю, что это звучит, вероятно, очень банально, но я видел много организаций и слышал от многих инженеров, которых мы нанимали на протяжении многих лет, что их не существовало. На месте работы, откуда они приехали, не было организации.

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

Так что даже в наших рекомендациях проделайте дыры в том, что мы можем добавить, где мы можем стать лучше, постоянно совершенствуя это. Но тратить время на это, некоторые из основных вещей, таких как OWASP, это действительно старая практика, но проходить через это с вашим приложением, учитывая эти вещи. Это вроде того, что сказал Тим, это действительно занимает время, и это нормально, чтобы тратить время на это. Я хотел добавить еще один пункт к разговору об ИИ. Разговор с несколькими нашими инженерами на прошлой неделе действительно стал событием. Мы используем Chat GPT для модульного тестирования. Взяв функцию и исследуя ее интересными способами, как вы можете использовать что-то вроде Chat GPT для написания модульного теста, где вы не станете лучшим автором этого модульного теста, по мнению Тима. Именно здесь, я думаю, мы можем гораздо больше использовать ИИ в профилактических целях.

ЛОУРЕНС ЭДМОНДСОН: Да. То, что мы делаем со своей стороны, я думаю, что контрольные списки и сборник сценариев — это здорово. Мы используем автоматизированные инструменты, такие как SonarQube, и действительно применяем линтинг и тому подобное, просто для того, чтобы повысить качество кода с помощью линтинга, но также используем SonarQube, чтобы просто убедиться, что код более безопасен, что мы ищем. для уязвимостей и тому подобного. Я думаю, что в некоторых языках легче найти эксплойты, чем в других, как я уже упоминал ранее, просто из-за природы языка. А также только определенные фреймворки, где качество кодеров, которые вносят свой вклад в эту кодовую базу, типичное — мы обычно видим это с открытым исходным кодом, где это похоже на — происходит много копирования и вставки Stack Overflow, по сравнению с людьми, которые действительно изучали CS и действительно знают, что делают. Так что это только одна вещь, которую я видел.

ТИМ НЭШ: Я чувствую, что мы должны отметить, конечно же, для себя, что я использую Stack OverFlow почти каждый день. И поэтому мы все виноваты в этом. Хорошо ругать это, но я не думаю… я имею в виду, я помню, когда впервые начал программировать. Я получил журнал, печатал код из журнала и нажимал Enter. Я не могу представить, чтобы сеть действительно работала сегодня, если бы мы все еще занимались этим и не имели переполнения стека или чего-то подобного.

Sergi: Нет, это ускоритель. И, надеюсь, ИИ станет следующим этапом этого. Но да, это забавный мем.

МОДЕРАТОР: Спасибо. Так что немного смещаюсь. В отрасли наблюдается большой импульс, связанный с реализациями Headless и Headless. И мы также видели, как на некоторых других наших каналах сегодня или на других сессиях говорят о Безголовых. Поэтому, когда мы начали работать с Atlas в WP Engine, мы встретились со многими разработчиками, и безопасность всегда была ключевым мотиватором. Итак, как вы относитесь к безопасности с помощью Headless? И я знаю, Джимми, это та область, в которой ты сделал несколько проектов. Мы хотели бы узнать ваше мнение об этом.

ДЖИММИ СКВАЙРЕС: Да, мы много работаем над Headless. Я думаю, что почти все наши проекты на данный момент, вероятно, используют подход безголовой архитектуры. Я думаю, что я хочу сделать несколько замечаний по этому поводу, поскольку это относится к безопасности. Итак, я думаю, во-первых, когда вы выбираете архитектуру без головы, вы, как правило, в начале ставите себя в лагерь с открытым исходным кодом. И, конечно же, идет много споров о том, что безопаснее, с открытым или закрытым исходным кодом. Я склоняюсь к тому, что проекты OSS более безопасны по своей природе. Итак, вы выбираете такие фреймворки, как Next, WordPress, где у вас огромное сообщество. И это, как правило, обеспечивает большую безопасность за счет простого разоблачения.

Так что я думаю, что это один. Я думаю, что второе — это что-то вроде Static Generation. Так много веб-сайтов и продуктов, которые созданы, вам не нужна динамическая природа большой системы управления контентом, монолитной системы в традиционном смысле. Вы можете использовать что-то вроде Cloudflare и действительно статически генерировать большие части этого приложения, тем самым уменьшая свое влияние на векторы и воздействие. Так что мы большие поклонники этого. И тогда, конечно, вы также получите все преимущества производительности. Так что это всего лишь пара моментов, которые я хотел сделать по архитектуре без головы. Но есть еще много причин с точки зрения безопасности, которые нам нравятся. Но я думаю, что это, пожалуй, две самые выдающиеся области.

ТИМ НЭШ: Я хотел бы просто вернуться назад и напомнить людям, что там, сзади, все еще есть система управления контентом. И я слишком часто слышу, что Безголовый абсолютно безопасен. Это похоже на то, что да, но этот открытый экземпляр WordPress, который все еще находится там, только потому, что вы не вызываете его напрямую с веб-сайта, да, он все еще там на admin.yoursite.com. А у вас нет... есть определенное убеждение, что, о да, теперь мы в безопасности, поэтому нам не нужно беспокоиться о поддержании актуальности, потому что это не веб-сайт. Это как нет, нет, вам все еще нужно все, что вы делали раньше, и теперь у нас есть и другая сторона.

И я имею в виду, что Headless — отличный термин для чего-то, что существует уже давно и набирает обороты, но мы делали это еще до того, как в WordPress появился REST API. Мы выталкивали контент из WordPress в такие вещи, как Jekyll, чтобы получить из него хотя бы статичный сайт. И первоначальная причина для этого заключалась в том, чтобы изменить систему WordPress или вашу систему управления контентом внутри вашей сети. Так что вы могли бы заблокировать его и уберечь от большой, страшной паутины.

Теперь у нас есть много хостинговых компаний, которые предоставляют решения без головы. And that infrastructure is now out in the cloud again. So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. Спасибо. And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.