0
0
As equipes de DevOps e segurança há muito estão em desacordo umas com as outras sobre o pipeline de entrega de software. Historicamente, as equipes de DevOps viram as equipes de segurança como o “departamento de prevenção de liberação” com abordagens excessivamente conservadoras para mitigação de riscos. Enquanto isso, as equipes de segurança acham que as versões aceleradas de software representam um risco muito grande para a governança, a segurança e os controles regulatórios. Para conciliar os dois, muitas organizações tentaram mudar a segurança e a conformidade, implementando medidas mais cedo no processo de desenvolvimento.
Embora essa abordagem limitada do DevSecOps melhore a qualidade e a entrega do software, ela não resolve todo o problema. As empresas com visão de futuro perceberam que não é suficiente mudar a segurança e a conformidade para a esquerda; elas precisam deslocá-las para todos os lugares.
Ao incluir processos de segurança e conformidade na automação de ponta a ponta, as empresas podem proteger o software em toda a cadeia de suprimentos de software, melhorar significativamente a experiência do desenvolvedor e acelerar a entrega mais segura. Para conseguir isso, as empresas precisam superar esses sete mitos comuns do DevSecOps que estão impedindo que elas façam a mudança.
7 mitos DevSecOps
Mito 1: Segurança e conformidade são um ponto único no processo de entrega de software.
Realidade: A segurança e a conformidade são mais eficazes quando são contínuas em todo o pipeline. As empresas que tratam a segurança e a conformidade como eventos, muitas vezes têm que afastar equipes de desenvolvimento inteiras das atividades de criação de valor por períodos ao longo do ano para gerenciar os requisitos de auditoria. Essa abordagem aumenta significativamente o “imposto de conformidade” de uma empresa. Se a segurança não for incorporada desde o início, as equipes de segurança gastam mais tempo voltando e corrigindo problemas – tempo que não agrega valor produtivo à organização.
Mito 2: Adicionar mais ferramentas ajudará a resolver os desafios de segurança e conformidade.
Realidade: Embora as ferramentas certamente possam ajudar na segurança e conformidade, soluções únicas geralmente não resolverão o problema geral. Normalmente, são necessárias mais pessoas para operar as ferramentas e analisar os resultados. Os gerentes de desenvolvimento devem consumir os resultados e priorizar as ações para os desenvolvedores. Embora mais ferramentas possam ajudar, mais ferramentas também podem significar maior complexidade. Encontrar uma solução única e abrangente, em vez de um conjunto de ferramentas, será mais eficaz e criará menos pontos potenciais de falha, dando uma visão holística da postura de segurança e risco de uma empresa.
Mito 3: Treinar desenvolvedores para serem especialistas em segurança e conformidade evitará a não conformidade.
Realidade: Seus desenvolvedores provavelmente querem inovar, não executar testes ou decodificar estruturas regulatórias. Os desenvolvedores devem estar absolutamente preocupados com a segurança – estamos aqui dizendo que a segurança é problema de todos – mas esperar que as equipes de desenvolvimento lidem com a segurança, além de sua descrição de trabalho, é uma boa maneira de sufocar a inovação e gerar ressentimento.
Mito 4: Incorporar especialistas em segurança em equipes de DevOps abordará o desafio.
Realidade: Ter um especialista em segurança dedicado dentro do silo de desenvolvimento pode ser útil para liberar os desenvolvedores para inovar. No entanto, essa abordagem ainda pode causar interrupções nos desenvolvedores e aprofundar a divisão entre as duas equipes.
Mito 5: Minha empresa é muito pequena ou obscura para ser alvo de um ataque cibernético.
Realidade: O custo médio de uma violação de dados para uma empresa está a milhões e está aumentando rapidamente. Nenhuma empresa deve se sentir confortável jogando com esse tipo de lucro. Todas as empresas – de todos os tamanhos e indústrias – estão em risco e precisam levar a segurança a sério.
Mito 6: Se eu automatizar, estou seguro e em conformidade.
Realidade: A automação é a chave para a segurança e a conformidade – mas muitas ferramentas de automação são soluções de ponta a ponto, em vez de automação de ponta a ponta. Se você implantar ferramentas para automatizar pontos únicos do seu pipeline, essas peças serão mais seguras. Mas se você implantar ferramentas para automatizar todo o seu pipeline, todo o seu pipeline será mais seguro.
Mito 7: Abraçar o DevSecOps é suficiente.
Realidade: É preciso mais do que apenas revisar seu pipeline de entrega de software para resolver os silos entre as equipes de desenvolvimento e segurança. A cultura em toda a sua organização também precisa ser revisada. Sim, a segurança precisa ser da preocupação de todos; mas a inovação e a produtividade também precisam ser uma prioridade em todas as equipes.
Segurança de ponta a ponta
Mudar a segurança em todos os lugares por meio de uma solução de entrega de software de ponta a ponta permite que você tenha segurança desde o início e em todo o pipeline. Longe vão os dias de auditorias de segurança de um mês que interrompem o desenvolvimento e a produtividade. O Advanced DevSecOps permite testes automatizados de segurança e conformidade, ao mesmo tempo em que impõe o uso de componentes aprovados.
A automação de ponta a ponta limita a introdução de falhas de segurança devido a erros humanos e, se algo quebrar, é mais fácil encontrar e corrigir o problema antes que o código comprometido seja entregue. Os controles de acesso são automatizados para gerenciar quem pode fazer alterações e quando – garantindo que ninguém altere acidentalmente componentes críticos sem ser notado.
Elimine silos através de pipeline compartilhado
Com uma plataforma de pipeline compartilhada que abrange desenvolvimento, controle de qualidade e operações, as organizações têm controle e visibilidade avançados sobre todo o processo de desenvolvimento do sistema. As equipes de segurança, desenvolvimento e operações obtêm uma compreensão holística compartilhada de todo o setor digital, permitindo que elas inovem com uma perspectiva informada.
Um pipeline compartilhado ajuda a detectar o código de problema pré-lançamento. Em vez de corrigir vulnerabilidades pós-entrega, correções incrementais podem ser implantadas para resolver problemas à medida que eles surgem. Mais visibilidade significa uma melhor compreensão do pipeline para todos, o que, por sua vez, melhora a comunicação e ajuda a eliminar a culpa.
Habilitar entrega progressiva
Uma solução de entrega de software de ponta a ponta permite a entrega progressiva do seu software para acelerar versões seguras e protegidas. A entrega progressiva introduz um novo código de forma contínua, em vez de através de lançamentos “big bang”. Essa abordagem mitiga o risco testando o código em pequena escala com a capacidade de reverter rapidamente qualquer código de problema que surja (gerenciamento de recursos). A entrega progressiva transforma uma versão de software em um processo gradual de baixo risco com governança confiável e fornece um “interruptor de empresa” caso algo sério aconteça na produção.
A entrega progressiva também dá aos desenvolvedores mais liberdade para inovar. No ambiente de lançamento de software de baixo risco, eles podem experimentar mais com menos risco e em um cronograma mais flexível. As equipes de desenvolvimento precisam do espaço para criar; a InfoSec precisa de segurança e governança. Um pipeline de software de ponta a ponta satisfaz ambos – o que se manifesta ao colocar os produtos no mercado mais rapidamente.
FONTE: HELPNET SECURITY