Houve muita conversa na conferência RSA deste ano sobre DevOps e segurança: DevOpsSec ou DevSecOps, DevOps Rugged ou seja lá como as pessoas queiram chamá-lo. Isso incluiu um seminário de um dia inteiro sobre DevOps antes da abertura da conferência e várias palestras e workshops durante todo o evento, que tentaram mostrar que o DevOps não trata apenas da entrega de software mais rápido, mas também sobre como fazer software melhor e mais seguro; e que DevOps não serve apenas para a nuvem, mas que pode trabalhar como um aliado dentro de uma empresa.

DevOps Rugged

A história do DevOps Rugged é baseada em algumas ideias centrais.

Entregar alterações menores, com mais frequência, reduz a complexidade. Mudanças menores e menos complexas são mais fáceis de executar teste e avaliação, e é mais fácil de solucionar problemas quando algo dá errado. E isso deve resultar em um código mais seguro: código menos complexo tem menos bugs, e código com menos bugs também tem menos vulnerabilidades.

Se você entregar código com mais freqüencia, precisará automatizar e agilizar o trabalho de testes e implantação. A criação e a implementação padronizada, repetitiva e automatizada, com built-in de testes e verificações, permite que você envie alterações muito mais rápido e com muito mais confiança, o que é importante quando você está tentando corrigir uma vulnerabilidade crítica.

E usar uma rotina de implantação automatizada para todas as alterações – alterações no código do aplicativo, alterações de configuração e mudanças na infraestrutura – proporciona melhor controle de mudanças. Você sabe o que foi alterado, por quem e quando, em cada sistema e pode acompanhar todas as alterações de volta para o seu sistema de controle de versão.

Mas isso significa que você precisa repensar em como fazer a implantação e o gerenciamento de configuração, e é por isso que muitos fornecedores – e não apenas Opscode e Puppet Labs, mas também fornecedores corporativos clássicos, como a IBM – estão tão animados com o DevOps.

O problema de teste de segurança em DevOps

Você também precisa repensar em como será feito o teste, especialmente o teste do sistema e os testes de segurança.

Em DevOps, com entrega contínua ou implantação contínua com a produção, não existirá um “sprint de endurecimento“, no qual você pode agendar um pen test ou uma varredura profunda do sistema, ou até mesmo uma auditoria para realizar revisões operacionais antes de o código ser distribuído. Em vez disso, será necessário fazer seu teste de segurança e controle de fase, conforme as alterações são enviadas. Motores de análise estática que suportam a verificação periódica podem ser utilizados neste momento, mas a maioria das outras ferramentas de verificação de segurança e de testes com as quais contamos atualmente não vão se manter, o que significa que você vai precisar escrever seus próprios testes de segurança. Mas isso levanta uma questão séria. Quem vai escrever esses testes?

A Infosec? Já há uma escassez global de pessoas que entendem de segurança de aplicativos atualmente, e a maioria dessas pessoas – aqueles que não estão trabalhando em consultorias ou para fornecedores de ferramentas – está ocupada fazendo avaliações de risco e executando varreduras, monitorando os resultados através do desenvolvimento e da correção de vulnerabilidades, ou talvez fazer revisões de código de segurança, ajudando com a modelagem dos problemas em um pequeno número de casos mais avançados. Eles não têm o tempo ou muitas vezes as habilidades para escrever testes de segurança automatizados em Ruby, ou qualquer estrutura de testes automatizados que você selecionar.

O QA? Em mais e mais empresas hoje, especialmente onde métodos ágeis ou DevOps são seguidos, não há ninguém no departamento de QA, porque testes manuais feitos através de listas de verificação de teste não podem se manter e, por isso, os desenvolvedores são responsáveis ​​por fazer seus próprios testes.

Quando se trata de testes de segurança, isso é um problema. A maioria dos desenvolvedores ainda não tem o conhecimento sobre segurança de aplicativos para entender como escrever código seguro, o que significa que também não podem compreender o suficiente sobre segurança para saber o que os testes de segurança precisam para ser escritos. E escrever um ataque automatizado em Gauntlt (e posso dizer que mais pessoas estão falando sobre Gauntlt do que escrevendo testes com ele) é muito diferente de escrever um teste bem sucedido e automatizado em JUnit, ou conduzir testes de usabilidade funcionais em Selenium ou Watir.

Assim, não devemos esperar muito de testes de segurança automatizados em DevOps. Não há tempo suficiente em uma Entrega Contínua para fazer uma varredura profunda ou mais abrangente, especialmente se você deseja implantar alguma mudança uma vez ou várias vezes por dia, e não vamos começar a cobrir todos os problemas reais a partir de alguns testes de segurança automatizados escritos em Gauntlt ou Mittn.

Mas talvez isso seja ok, porque DevOps poderia nos forçar a mudar a maneira como nós pensamos e fazemos a segurança do aplicativo, assim como o desenvolvimento Agile mudou a forma como a maioria de nós projeta e constrói aplicações.

DevOpsSec – um fator decisivo para a mudança

O desenvolvimento ágil forçou os desenvolvedores a trabalharem mais estreitamente uns com os outros e com o cliente, para compreender as necessidades e as prioridades reais e para responder a mudanças nos requisitos e prioridades. E também fez com que os desenvolvedores tivessem mais responsabilidade quanto à qualidade do código e para se certificarem de que o código realmente fez o que deveria, por meio de práticas como TDD e testes automatizados.

O DevOps está empurrando os desenvolvedores novamente, desta vez para trabalharem mais estreitamente com as operações da Infosec, para entender o que é necessário para tornar seu código seguro e resiliente, além de ter bom desempenho. E também está pressionando os desenvolvedores a assumirem a responsabilidade por fazerem seu código executar corretamente na produção:

“Você o construiu, então você tem que executá-lo”, nas palavras de Werner Vogels, CTO da Amazon.

Quando se trata de segurança, DevOps pode forçar uma mudança fundamental na forma como a segurança do aplicativo é feita hoje, a partir de “verifique-então-corrija” para algo que irá realmente funcionar: garantir a segurança desde o início, onde faz mais diferença. Mas um monte de coisas tem que mudar para que isso seja possível:

• Os desenvolvedores precisam melhorar suas habilidades em segurança de aplicativos e precisam trabalhar mais estreitamente com os Ops e com a Infosec, para que possam compreender os riscos de segurança e operacionais, e entender como lidar com eles de forma proativa. Pensar mais sobre segurança e confiabilidade em requisitos e projeto, compreender as capacidades de suas linguagens e frameworks de segurança e usá-los corretamente, escrever código mais cuidadoso e revisão de código com mais cuidado.
• Gerentes e Engenheiros de Produtos precisam dar aos desenvolvedores um tempo para aprender e construir essas habilidades, e um tempo para pensar através da concepção de fazer revisões de código adequadas.
• A Infosec precisa se ​​tornar mais interativa e mais ágil, para que possa entender mudanças, riscos e ameaças conforme os desenvolvedores adotam novas plataformas e novas tecnologias (nuvem, mobile, Internet das coisas etc.). Assim, ela pode ajudar os desenvolvedores a projetarem e escreverem ferramentas e testes modelo, em vez de prepararem listas de verificação – para fazer o que é chamado de “Segurança como Código”.

DevOps não está tornando software mais seguro, ainda não, mas poderia, se ele mudar a maneira como os desenvolvedores projetam e constroem software e também a maneira como a maioria de nós pensa sobre segurança de aplicativos.

***

Jim Bird faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://swreflections.blogspot.com.br/2015/04/can-devopssec-make-software-more-secure.html