Blog Infonova

Informação para tomada de decisão

Resultado da pesquisa por: ""

O que é DevSecOps e por que é tão difícil de implementar?

Por Juliana Gaidargi em 3/05/2021 em Gestão de TI

Saber o que e DevSecOps se tornou de suma importância no cenário atual. Afinal, ele trata da introdução da segurança no início do ciclo de vida de desenvolvimento de aplicativos. Ou seja, visa minimizar as vulnerabilidades e aproximar a segurança dos objetivos de TI e de negócios.

devsecops

O que é DevSecOps, afinal?

DevSecOps consiste em uma mudança de cultura na indústria de software. Afinal, visa preparar a segurança nos ciclos de liberação rápida típicos do desenvolvimento e implantação de aplicativos modernos, também conhecidos como movimento DevOps. Contudo, adotar essa mentalidade exige que as organizações preencham a lacuna que geralmente existe entre as equipes de desenvolvimento e segurança. Ou seja, muitos dos processos de segurança devem ser automatizados e gerenciados pela própria equipe de desenvolvimento.

Qual é a diferença entre DevSecOps e o desenvolvimento de software tradicional?

Tradicionalmente, os principais desenvolvedores de software costumavam lançar novas versões de seus aplicativos a cada poucos meses ou mesmo anos. Isso proporcionou tempo suficiente para que o código passasse por testes de garantia de qualidade e segurança. Equipes especializadas distintas executavam esses processos.

No entanto, os últimos dez anos viram o surgimento de nuvens públicas, contêineres e o modelo de microsserviço. Neles, dividem-se aplicativos monolíticos em partes menores que funcionam de forma independente. Contudo, essa mudança também teve um impacto direto na maneira como o software é desenvolvido. 

Afinal, levou a lançamentos e práticas de desenvolvimento ágil. Ou seja, onde novos recursos e códigos são continuamente colocados em produção em um ritmo rápido. Portanto, muitos desses processos foram automatizados com o uso de novas tecnologias e ferramentas, permitindo que as empresas inovem com mais rapidez e fiquem à frente da concorrência.

O papel da nuvem

No entanto, o avanço da nuvem, contêineres e microsserviços, também levou ao surgimento do que o setor chama de cultura DevOps. Nela, os desenvolvedores agora podem provisionar e escalar a infraestrutura de que precisam sem esperar que uma equipe de infraestrutura separada faça isso por eles. Inclusive, todos os principais provedores de nuvem agora oferecem APIs e ferramentas de configuração que permitem tratar a configuração da infraestrutura como código usando modelos de implantação.

Contudo, embora a cultura DevOps trouxesse muitas inovações para o desenvolvimento de software, a segurança muitas vezes não era capaz de acompanhar a nova velocidade com que o código estava sendo produzido e lançado. Por isso, você deve entender o que é DevSecOps e qual é o seu papel nesse cenário. 

Afinal, o DevSecOps é uma tentativa de corrigir isso e integrar totalmente os testes de segurança nos pipelines de integração contínua (CI) e entrega contínua (CD). No entanto, de forma a também construir o conhecimento e as habilidades necessárias na equipe de desenvolvimento para que os resultados dos testes e da correção possam também pode ser feito internamente.

Fatores que tornam um ambiente DevSecOps real

  1. O teste de segurança é feito pela equipe de desenvolvimento;
  2. Os problemas encontrados durante o teste são gerenciados pela equipe de desenvolvimento;
  3. Portanto, a correção desses problemas fica por conta da equipe de desenvolvimento.

Chris Wysopal, cofundador e diretor de tecnologia da empresa de testes de segurança de aplicativos Veracode, afirma que “O último vai levar algum tempo, mas acho que é quando a segurança do aplicativo realmente se torna DevSecOps e não há necessidade de uma equipe separada.”

Atingindo a verdadeira integração entre segurança e desenvolvimento

De acordo com Wysopal, alcançar a última etapa é difícil porque os desenvolvedores devem construir o conjunto de habilidades necessárias para corrigir bugs relacionados à segurança sem orientação externa. Contudo, isso leva bastante tempo. 

Entretanto, muitas equipes chegam lá incorporando um denominado campeão de segurança em suas equipes de desenvolvimento. Ou seja, incluem alguém com experiência em segurança de aplicativos e com treinamento mais avançado nesse campo do que a maioria da equipe. Contudo, também é importante treinar toda a equipe em práticas de programação seguras. De qualquer forma, essa pessoa pode revisar as correções de segurança para se certificar de que estão corretas.

Contudo, isso não significa que o líder de segurança não pode obter uma opinião de especialista fora da equipe. É o caso de consultar o provedor de testes de segurança de aplicativos da empresa que oferece serviços de consultoria aos clientes, por exemplo. 

Exceção, não regra

No entanto, isso seria só em casos especiais, não a norma. Portanto, é diferente de ter equipes de desenvolvimento e segurança separadas e ter um ou mais membros da equipe de segurança integrados às equipes de desenvolvimento. De acordo com Brian Fox, CTO de automação de DevOps e empresa de governança de código aberto Sonatype, a integração entre desenvolvimento e segurança precisa acontecer no nível de gerenciamento também.

“Quando a missão da segurança não está totalmente alinhada com a integração total ao desenvolvimento, de cima para baixo, não acho que você termine com a coisa certa. Afinal, você acaba tendo esses confrontos de nível gerencial às vezes em que os objetivos são diferentes, mesmo que as pessoas trabalhem na mesma equipe. É semelhante a brincar em paralelo com crianças pequenas: você tem duas crianças brincando lado a lado, e elas não estão lutando, mas isso não significa que estão realmente brincando juntas. Acho que isso vem acontecendo em muitas organizações. “

Houve um caso em que costumava haver um gerente de QA e um gerente de engenharia e eles trabalhavam juntos. Contudo, sempre havia um pouco de tribalismo acontecendo.

 “Assim que isso acabou e o QA se tornou parte das coisas que as pessoas da equipe de desenvolvimento estavam fazendo, você parou de ver a mentalidade de nós contra eles, porém, ainda não chegamos lá com a segurança. Acho que é aí que muitas empresas têm dificuldade”.

Teste e ferramentas DevSecOps

As empresas de tecnologia do Vale do Silício lideraram o caminho na adoção do DevSecOps no início. Entretanto, as ferramentas de teste de segurança disponíveis na época não eram amigáveis ​​para o desenvolvedor. Afinal, os desenvolvedores querem ferramentas de linha de comando que:

  • Possam ser automatizadas;
  • Permitam ajustar facilmente várias configurações;
  • Cuja saída possa ser facilmente importada para rastreadores de bugs;
  • Scanners de segurança tradicionais são projetados com equipes de segurança com CISOs em mente. Afinal, seus  objetivos são governança, segurança, conformidade de políticas e gestão de riscos.

Então, lentamente, novas ferramentas começaram a surgir, criadas por desenvolvedores para desenvolvedores e integradas a ambientes de desenvolvimento e fluxos de trabalho de CI / CD. Algumas eram de código aberto, outras eram modelos de negócios iniciantes construídos em torno deles. Contudo, embora resolvessem as necessidades dos desenvolvedores, eles realmente não atendiam mais às necessidades do CISO.

No entanto, se muitas ferramentas de código aberto diferentes estão sendo usadas, a equipe de desenvolvimento pode sentir que está cobrindo o que acha que precisa cobrir. Afinal, de uma perspectiva de governança, é difícil para a equipe de segurança mapear todas essas diferentes ferramentas fragmentadas para as políticas da empresa.

Mudanças

Portanto, nos últimos dois anos, os fornecedores de segurança de aplicativos tradicionais mudaram seus produtos para atender a ambos os casos de uso:

  1. Para fornecer análises e relatórios necessários para os CISOs;
  2. Ter a flexibilidade e facilidade de uso esperadas pelos desenvolvedores. 

Ou seja, alguns provedores de serviços baseados em nuvem voltados para desenvolvedores, como o GitHub, começaram a adicionar testes de segurança diretamente a seus serviços. Quando não está disponível como um recurso nativo, geralmente está disponível no mercado do serviço como uma integração de um fornecedor terceirizado.

“Ao longo de toda a minha carreira, observei um padrão que se repete. Há um pêndulo que parece balançar para frente e para trás entre as pessoas que querem um fornecedor e um conjunto de ferramentas abrangente e as pessoas que estão montando as melhores correntes de ferramentas. Eu diria que nos últimos dois anos vimos as coisas balançarem muito dramaticamente para a suíte abrangente única” – Fox.

Porém, esse cenário deve mudar. Provavelmente, quando a próxima tecnologia disruptiva vier e as organizações precisam estar prontas para isso. O problema com os pacotes é que eles podem se destacar em uma ou mais coisas de que a organização precisa. 

No entanto, depois incluem outros recursos que são usados ​​porque vêm gratuitamente com o pacote, não porque sejam a melhor solução para os respectivos problemas que estão disponíveis. Com o tempo, isso pode levar a grupos fragmentados de desenvolvedores dentro da organização que começarão a testar e usar outras ferramentas que atendam às suas necessidades melhor do que o conjunto aprovado pela empresa oferece.

Governança

Do ponto de vista da governança, ter equipes não gerenciadas é ruim. Porém, as empresas precisam estar cientes de que, daqui a um ou dois anos, isso acontecerá inevitavelmente e, apesar das tentativas de restringir o uso de ferramentas, sempre haverá alguns desenvolvedores que farão suas próprias coisas. Segundo Fox:

“Os primeiros a adotar a nuvem às vezes eram equipes individuais em organizações muito maiores que se rebelavam contra o tempo que demorava para obter as máquinas. Então, se você abraçar e entender que isso vai acontecer e pensar sobre isso, você pode ser um pouco mais flexível para reconhecer que, ei, esta nova equipe pode realmente estar à beira de alguma inovação realmente disruptiva que pode ser a coisa pelo qual queremos substituir esta funcionalidade da suíte”.

Adoção de DevSecOps

De acordo com Wysopal, mais empresas estão integrando varreduras de segurança automatizadas como parte dos pipelines de CI / CD. Contudo, os resultados podem não ser imediatamente aparentes por causa do que ele chama de “dívida de segurança”. Este consiste no número de vulnerabilidades que entram em produção porque os desenvolvedores optaram por não corrigi-los.

Isso pode acontecer por vários motivos, incluindo:

  • Ser incapaz de corrigi-los imediatamente;
  • Não planejar consertá-los porque há outras atenuações em vigor;
  • Deixar de corrigi-los porque têm uma gravidade inferior. 

O relatório State of Software Security de 2019 da Veracode revelou dados bastante interessantes. Baseado em dados coletados de varreduras realizadas em 85.000 aplicativos ao longo de um ano, revelou que o tempo médio de correção de vulnerabilidades encontradas em aplicativos é de 171 dias, em comparação com o tempo médio de 59 dias, uma década atrás, quando o primeiro relatório saiu. No entanto, a dívida de segurança acumulada distorce isso. Portanto, o tempo médio para consertar, na verdade, permaneceu quase o mesmo.

Contudo, ao correlacionar os resultados da varredura com a frequência das varreduras de um determinado aplicativo, os dados mostram que os aplicativos varridos diariamente têm um tempo médio de correção de 19 dias em comparação com 68 dias para aplicativos que são verificados mensalmente. Afinal, a frequência aumentada sugere integração da varredura automatizada em fluxos de trabalho de CI / CD. Então, isso sugere que é mais fácil e rápido corrigir vulnerabilidades ao realizar a varredura com mais frequência.

Assim como ocorre com a dívida financeira, a saída da dívida mobiliária exige necessariamente uma mudança de hábitos de pagamento de saldos. Portanto, a integração de desenvolvimento de software e operações de TI (DevOps) e integração de segurança nesses processos (frequentemente chamados de DevSecOps) nos últimos anos certamente mudou hábitos.

Mudança de cultura

Outro benefício de uma verdadeira mudança de cultura em relação ao DevSecOps deve ser que o número de vulnerabilidades graves que existem no código também deve diminuir. Os dados da Veracode mostram que a porcentagem de aplicativos sem vulnerabilidades caiu de modo geral em comparação a 10 anos atrás, sugerindo que a situação piorou. No entanto, a porcentagem de aplicativos sem falhas de alta gravidade na verdade aumentou de 66% para 80%.

“Vejo muitas organizações ainda lutando com esse modelo. Elas estão se movendo em direção a este ambiente de desenvolvimento contínuo, têm infraestrutura e CI e estão usando contêineres. Eles têm uma equipe de segurança de aplicativos que vem posteriormente executando varreduras, produzindo relatórios – às vezes relatórios impressos em papel literalmente – e trazendo-os para o desenvolvimento, ao invés de alavancar ferramentas que capacitam o desenvolvimento para evitar esses erros no início. A maior parte das organizações que vejo ainda cai nessa mentalidade de nós contra eles, desenvolvimento e segurança” – Fox.

Profissionais ainda terão espaço

Contudo, mesmo com DevSecOps, profissionais de segurança e o teste manual ainda terão sua importância. Afinal, varreduras totalmente automatizadas não conseguem encontrar falhas lógicas ou de projeto.

“O que estamos começando a ver é que o teste manual não é feito uma vez por ano, ou duas vezes por ano. Na verdade, ele está sendo mais iterativo. Afinal, está sendo feito mais como parte do processo de DevOps, onde talvez haja um sprint de duas semanas, no qual estão fazendo um novo recurso que tem impacto na segurança como uma pequena quantidade de teste manual que está acontecendo apenas para esse recurso. Às vezes, isso pode ser feito pelo líder de segurança, se ele entender o suficiente sobre o teste manual e atender ao objetivo da equipe de desenvolvimento fazer isso sozinha” –  Wysopal.

Alternativa

Contar com uma parceira de TI especializada pode fazer a diferença para o seu negócio. Afinal, ela saberá detectar e informar possibilidades de melhorias. A Infonova, por exemplo, atua nessa área há 20 anos. Portanto, é plenamente capaz de monitorar a segurança dos seus dados de forma assertiva e com custo acessível.

Sobre a Infonova

A Infonova já atendeu mais de 135 clientes dos mais diversos segmentos, desde corporate, governo, PME até indústria do entretenimento e saúde. Você pode conferir a lista completa de clientes satisfeitos da Infonova aqui.

A Infonova usa uma metodologia consolidada. Portanto, essa empresa de TI conta com depoimentos da maioria de seus clientes garantindo a qualidade do atendimento.

metodologia infonovaEm relação à confiança, a Infonova comprova sua transparência e seriedade logo no início do nosso contrato. Afinal, é quando realiza uma visita inicial de manutenção intensiva em todos os computadores da sua empresa e também servidores.

Inclusive, se você pedir, a Infonova oferece um mapeamento de todo seu ambiente de TI.  Afinal, seu interesse é conhecer toda sua infraestrutura e, de cara, resolver todas as suas dores.

modelos de contrato

Resumindo, a Infonova faz um diagnóstico para identificar como está a sua TI. Então, avalia o que está bom, resolvemos o que está ruim e cria um projeto para o que é possível melhorar. Tudo isso sem custo. Ou seja, a Infonova conta com as melhores condições custo-benefício do mercado. Especialmente em relação a automação da infraestrutura em nuvem e outras inovações.

Perfil Infonova

A expertise da Infonova permite fornecer atendimento técnico local com escalas flexíveis definidas pelo cliente. Estas incluem:

  • Atendimento por demanda;
  • Disponibilização de equipes com 1 técnico local e retaguarda especializada; 
  • Equipes completas com até 200 profissionais qualificados para assumir parte ou toda a operação de TI.
Colaboradores

O trabalho executado pela equipe da Infonova é primoroso. Afinal, essa empresa de TI se preocupa com seus funcionários. Ou seja, a Infonova oferece participação nos lucros aos seus colaboradores a fim de mantê-los sempre motivados. Além disso, a contratação dos analistas é CLT Full, o que reduz o turnover e aumenta a confiança. 

Soluções

Como a empresa de TI completa que é, a Infonova tem soluções voltadas para PMEs, Governo e Corporate. Todas compreendem modelos flexíveis com início rápido e transição sem dor.

Confira a seguir:

soluções infonova

Para saber mais sobre os serviços da Infonova, entre em contato pelo (11) 2246-2875 ou clique aqui.

Se quer saber mais sobre o que nossos clientes têm a dizer sobre nossos serviços, baixe gratuitamente nossos cases exclusivos.

Já vai?

Receba conteúdos exclusivos e gratuitos direto no seu e-mail, para ler sem pressa ;)

FALE
COM UM
ESPECIALISTA

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

FALE
COM UM
ESPECIALISTA

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Acesse informação exclusiva para nossos clientes e esteja informado. Conheça as técnicas, ferramentas e estatísticas do mercado, de graça, e no seu email.
É só preencher o formulário para acessar.

Receba Gratuitamente

Passo 2
0%

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.

Receba Gratuitamente

Fique tranquilo, não compartilhamos suas informações.