Como ficar no topo da segurança em 2023

Segurança e desempenho são a base de cada projeto, site, aplicativo e componente que você desenvolve. Mas, neste cenário em constante mudança, pode ser um desafio manter-se atualizado sobre as melhores práticas fundamentais e, ao mesmo tempo, inovar.

Nesta conversa, ouça os principais tecnólogos sobre como eles estão se mantendo no topo da segurança e do desempenho em 2023.

Caixas de som:

• Ramadass Prabhakar, vice-presidente sênior e diretor de tecnologia da WP Engine
• Lawrence Edmondson, CTO da Barbarian
• Sergi Isasi, vice-presidente de produto, desempenho de aplicativos da Cloudflare
• Tim Nash, consultor de segurança do WordPress em timnash.co.uk
• Jimmy Squires, CTO da space150

Transcrição:

RAMADASS: Olá a todos. Bem-vindo à quarta edição do Decode. Foi maravilhoso ver o crescimento de participantes a cada ano. Nos últimos dois anos, houve uma mudança significativa no cenário de segurança em todo o setor. Vimos boletins de notícias regulares sobre violações de segurança e segurança como um tópico que aparece com frequência nas discussões com clientes e desenvolvedores. Portanto, hoje reunimos um grupo fabuloso de especialistas do setor apaixonados por segurança e que estão aqui para responder às nossas perguntas e compartilhar seus aprendizados conosco. Então, vamos começar com uma breve introdução aos nossos palestrantes. Lawrence, para você.

LAWRENCE EDMONDSON: Muito obrigado por nos receber. Lawrence Edmondson aqui, CTO da Barbarian. A Barbarian é uma agência digital de serviço completo. Estamos localizados em Nova York.

RAMADASS: Obrigado, Lawrence. Com você, Sergi.

SERGI ISASI: Obrigado. Sou vice-presidente de produtos da Cloudflare. Cloudflare, construímos produtos que tornam qualquer coisa para nossos clientes e parceiros, como WPE, conectar-se à Internet de forma mais segura e rápida e estou em San Francisco.

MODERADOR: Obrigado, Sergi. E Tim, para você.

TIM NASH: Sou consultor de segurança do WordPress aqui no Reino Unido. E basicamente passo minha vida assustando desenvolvedores.

MODERADOR: Obrigado. E Jimmy.

JIMMY SQUIRES: Sim, obrigado. Estou com a Space 150, também uma agência digital de serviço completo em Minneapolis e CTO lá.

MODERADOR: Obrigado por concordar em fazer parte do nosso painel hoje. Então, gostaria de começar falando sobre algo único que você está fazendo em segurança hoje em sua organização ou em suas equipes. Então talvez vamos começar com Sergi.

SERGI ISASI: Sim, vou reproduzir a introdução de Tim, onde ele assusta os desenvolvedores. Uma das coisas que estamos tentando fazer mais na Cloudflare é dar aos nossos clientes mais informações sobre seu tráfego e reduzir a carga operacional. Então, historicamente, se você quiser descobrir o que pode estar afetando sua rede, o que pode ser um ataque que você pode estar vendo, você deve implantar um WAF, colocá-lo no modo de log e, em seguida, pedir a um analista de segurança para examinar os logs e veja o que detectou. E há muito menos recursos para fazer isso hoje em dia.

Portanto, nosso foco para este ano é fornecer informações aos nossos clientes sobre os ataques que vemos neles, mesmo que não estejam usando o produto que impediria esse ataque hoje. Assim, eles podem saber se seu aplicativo está sob ataque ou se está em boas condições. E esse é o nosso foco para o restante do ano, apresentando todos os nossos produtos de segurança e informando aos nossos clientes o que pode estar acontecendo ou o que realmente está acontecendo em sua rede e se eles desejam ou não bloqueá-la.

MODERADOR: Maravilhoso. Isso soa realmente muito poderoso. Estou ansioso para ouvir mais sobre isso. Então, Tim, e você?

TIM NASH: Trabalho com muitos clientes diferentes, ambas agências, mas também sites individuais menores. E faço muitas revisões de código e revisões de site. E até este ano, eu não vi o crescimento de pessoas realmente se preocupando tanto que as pessoas ficam muito felizes em receber uma revisão e apenas fazer o trabalho que você diz para fazer. Então, se você der a eles um monte de recomendações, eles simplesmente seguirão. Mas então, se eu voltar ao site no próximo ano, estarei apenas dando a eles mais um monte de recomendações. Portanto, tenho visto uma mudança neste último ano em que as pessoas realmente se preocupam o suficiente para fazer perguntas. E então, para mim, as auditorias de código foram jogadas fora na grande e longa linha 6, 4, 2 deste arquivo, blá, precisa ser feito assim.

Eu me livrei de tudo isso e realmente comecei a focar na educação e percebi que, para ser honesto, o que a maioria das pessoas quer não é que digam, você deve consertar essa linha, mas para ouvir, veja como consertar cada linha que está ali. Então, para mim, a grande mudança e a grande mudança de foco foram para a educação. E isso é algo que abrange toda a indústria. Acho que há mais e mais pessoas falando sobre segurança este ano do que no ano passado e mais e mais nos anos anteriores.

MODERADOR: Não, isso é maravilhoso. Eu realmente gosto desse foco de mudar de dar a você o peixe para ensiná-lo a pegá-lo. Então isso é realmente–

TIM NASH: Eu estava tentando evitar essa analogia a todo custo por ser clichê.

MODERADOR: Obrigado.

TIM NASH: muito bem.

MODERADOR: Tudo bem, Jimmy.

JIMMY SQUIRES: Sim, acho que há tanto, decidi me concentrar em uma coisa realmente específica para falar sobre esta resposta. E isso está realmente restringindo seu escopo quando você está lidando com acesso e tokens de API. Acho que a violação do repositório Heroku, GitHub no ano passado foi um lembrete muito bom de que você está no controle de muitas coisas. Então, quando estamos trabalhando com nossos desenvolvedores, lembrando-os da importância dessa política de acesso com escopo em qualquer plataforma ou sistema com o qual você esteja trabalhando. Muitas vezes, um desenvolvedor realmente deseja um acesso aberto bastante amplo no início do desenvolvimento, apenas para facilitar. E às vezes essas coisas que provavelmente temos – vergonha de admitir – elas não chegam ao nível que deveriam estar antes da produção. Portanto, comece cedo, realmente considerando esses escopos de segurança.

MODERADOR: Obrigado, Jimmy. E Lawrence, sei que você também trabalha muito com desenvolvedores. Então, o que vocês estão procurando nessa frente para isso?

LAWRENCE EDMONDSON: Sim, claro. Só para reforçar o que Jimmy disse, com certeza, nós dois trabalhamos com publicidade. Então, acho que vemos muitos dos mesmos desafios quando você trabalha com publicidade em vez de trabalhar em um ambiente de produto. Para nós, tocamos em muitas tecnologias diferentes, em muitas pilhas de tecnologias diferentes. Temos que ser tecnicamente agnósticos. Então, o que estamos vendo é que os consumidores estão se envolvendo de várias maneiras agora por meio de dispositivos móveis e sociais. Há alguns anos, o desktop era o principal meio de acesso a sites e conteúdo. Agora está completamente invertido. Passou do desktop para o celular e agora para o social.

Portanto, suas camadas de API e suas camadas de aplicativo devem ser bloqueadas de maneiras que tenham um pouco de paranóia saudável associada a elas. Então, o que estamos vendo é que o espectro de ataque está crescendo, então estamos constantemente buscando novas maneiras de fazer o DevOps pensar como programadores, para que eles entendam as possíveis maneiras de as coisas serem violadas. Então é isso que estamos fazendo hoje.

MODERADOR: Obrigado por isso. E você mencionou como o vetor de ataque está aumentando. E isso é algo que temos aqui, no WP Engine, estamos analisando mais sobre como você adota um mecanismo de defesa em profundidade. Portanto, não confie em nenhuma camada para ser segura. E então, como você incorpora isso na maneira como você codifica e na maneira como escreve software. Então, obrigado por isso. Como todos vocês falaram sobre a tendência de mudança que está acontecendo lá, violações que aconteceram no ano passado. Então, ao olhar para 2023, quais são alguns dos principais temas ou ameaças aos quais todos vocês estão prestando atenção? E talvez, Sergi, você possa começar. Sim.

SERGI ISASI: Claro. E isso vai soar bobo porque é 2023 e vou dizer a palavra DDOS, mas ainda é uma coisa. E realmente tem sido uma mudança interessante nos últimos nove, 12 meses no mundo DDOS. Volumétrico não é realmente um vetor DDOS atualmente. Há muito menos reflexão. E do ponto de vista de um agente de ameaça, é mais fácil lançar um DDOS porque você tem muitas ferramentas prontas para uso, certo? Estamos quase de volta aos dias de script TD, mas você também tem muito menos sistemas comprometidos para atacar. Portanto, se você está tentando fazer reflexão, não há muita infraestrutura gerenciada por alguém que pode não ter corrigido seu sistema, então você pode pegar um pacote e transformá-lo em 10. Isso não é mais uma grande coisa.

Então, eles estão migrando para a camada 7. E a camada 7 é mais cara para lançar porque você precisa de muita CPU para fazer isso, mas também é muito mais cara para mitigar. Portanto, se você tiver algum tipo de sistema de proteção DDOS, precisará aceitar a conexão, examiná-la e começar a descartá-la em vez de algo que poderia descartá-la em uma camada inferior. O que descobrimos e mitigamos o maior DDOS de camada 7 relatado no mês passado. O grande tema desses ataques são os dispositivos mais poderosos.

Portanto, se você pensar em todas as coisas que conectamos em casa hoje em dia, o processador desse dispositivo é significativamente melhor do que há três ou quatro anos. Então sua câmera faz muito mais. Portanto, ele possui uma CPU mais robusta, até mesmo seus roteadores são na verdade uma máquina bastante forte. E qualquer comprometimento desses dispositivos pode permitir um grande, grande ataque, especialmente porque, se você comprometer um, agora comprometerá basicamente todos os que estiverem conectados.

A outra coisa sobre a qual falamos um pouco hoje em dia, mas é um pouco mais discreto, é que passamos de dispositivos de hardware comprometidos para contas comprometidas em serviços de nuvem. Os serviços em nuvem têm CPU efetivamente ilimitada. Portanto, se eu conseguir acesso a várias contas de indivíduos ou empresas e ativar o que quiser nesse sistema de nuvem, posso lançar um ataque extremamente grande. E é isso que estamos vendo nos ataques recordes. Então, sim, 2023, ainda DDOS, ainda uma coisa, mas agora na camada 7 versus as camadas inferiores.

MODERADOR: Obrigado. Isso é assustador, mas também, ao mesmo tempo, acho que indica como continuamos aprimorando nossos protocolos de segurança e a área de foco continua a crescer. Eu sei, Lawrence, você e eu conversamos no passado sobre IA como um boom e uma ameaça. Eu adoraria ouvir alguns de seus pensamentos sobre IA generativa e como você vê isso realmente impactando a área de superfície de segurança em 2023.

LAWRENCE EDMONDSON: Estou muito empolgado, muito otimista com a IA. Estamos no Barbarian, mas ao mesmo tempo é muito assustador. O potencial de algo como um chatGPT sendo usado de maneira maliciosa. Por exemplo, você pode fazer com que o Chat GPT comente seu código. E, na verdade, faz um trabalho bastante decente, dependendo da linguagem e da confusão do seu código, faz um bom trabalho. Acho que a próxima coisa que veremos é o Chat GPT - e isso pode já estar em andamento porque todos os dias, o Chat GPT faz isso. Como hoje, acabei de ver que é possível responder no Slack e encontrar respostas no Slack.

Então, acho que a próxima coisa, em termos de segurança, no Chat GPT é fazer com que o Chat GPT encontre explorações e realmente escreva o código para – código malicioso para realmente explorar os pontos fracos que encontrar. Estamos vendo isso, especialmente o potencial para isso na memória. Portanto, os ataques de memória não deixam uma assinatura o tempo todo. Portanto, os vírus e verificadores de vírus tradicionais trabalham na busca de assinaturas de um ataque. Nos ataques à memória, você está atacando o aplicativo. Você está fazendo algo como um estouro de buffer. Você está tentando comprometer o aplicativo em tempo de execução. Acho que o Chat GPT está realmente pronto para fazer isso. E acho que é apenas uma questão de tempo até vermos a primeira exploração do ChatGPT em grande escala acontecer.

TIM NASH: Como você imaginaria isso realmente acontecendo? Porque, obviamente, o ChatGPT, em sua essência, é apenas um conjunto de solicitações de APIs para um servidor. E você está enviando uma solicitação que diz, ei, me gere algum código malicioso. É devolvê-lo de volta. Quero dizer, já existem muitas pessoas gerando códigos maliciosos. Como você faria isso ser pior do que o código malicioso que já existe?

LAWRENCE EDMONDSON: Então é exatamente isso. Já existe um grande repositório para aprender. Então, ChatGPT, o que ele faz, ele realmente analisa – você tem que treinar o modelo. Então, com o tempo, os engenheiros treinam o modelo para reconhecer quando alguém diz isso, na verdade é isso que eles querem dizer. Portanto, entenda o contexto. Então é exatamente isso, mas de uma forma diferente. É treinar o modelo para realmente escrever código e o que isso realmente significa. E algumas línguas são muito fáceis. Então PHP, muito fácil de escrever código em PHP. Essas linguagens interpretadas são muito mais fáceis. É muito mais confuso, mas em vez de fazer algo como um Java, que precisa ser compilado, entende o que quero dizer?

Então, acho que uma maneira fácil de fazer isso seria criar um modelo baseado no chatGPT 3 que, na verdade, você o treina para realmente - você passa pelo material da sintaxe, passa por todas as coisas básicas da ciência da computação e depois pega um passo à frente e pronto, OK, esses pacotes NPM têm essas explorações. Procure por isso e descubra uma maneira de realmente… eles têm essas vulnerabilidades, desculpe, e procure uma maneira de explorar essas vulnerabilidades. Eu garanto, não estamos muito longe de ver algo assim acontecer.

MODERADOR: Obrigado, Lawrence. Eu acho que é uma área muito nascente. O que é interessante neste espaço é que com a IA, em geral, ela tem tanto o equilíbrio do que você pode aproveitá-la, seja para realmente usar essas assinaturas para prevenir e aprender com isso para ver como você pode nos impedir de escrever código ruim ou código vulnerável. E, ao mesmo tempo, assim como vimos, as pessoas falam sobre, ei, eu escrevi meu primeiro plug-in em cinco minutos com o Chat GPT, eu acho– sim, é mais sobre isso começar a permitir que as pessoas criem malware um pouco mais rápido? Mas acho que tem os dois aspectos.

É mais sobre como você continua a aproveitar qualquer uma dessas ferramentas para melhorar a escrita de código, mas escrevendo um código mais seguro. E eu sei, Tim, essa é uma área de paixão para você. Gostaria de falar um pouco mais sobre como você vê a evolução do Secure Code em 2023 e o que você está fazendo nesse espaço?

TIM NASH: Bem, quero dizer, de várias maneiras, o Chat GPT é um bom exemplo disso. Se eu estava pensando em um vetor de ataque, vou ser sincero, não estava pensando em escanear em massa, alimentando-o com muitas coisas como um ator ruim. Eu estava pensando nisso como o desenvolvedor de código médio que estava tentando economizar tempo e estava inserindo coisas no Chat GPT e jogando fora e não necessariamente entendendo completamente todo o código que está sendo escrito, sendo produzido, não escrevi nenhum teste para vai com isso. Isso é apenas uma coisa rápida, é apenas um script rápido, está tudo bem. Entra em produção, não está bem e queima tudo.

Agora, isso é exatamente o mesmo que algo que todo desenvolvedor faz todos os dias, independentemente. O Chat GPT não está mudando isso, mas o habilita com um pouco mais de facilidade. Dá – há menos barreiras.

SERGI ISASI: Sim, então não é exatamente o mesmo que copiar e colar do Stack Overflow, que eu acho que é o que você está se referindo, Tim, que é basicamente tudo que eu faço para o código. Mas acho que é um aumento de eficiência com certeza, tanto para o positivo quanto para o negativo. Mas eu acho que permite mudanças mais sutis e exploração mais rápida de algo que mais do que o mecanismo baseado em assinatura não pode realmente alcançar. Então, quando você está fazendo a detecção, você precisa ter um sistema que diga, isso parece semelhante a algo que eu vi no passado, em vez de corresponder diretamente a algo que eu vi no passado. E isso é, na verdade, do lado da detecção, provavelmente também melhor servido com ML ou AI ou como você quiser chamá-lo.

Aprendemos isso com tráfego automatizado, basicamente bots. A melhor maneira de saber como eles estão contornando a detecção baseada em assinatura é com ML. Mas agora você está passando de, eu sei absolutamente que isso é ruim, para, bem, é provável que seja automatizado ou provavelmente se pareça com uma assinatura que eu já vi antes, mas não uma correspondência exata.

MODERADOR: Maravilhoso. Obrigado. Obrigado, Sergi e Tim por esse contexto adicional. Portanto, entre os participantes, temos muitos desenvolvedores e agências que estão presentes aqui hoje. E muita gente está pensando em estabelecer as melhores práticas, principalmente porque os cenários estão mudando em termos de vetores de ameaças. Então, quais são algumas das melhores práticas que você recomendaria ao criar um site, um aplicativo ou uma plataforma, ou apenas ao iniciar um novo projeto? Então, quais são algumas coisas que as pessoas devem estar atentas?

SERGI ISASI: Então eu posso começar isso. Seria mais do lado operacional do que do lado do desenvolvimento. Acho que uma das coisas que pregamos aqui é, primeiro, assumir que algo ruim vai acontecer. Então uma brecha está chegando, você não pode simplesmente ir se surpreender com ela. É provável que aconteça em algum momento. E nossa chave– então, primeiro, crie um livro de corrida para isso. Portanto, quando isso acontecer, saiba com quais pessoas entrar em contato e qual será sua resposta, tanto da detecção quanto da resposta, mas também comunique-se com seus clientes se isso os afetar. E nesse sentido, o que nós, penso, fazemos muito bem na Cloudflare e faz parte da nossa marca e acho que nos serviu muito bem é ser franco, aberto e o mais comunicativo possível sobre qualquer coisa isso aconteceu.

A franqueza tem sido muito importante para restabelecer a confiança dos clientes quando algo ocorre, seja uma violação de software ou algum erro que você cometeu em relação a um incidente. Esconder-se atrás dele nunca é a escolha certa.

MODERADOR: Sim.

JIMMY SQUIRES: Acho que outra coisa também é que nós – agora que todos estão obviamente remotos e especialmente nas equipes de desenvolvimento, estão realmente reservando um tempo no início de um projeto para fazer algum quadro branco e planejamento arquitetônico. É tão fácil mergulhar direto nos requisitos e criar histórias de desenvolvimento, mas gastar tempo com seus colegas para questionar como isso poderia ser explorado? Percorra os cenários. Fazemos muito planejamento de cenários que leva a muitas boas conversas sobre como queremos fortalecer diferentes partes do aplicativo.

LAWRENCE EDMONDSON: E só nisso, não sei se alguém sabe, mas o MPM é na verdade o maior repositório de arquivos compartilhados – é o maior repositório de bibliotecas de aplicativos que existe, mas isso significa que também representa o maior risco. Portanto, uma coisa da qual estamos muito cientes ao assumir um novo projeto, se estivermos usando o NPM, é garantir que estamos observando as vulnerabilidades, que estamos bloqueando as versões que enviamos para produção, que antes de Estamos fazendo uma atualização, garantimos que seja algo compatível, mas também muito seguro. Não há ameaças abertas porque vimos muitas vulnerabilidades se infiltrarem no NPM. Então, isso é apenas uma coisa a se observar.

TIM NASH: Acho que estamos repetindo tudo.

JIMMY SQUIRES: Vá em frente, Tim.

TIM NASH: Acho que estamos confundindo tudo isso com a ideia de que, na verdade, a confiança está sendo completamente quebrada nos ciclos de desenvolvimento há anos. As pessoas estão começando a perceber isso agora. E se você é um desenvolvedor PHP trabalhando no WordPress, por exemplo, fica sentado chamando ações e filtros, mas não deveria confiar nessas ações e filtros. Qualquer dado que esteja chegando, você deve validar, você deve verificar. Deve ser higienizado. Mas quando está saindo do banco de dados, você ainda não deve confiar nele.

Mesmo que você tenha colocado esses dados no banco de dados, não deve confiar nos dados que estão saindo. Se estamos passando algo para uma biblioteca de terceiros, seja esse NPM, seja aquele pacote de compositor ou apenas outro plugin do WordPress, imediatamente isso sai de nosso controle, não confiamos nele novamente. Mas quando ele volta, mesmo que o tenhamos verificado, ainda não confiamos nele. E se você entrar com essa mentalidade, como desenvolvedor, de que todos os dados não devem ser confiáveis ​​e devem ser isolados o tempo todo e você deve fazer as verificações de segurança em cada ponto, você chegará com um sistema muito mais seguro. Você pode sair com um sistema um pouco mais lento. Você pode se deparar com um sistema um pouco mais frustrante e que precisa de muito mais testes para garantir que o que você está fazendo não esteja realmente causando mais problemas do que ajudando.

MODERADOR: Sim.

TIM NASH: Adicione complicações, mas você acaba com um sistema muito mais seguro. E para a maioria das pessoas, é isso que elas querem.

LAWRENCE EDMONDSON: Sim.

MODERADOR: Sim. Você está absolutamente correto. Trata-se de não confiar em nenhum outro pedaço de código que está chegando. E sobre o que Jimmy e Sergi falaram, é ter um plano e de uma perspectiva de arquitetura, ou de uma perspectiva operacional, mas reunir tudo isso em sua prática geral, seja como mecanismos de codificação de segurança ou ter um manual de incidentes. Então, Tim, estou muito interessado em ouvir mais de você por aí - você faz muito treinamento, ensina muito em todo o mundo. Quais são alguns erros comuns que você vê quando as pessoas começam a trabalhar em projetos, ou erros que você pode ter cometido, eu cometi muitos deles.

TIM NASH: Eu ia dizer, tenho certeza de que sou culpado de todos os erros sobre os quais estou prestes a falar. E o maior e o mais simples é ser uma pessoa legal. A maioria dos desenvolvedores assume boas intenções. A maioria das pessoas supõe que você usará o aplicativo da mesma forma que o escreveu. Agora, com bastante frequência, não escrevemos documentação para que o usuário não tenha ideia de como usar o aplicativo em primeiro lugar, mas isso é um problema separado. Um ator ruim vai entrar e pegar qualquer bug e ir embora, isso não é um bug, para um ator ruim, isso é um recurso. Isso é uma oportunidade. Está fazendo algo que o desenvolvedor não espera, portanto, há uma rota potencial para isso.

E, no geral, algo que você vê repetidamente, quando diz, olhe, você tem um conjunto de testes de unidade. Ótimo. Mas você só testou as coisas positivas, o resultado que você queria. Você não testou o que acontece se sairmos desses limites. Você acabou de testar para garantir que a coisa funcione de acordo com o que seu chefe deseja. Então, o que você realmente tem são testes de aceitação, testes de aceitação duvidosos. E então tudo se resume a todos os fundamentos. Como desenvolvedor, é baseado nisso, não confie nas coisas. E se você é um desenvolvedor WordPress em particular, o WordPress realmente tem algumas funções auxiliares realmente boas para fazer todo tipo de segurança padrão que pedimos para as pessoas fazerem.

E trata-se de educar e aprender a usá-los. Quando estou fazendo revisões de código, sempre vejo os mesmos problemas. E se eu vir uma vez em um código, verei 1.000 vezes no mesmo conjunto de códigos. E serão coisas como, sim, bem, nós apenas permitimos que qualquer coisa antiga aparecesse na página. Não nos preocupamos em verificar se havia ou não alguma coisa lá dentro. Sim, colocamos coisas no banco de dados. Olha, pode parecer uma consulta SQL, pode não ser.

Todos esses tipos de coisas são fáceis de consertar e já fornecemos as ferramentas para consertar. E a razão pela qual não os corrigimos nem sempre é porque as pessoas não sabem que não devem deixar essas coisas acontecerem, é que ficamos preguiçosos, estamos fazendo as coisas rapidamente, estamos pegando o código do Stack Overflow, estamos fazendo com que o Chat GPT faça coisas para nós, não estamos verificando as coisas. E muitos problemas de segurança vêm desse estado, devo me apressar. Eu devo me apressar. Eu devo me apressar, eu tenho que fazer isso. Estou passando para a próxima coisa, estou passando para a próxima coisa.

Estranhamente, para muitos desenvolvedores, na verdade, apenas dando a eles tempo e espaço e dizendo, não há problema em reservar um tempo para realmente verificar o que você fez para que, quando acontecer - e nos casos em que eu entro em jogo, Estou voltando e dizendo, bem, todas essas coisas e os desenvolvedores parecem envergonhados. Eles estão indo, sim, nós sabemos de tudo isso. Nós simplesmente não tivemos tempo.

Então esperamos dar às pessoas mais tempo e realmente dar-lhes as ferramentas, que já temos particularmente dentro do WordPress. O WordPress tem um conjunto realmente brilhante de funções auxiliares para os problemas de segurança mais comuns que você teria em um plugin ou tema do WordPress. Portanto, trata-se apenas de aprendê-los e investir tempo para realmente implementá-los.

MODERADOR: Sim. E acho isso muito poderoso, investir tempo. Na maioria das vezes, os desenvolvedores sabem o que precisa ser corrigido. Então, dando-lhes tempo. Então, eu realmente gosto dessa mensagem. E Jimmy, sei que você trouxe isso para o seu próprio fluxo de trabalho em sua agência. Você quer falar um pouco mais sobre as práticas seguras de fluxo de trabalho que você implementou?

JIMMY SQUIRES: Sim, com certeza. E realmente, começa com algo que Sergi disse que é ter um plano, ter diretrizes e padrões para sua equipe de desenvolvimento seguir. Sei que isso provavelmente parece muito básico, mas já vi muitas organizações e ouvi de muitos engenheiros que contratamos ao longo dos anos que isso não existia. Não havia organização no local de trabalho de onde vinham.

Então, o que gostamos de fazer é ter um conjunto padrão de diretrizes, todos os nossos novos engenheiros precisam ler isso de cima a baixo. Não é tão pesado que não seja consumível. Gostamos de mantê-lo em markdown, então está tudo em um repositório. Provavelmente abriremos o código em algum momento. Não há nada lá que seja realmente proprietário, e então encorajamos todos a contribuir com isso. Isso é um pedido a todos os engenheiros.

Portanto, mesmo em nossas diretrizes, faça furos onde podemos adicionar, onde podemos ser melhores, crescendo continuamente. Mas gastar tempo com isso, algumas das coisas básicas como OWASP, é uma prática muito antiga, mas passar por isso com seu aplicativo, considerando essas coisas. É mais ou menos o que Tim disse, é realmente tomar o tempo e estar bem em levar o tempo com isso. Eu queria adicionar um ponto extra à conversa sobre IA. Conversar com alguns de nossos engenheiros na semana passada realmente teve um evento. Estamos usando o Chat GPT para isso, na verdade, para testes de unidade. Pegando uma função e explorando-a de maneiras interessantes, como você pode aproveitar algo como Chat GPT para escrever um teste de unidade em que você não será o melhor autor desse teste de unidade, para o ponto de Tim. É aí que eu acho que podemos aproveitar muito mais a IA de forma preventiva.

LAWRENCE EDMONDSON: Sim. O que estamos fazendo do nosso lado, acho que listas de verificação e ter um manual são ótimos. Estamos usando ferramentas automatizadas como o SonarQube e realmente implementando o linting e coisas assim, apenas para aumentar a qualidade do código com o linting, mas também usando o SonarQube apenas para garantir que o código seja mais seguro, que estamos procurando para vulnerabilidades e coisas assim. Acho que algumas linguagens são mais fáceis do que outras de encontrar exploits, como mencionei antes, apenas por causa da natureza da linguagem. E também apenas algumas estruturas em que a qualidade dos codificadores que estão contribuindo para essa base de código normalmente - normalmente vemos isso com o código aberto, onde é como - há muitas cópias e colagens do Stack Overflow acontecendo, versus pessoas que realmente estudaram CS e realmente sabem o que estão fazendo. Então, isso é apenas uma coisa que eu vi.

TIM NASH: Acho que devemos apontar, certamente para mim, que uso o Stack OverFlow praticamente todos os dias. E então somos todos culpados disso. É bom falar sobre isso, mas não acho… Quero dizer, lembro-me de quando comecei a codificar. Peguei uma revista e estava digitando o código da revista e pressionando Enter. Não consigo imaginar a web realmente funcionando hoje se ainda continuássemos fazendo isso e não tivéssemos o Stack Overflow ou algo semelhante.

Sergi: Não, é o acelerador. E espero que a IA seja o próximo estágio disso. Mas sim, é um meme divertido.

MODERADOR: Obrigado. Então mudando um pouco. Há muito impulso acontecendo na indústria em torno de implementações Headless e Headless. E também vimos em alguns de nossos outros canais hoje ou em outras sessões falando sobre Headless. Então, quando começamos a trabalhar com o Atlas no WP Engine, nos encontramos com muitos desenvolvedores e a segurança sempre foi um motivador importante. Então, como você vê a segurança com o Headless? E eu sei, Jimmy, esta é uma área em que você fez alguns projetos em torno dela. Adoraríamos saber sua opinião sobre isso.

JIMMY SQUIRES: Sim, trabalhamos muito em Headless. Acho que quase todos os nossos projetos neste momento provavelmente adotam uma abordagem de arquitetura sem cabeça. Eu acho que alguns pontos que eu só quero fazer sobre isso, no que se refere à segurança. Portanto, acho que a primeira é que, ao escolher uma arquitetura sem cabeça, você geralmente se coloca mais no campo do código aberto no início. E há muito debate, é claro, sobre o que é mais seguro, código aberto ou código fechado. Costumo cair no campo dos projetos OSS que são mais seguros por natureza. Então você está escolhendo frameworks como Next, WordPress, onde você tem uma comunidade gigante. E isso tende a se prestar a mais segurança apenas por meio da exposição.

Então eu acho que é um. Acho que o segundo é algo como Geração Estática. Muitos sites e produtos que são construídos não precisam da natureza dinâmica de um grande gerenciamento de conteúdo, sistema monolítico no sentido tradicional. Você pode aproveitar algo como Cloudflare e realmente gerar estaticamente grandes porções desse aplicativo, reduzindo assim sua pegada para vetores e exposição. Então, somos grandes fãs disso. E então, é claro, você obtém todos os benefícios de desempenho com isso também. Então, esses são apenas alguns pontos que eu queria destacar na arquitetura sem cabeça. Mas muito mais razões do ponto de vista de segurança que gostamos. Mas acho que essas são provavelmente duas das maiores áreas de destaque.

TIM NASH: Eu gostaria apenas de voltar e lembrar às pessoas que ainda há um sistema de gerenciamento de conteúdo lá na parte de trás. E ouço isso com muita frequência, Headless é totalmente seguro. É como, sim, mas aquela instância exposta do WordPress que ainda está lá, só porque você não a está chamando diretamente do site, sim, ainda está lá em admin.yoursite.com. E você não… há uma certa crença de que, sim, bem, estamos seguros agora, então não precisamos nos preocupar em mantê-lo atualizado porque não é o site. É como, não, não, você ainda precisa de todas as coisas que estava fazendo antes e agora temos o outro lado também.

E quero dizer, Headless é um ótimo termo para algo que existe há muito tempo e está ganhando muito impulso, mas estávamos fazendo isso antes de o WordPress ter uma API REST. Estávamos enviando conteúdo do WordPress para coisas como Jekyll para obter pelo menos um site estático. E o raciocínio original para fazer isso era colocá-lo variando o sistema WordPress ou seu sistema de gerenciamento de conteúdo dentro de sua rede. Assim, você pode bloqueá-lo e mantê-lo longe da grande e assustadora web.

Agora estamos recebendo muitas empresas de hospedagem que fornecem soluções sem cabeça. 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. Obrigado. 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.