Resumo do painel: rompendo maus hábitos de segurança com Corey Quinn

Em 8 de dezembro, Clinton Herget e Simon Maple, Field CTOs da Snyk, tiveram a oportunidade de conversar com Corey Quinn, Chief Cloud Economist do The Duckbill Group, apresentador de podcast, curador de "Last Week in AWS” e personalidade sarcástica no Twitter.

A conversa teve vários momentos divertidos, desde reclamações sobre a fila de uma hora para tomar café no AWS re:Invent até Corey declarar que “SBOMs são uma fantasia” (há mais contexto por trás disso… continue lendo). Neste blog, vamos abordar alguns dos principais destaques, mas, se quiser ouvir todas as tiradas de Corey Quinn durante a conversa, assista ao painel completo aqui.

Principais aprendizados do AWS re:Invent 2022

Como o AWS re:Invent 2022 acabou de terminar, Corey e Clinton reservaram alguns minutos para compartilhar seus principais aprendizados. Corey destacou que é importante priorizar conhecer pessoas em vez de participar de sessões. O dia no AWS re:Invent tem um número limitado de horas, e Corey prefere aproveitá-las para conhecer pessoas da AWS, em vez de ficar sentado em sessões. Afinal, as sessões ficam disponíveis sob demanda depois da conferência, mas não dá para conversar pessoalmente com especialistas da AWS.

Clinton ficou animado com os detalhes anunciados sobre o compromisso da Amazon Web Services com o Open Cybersecurity Schema Framework (OCSF). Ao padronizar uma estrutura de segurança, a AWS estabelece um precedente para uma linguagem interoperável e legível por máquina para descrever a segurança de aplicações. Clinton vê isso como o primeiro passo para melhorar a conversa sobre riscos compartilhados em todo o setor.

Uma retrospectiva: os pesadelos de segurança da AWS em 2022

Corey Quinn e Clinton Herget também olharam para 2022 e refletiram sobre alguns “pesadelos” de segurança da AWS que precisam ser resolvidos no novo ano. Entre os principais estavam:

A desconexão entre os ambientes de desenvolvimento e produção

Segundo Clinton, um dos problemas mais importantes no desenvolvimento de software atualmente é a lacuna entre os ambientes de desenvolvimento e produção. Como tudo na nuvem é código, qualquer correção de riscos de segurança precisa acontecer no código. Ele explica: “Como operador, recebo um alerta vermelho, enorme e assustador dizendo: ‘você tem Log4J em um pod em um cluster EKS; precisa corrigir isso’. E agora? Não há uma forma automatizada e legível por máquina de entender qual arquivo e qual repositório Git precisam ser alterados por causa dessa notificação.”

Confiança implícita demais na cadeia de suprimentos de software

Além disso, em 2022, as equipes de desenvolvimento de software erraram ao confiar demais nos componentes da cadeia de suprimentos de software. Em vez de presumir que cada software de código aberto e suas dependências são seguros, as equipes precisam verificar se os componentes de terceiros são realmente seguros para uso.

SBOMs que não vão fundo o suficiente

Corey também apontou que as listas de materiais de software (SBOMs) atuais não são suficientes. Na opinião dele, elas não fazem jus à natureza interconectada dos aplicativos modernos. É possível seguir dependências transitivas até cair na toca do coelho de uma “dependência de uma dependência de uma dependência” e assim por diante, sem nunca entender completamente o nível de risco de terceiros no seu aplicativo.

Soluções para os desafios de segurança atuais

Clinton e Corey também falaram sobre como as empresas devem pensar nesses “pesadelos de 2022” e reagir a eles com a chegada do novo ano. Eles discutiram:

Complementar as SBOMs com outras boas práticas

Então, qual é a solução para melhorar as práticas atuais relacionadas a SBOMs? Corey Quinn brincou que “para corrigir isso de verdade, é preciso aplicar patches nos seres humanos”.

Em outras palavras, registrar todo o conteúdo da sua cadeia de suprimentos de software não vai resolver os problemas de segurança; o que faz diferença é mudar a cultura organizacional e capacitar as pessoas para resolver problemas de segurança. Uma parte importante disso é reduzir os alertas de segurança — diminuindo o ruído para que sua equipe possa priorizar o que realmente importa na SBOM.

Clinton também acrescentou que as organizações não deveriam ter vergonha de usar código aberto. Quando entendem que esse uso é aceitável — e não representa necessariamente um risco para o sucesso dos negócios —, elas podem ser muito mais transparentes sobre quais componentes compartilhados estão usando e onde.

Entender a fundo os processos atuais da sua organização

Como sua IaC, sua nuvem e seu código-fonte se relacionam? Como sua equipe de segurança trabalha com seus desenvolvedores — e vice-versa? Que contextos cada uma dessas pessoas considera no dia a dia? Clinton e Corey destacaram a importância de dar um passo atrás e responder a essas perguntas. Isso faz toda a diferença na forma como cada área da empresa enxerga e trata os riscos.

Corey também comentou que hesita muito em dar conselhos além de “entenda o contexto em que você está atuando e tome decisões que façam sentido para você”. Por isso, as organizações precisam fazer perguntas mais profundas e descobrir quais boas práticas de segurança funcionam para elas.

Trabalhar com o contexto da sua equipe de desenvolvimento — e não contra ele

A segurança costuma ser uma área reativa. Corey comentou que, embora necessário, o trabalho de segurança não impulsiona os negócios de forma tangível. Por isso, muitas vezes acaba ficando em segundo plano. Como a maioria das áreas provavelmente se sente assim em relação à segurança, as equipes precisam tornar as práticas de segurança o mais simples possível.

O SDLC precisa ser protegido com o mínimo possível de trabalho manual. Especialmente quando se trata de capacitar desenvolvedores com boas práticas de segurança, o segredo é se conectar ao contexto deles e entender com o que trabalham no dia a dia.

Ano novo, novas oportunidades de segurança na AWS

Isso é só uma pequena parte do que Corey e Clinton discutiram. Eles apresentaram inúmeras oportunidades de segurança na AWS para 2023, desde um foco maior em segurança voltada para desenvolvedores até mais transparência nas cadeias de suprimentos de software, entre muitos outros temas.

Não deixe de conferir a conversa completa aqui. Saiba também como a plataforma de segurança para desenvolvedores da Snyk pode ajudar você a expandir seu programa de segurança em 2023.