fbpx

Três dias de DevSecOps

devsecop
Compartilhar no facebook
Compartilhar no linkedin
Compartilhar no twitter
Compartilhar no whatsapp

Há muitas lições de segurança que podem ser aprendidas nos dias que cercam a violação da Equifax em março.

Três dias em março de 2017 surgiram continuamente em conversas do DevSecOps que li em foruns da comunidade Cloud e DevSecOps. Enquanto a maioria das pessoas amarra os três dias que antecederam o dia 10 de março à violação da Equifax, eu gravei tudo de uma forma muito diferente.

Primeiro, enquanto a Equifax foi violada em 10 de março, devido ao uso de componentes Struts vulneráveis ​​conhecidos, eles não foram os únicos violados naquele dia. Adicione o GMO Payment Gateway do Japão, o Canada Revenue Service e o Canada Statistics à lista. Saia por mais três dias até 13 de março e você poderá adicionar o Japan Post e o Okinawa Power. Um mês depois, o India Post também foi violado. Tudo resultou do uso de versões conhecidas de Struts vulneráveis.

Agora, deixe-me mapear isso de volta para as práticas do DevSecOps. Três dias em março de 2017 surgiram continuamente em conversas do DevSecOps que li em foruns da comunidade Cloud e DevSecOps.

De acordo com o mais recente relatório Accelerate: State of DevOps da DORA, 7% das organizações de DevOps podem implantar sob demanda várias vezes ao dia.

O prazo para mudanças nessas mesmas organizações é inferior a uma hora. Em teoria, se uma dessas organizações descobrisse a vulnerabilidade do Struts em 7 de março e soubesse onde elas estavam usando as versões ruins, elas poderiam implantar rapidamente as alterações em seus ambientes de produção – ficando à frente de seus adversários.

Além dessas organizações de DevOps de “elite” estão os 48% conhecidos como “de alto desempenho”. Dado o mesmo conjunto de circunstâncias, essas organizações podem implantar mudanças entre um dia e uma semana. Se eles podem se mover mais rápido que três dias, eles estão à frente dos adversários.

Se for mais lento que três dias, eles correm risco. Todas as organizações fora da “elite” e “de alto desempenho” estão sempre em risco porque não podem implantar mudanças mais rapidamente do que seus adversários. Por isso que o modelo de varias mudanças simples e poucas complexas é adotado pela NetFlix, Uber, etc…

Este não é um problema novo. De fato, no 4º Relatório Anual da Cadeia de Fornecimento de Software, divulgado hoje pela Sonatype, mostramos que o tempo médio entre descoberta e exploração de vulnerabilidades foi reduzido em 93,5% – ou quatro vezes – nos últimos anos. Além disso, o relatório também aborda situações em que os adversários injetam vulnerabilidades conhecidas em versões de código aberto para torná-las exploráveis ​​no segundo em que são implantadas.

Em 2017, pode-se considerar “três dias” como a nova normal para o lead time das mudanças no DevSecOps. Em 2018, essa janela fechou para “um segundo”. Os adversários não são apenas espertos, mas também são rápidos e criativos.

Não se engane, sua organização pode se proteger com as práticas corretas, cultura e ferramentas para apoiar sua iniciativa DevSecOps. Mas perceba, a barra está sendo definido mais alto a cada ano – não apenas por seus próprios membros e líderes de equipe -, mas por aqueles que podem causar estragos em sua reputação e clientes bem merecidos.

Convido-o agora a ler o Relatório da Cadeia de Fornecimento de Software 2018/2019 da Sonatype, que lançará nova luz sobre o DevSecOps e as práticas de desenvolvimento de código aberto que afetam sua organização.

Comentários do Facebook

Conteúdos relacionados