Para discutir como a equipe Fail Fast alcança DevSecOps bem-sucedidos, vamos examinar o papel da segurança nos métodos modernos de desenvolvimento de software. Muitas empresas, como nossas fictícias Fail Fast Technologies, estão atualmente desenvolvendo software moderno usando processos DevOps ou procurando adotá-lo, então vamos esclarecer o que é DevOps.
O que é DevOps?
DevOps é uma cultura; é uma maneira de ver o ciclo de vida de desenvolvimento de software como uma conversa contínua entre as equipes. O DevOps só funciona se as equipes puderem quebrar silos e colaborar – enquanto ainda mantêm a integridade de sua função específica.
DevOps é uma filosofia que usa um conjunto de práticas combinadas para integrar o desenvolvimento de software e as operações de TI. O DevOps complementa o desenvolvimento ágil de software, promovendo um loop de feedback contínuo e dividindo o trabalho e o risco associado. Um dos melhores aspectos do DevOps é que você normalmente automatiza toda a construção de ambientes a partir do zero. Você constrói o aplicativo, constrói o host em que ele ficará e o implanta consistentemente no host.
Agora, vamos investigar as funções específicas que permitem a automação. A natureza integrada do DevOps é melhor vista como um loop contínuo. Cada atividade dentro do loop mapeia para um princípio correspondente. Cada etapa ou função fundamental se mistura com as outras, atraindo profissionais em todas as equipes, desde a codificação e teste até o lançamento e implantação e, finalmente, até a operação e monitoramento, com o ciclo se repetindo infinitamente.
Simplificando a estrutura DevOps
Integração Contínua
Começando no canto superior esquerdo do loop DevOps é a Integração Contínua como parte do “Código” e parcialmente a função “Construir”. Aqui estamos pegando as peças minimamente complexas do sistema e nos certificando de que todas elas ainda sejam construídas e passando por outros testes para garantir que todas as funções de coleta estejam de acordo com as especificações. Muitos desenvolvedores podem estar escrevendo código para diferentes aplicativos ou APIs no mesmo sistema, e todo esse código deve “integrar” preservando a integridade básica de toda a coleção de componentes. Se algum componente falhar em um teste, sabemos que é provável que o sistema falhe e não devemos implantá-lo.
Deployment Contínuo
A Implantação Contínua (às vezes chamada de Entrega Contínua) leva a saída da etapa de Integração Contínua e lhe dá um lugar para viver (essas duas etapas são frequentemente agrupadas e referidas como CI/CD). Esta etapa implanta ambientes consistentes que fornecem um ambiente de execução ao vivo para o sistema funcional. O ambiente pode ser referenciado como o código que foi escrito para implantá-lo e depurado como um sistema.
Teste/Validacão Contínua
Esta etapa da prática DevOps envolve testar o código para determinar como ele se comportará em um ambiente de produção. Aqui, os testes podem ser medidos em relação a um conjunto de métricas objetivas determinadas com antecedência por todas as equipes envolvidas no esforço de DevOps. Essas métricas qualificam que o aplicativo está pronto para os usuários finais. Testes de carga, testes funcionais, testes de regressão e testes de segurança são exemplos de testes que validam um aplicativo como pronto para produção. Este é o último lugar para resolver problemas de desempenho ou segurança.
Monitoramento Contínuo
As atividades associadas ao Monitoramento são geralmente lideradas pelo lado “Ops” da colaboração DevOps. Rede, sistemas, aplicativos, ameaças a qualquer parte da superfície de ataque de uma organização e vulnerabilidades que surgem ao longo do tempo são monitoradas em todos os aplicativos e APIs em produção. O monitoramento destina-se a fornecer feedback que pode ser acionável e resultar na priorização de desenvolvimento do referido feedback – a integração do feedback nos traz do lado direito do loop para o planejamento, codificação e construção.
Principais benefícios do DevSecOps
A pedra angular de uma prática bem-sucedida de DevOps é a automação; é por isso que a adoção de DevSecOps (segurança automatizada em fluxos de trabalho) faz tanto sentido. O DevSecOps está cercando cada etapa do processo DevOps e praticando com segurança. Ao adicionar segurança a cada etapa do ciclo de vida de desenvolvimento de software (SDLC), desde a codificação e construção até a operação e monitoramento da conformidade com a política – bases de código, aplicativos e APIs são projetados, construídos e implantados com a segurança em mente. A integração da segurança em cada função DevOps cria efetivamente o DevSecOps – uma camada abrangente que cobre toda a atividade ao longo do SDLC.
Os benefícios do DevSecOps incluem a sobreposição de segurança a cada etapa, para que não se torne uma reflexão tardia em silos e apenas o último “obriço” a ser superado antes que um aplicativo seja implantado. Praticamente falando, isso significa aplicar ativamente a segurança em cada etapa do SDLC – ensinando os desenvolvedores a detectar falhas de código cedo, ajudando os desenvolvedores a escolher bibliotecas de terceiros que não introduzem vulnerabilidades, definindo o significado de “feito” e continuando a mudar para a direita e para a esquerda ao monitorar superfícies de ataque. Por que integrar os testes de segurança tão firmemente no processo DevOps? Isso permite que as equipes peguem alvos de ataque em potencial no início, onde eles são muito menos caros e cansativos de consertar. Por exemplo, a pesquisa1 mostra que os usuários de treinamento prático de segurança do desenvolvedor que concluíram pelo menos uma lição levaram 110 dias para corrigir 50% das falhas – enquanto aqueles que não tiveram esse treinamento levaram 170 dias. Isso é uma diferença de dois meses! A questão é que a implementação bem-sucedida do DevSecOps é um dos problemas mais difíceis de resolver devido a uma variedade de fatores. A adoção cultural é um dos maiores bloqueadores para mudar para a esquerda e otimizar a avaliação e o teste da “direita” da superfície de ataque. Agora voltaremos à nossa história de Fail Fast Technologies e veremos quais medidas eles tomaram para incorporar com sucesso a segurança ao DevOps para criar DevSecOps.
Passos práticos para implantar DevSecOps
Embora o Fail Fast já estivesse implementando o DevOps, eles precisavam automatizar holisticamente a segurança em seu processo para adotar com sucesso o DevSecOps e evitar enfrentar outra crise como a injeção SQL.
Estabeleça e difunda os padrões pela organização
A equipe Fail Fast começou estabelecendo um vernáculo comum: concordar com definições de termos para significar o mesmo para todos em ambas as equipes. Isso eliminou a confusão e ajudou cada membro da equipe a entender melhor quais eram seus requisitos antes de mover seu código para outra parte do ciclo de vida de desenvolvimento de software.
CWE vs CVE Mesmo que as equipes tenham ouvido esses termos antes, algumas delas não estavam 100% claras sobre o que queriam dizer e, em alguns casos, estavam confundindo-as. Era importante que as equipes entendessem a diferença, porque isso ajudaria a configurá-las para o sucesso, sabendo como tratar cada uma de forma diferente no contexto de suas aplicações. CWE. “Common Weakness Enumeration (CWE™) é uma lista desenvolvida pela comunidade de tipos comuns de fraqueza de software e hardware que têm ramificações de segurança”, afirma seu site. Essas fraquezas não se aplicam apenas ao software, mas também se aplicam ao design e à arquitetura. Existem milhares de CWEs, mas as compilações mais reconhecíveis de falhas de segurança são as 25 principais do SANS, que representam as 25 CWEs mais comuns que afetam especificamente o software. Há também o Open Worldwide Application Security Project® (OWASP) Top 10, que se aplica mais diretamente a aplicativos da web. Um exemplo de um CWE é o CWE 89, ou injeção SQL, que pode levar ao acesso/manipulação direta do banco de dados SQL subjacente que não foi pretendido através do propósito projetado do aplicativo original – uma fraqueza com a qual a equipe Fail Fast infelizmente estava muito familiarizada. Os CWEs dão às equipes uma linguagem comum sobre falhas de segurança e quais são essas falhas para ajudá-las a priorizar onde os desenvolvedores precisam de mais treinamento e orientação, bem como o que corrigir.
CVE. CVE significa Vulnerabilidades e Exposição Comuns. Assim como os CWEs, os CVEs são organizados de uma maneira que permite que as equipes falem o mesmo idioma. O esforço da Tecnologia (NIST) para manter um banco de dados de problemas de segurança divulgados publicamente. Fornecedores da AppSec, como a Veracode, começaram a construir seus próprios bancos de dados proprietários para aumentar o banco de dados do NIST. Um CVE é um número de identificação que começa com o ano em que a vulnerabilidade foi descoberta, seguido por uma série de números que a identificam exclusivamente. Os CVEs são então pontuados de baixo a alto (0-10) para gravidade. Um CVE indica um problema específico associado a uma determinada biblioteca e número de versão. Os CVEs só podem ser emitidos por uma autoridade certificada, e há um processo demorado de relatório e prova de conceito que deve ser seguido para que uma vulnerabilidade seja “oficial” o suficiente para justificar um número CVE. CVEs são vulnerabilidades reais e demonstráveis.
Incorporar segurança ao ciclo de vida de desenvolvimento de software
Com as equipes da Fail Fast usando as mesmas palavras para descrever seu trabalho, elas estavam prontas para automatizar as tarefas que, em última análise, reduziriam a dívida de segurança e reduziriam a probabilidade de adicionar novas falhas.
Criamos as seis etapas a seguir para proteger o SDLC com base nos aprendizados de quase duas décadas ajudando as equipes a alcançar e manter programas de segurança de aplicativos. Observe que as etapas podem não acontecer na mesma ordem para todos, mas formam os seis elementos essenciais que vemos uma e outra vez. Para aprender sobre eles com mais detalhes, leia os 6 Passos da Veracode para Proteger o eBook SDLC.
1. Descubra fontes de risco e o que priorizar
O primeiro elemento-chave para proteger seu SDLC é descobrir e inventariar seu portfólio de aplicativos para entender as fontes de risco e o que você deseja priorizar. Quantas inscrições você tem? Onde eles residem? Quem é o dono deles? Eles ainda estão por perto? Quais são as suas dependências de código aberto? Fail Fast percebeu que eles não podiam garantir o que não podiam ver, e que um inventário abrangente de sua superfície de ataque era crítico. Seu primeiro passo foi entender quais aplicativos eles tinham, o que estava nesses aplicativos e quais sistemas suas equipes usavam. Eles estavam lutando para identificar todas as aplicações, dependências e sistemas, e sentiram que estavam fervendo o oceano. Eles decidiram se concentrar primeiro apenas nos aplicativos que já haviam inventariado – sabendo que sempre poderiam repetir a partir daí.
2 Aplicativos integrados com uma varredura inicial para estabelecer uma linha de base e ganhar visibilidade
Depois que o Fail Fast teve uma compreensão e mapeamento bons o suficientes dos aplicativos, bibliotecas e artefatos que compunham seu portfólio e processo de desenvolvimento de software, eles integraram aplicativos com uma varredura inicial para estabelecer uma linha de base e visibilidade. Eles conseguiram digitalizar rapidamente milhares de aplicativos usando a plataforma de nuvem da Veracode. Eles tiveram um instantâneo inicial de possíveis problemas no código que escreveram internamente e em seus componentes de terceiros. Eles entenderam o que estava nos aplicativos que tinham e decidiram como automatizar o uso de mecanismos de digitalização daqui para frente. Um dos problemas que o Fail Fast encontrou foi ter uma pessoa de segurança executando testes e, ao mesmo tempo, descobrir como fazer a triagem e abordar os resultados desses testes. Todo mundo tem um papel a desempenhar no DevSecOps. Eles identificaram desenvolvedores líderes, scrum masters e leads DevOps e os informaram exatamente quais testes executar, quando executá-los e como automatizar os testes.
3 Defina e atribua políticas de segurança Para aplicativos
A Política define expectativas e regras claras com as quais os aplicativos devem estar em conformidade. No Fail Fast, a política não era clara, então o cumprimento também não era. Eles devem reunir as equipes de segurança e desenvolvimento, incluindo o nível do conselho, em torno de uma política comum baseada em tolerância ao risco, processos de DevOps, maturidade, capacidade da equipe e muito mais. A qualificação da tolerância ao risco e a definição da política são extremamente complexas. A Fail Fast não tinha ninguém em sua equipe com bastante o conjunto de habilidades para fazer isso, então eles confiaram nos Consultores de Segurança de Aplicativos da Veracode para resolver facilmente esse problema sem ter que esperar que o processo de contratação fizesse seu curso. O Fail Fast começou com as recomendações de políticas de segurança internas da Veracode para aplicativos baseados na criticidade de negócios; eles planejavam adaptá-los mais tarde e restringir as descobertas por gravidade, categoria CWE, ID CWE, risco de licença, pontuação do Common Vulnerability Scoring System (CVSS) ou um padrão comum, como OWASP, OWASP Mobile, CWE Top 25 ou Precast/Prestressed Concrete Institute Security Standards Council (PCISSSC).
4 Triagem e endereço de descobertas nos fluxos de trabalho do desenvolvedor
Quando o Fail Fast bordou aplicativos, eles encontraram milhares de falhas que haviam se acumulado em sua base de código como dívida de segurança. Eles precisavam de um plano de como fazer com que todos os seus aplicativos integrados passassem por sua nova política. Eles precisavam priorizar o tempo do desenvolvedor em esforços de alto impacto para trazer aplicativos legados para conformidade e implantar com sucesso novos aplicativos com segurança em produção. Ao encontrar uma falha que viole a política, as equipes processariam e resolveriam essa descoberta por meio de remediação ou mitigação.
E a triagem aconteceu simultaneamente em novas compilações), o Fail Fast criou métricas simplificadas em incrementos de 30, 60 e 180 dias através dos quais eles rastrearam aplicativos em escopo ou descobertos, integrados, compatíveis e resilientes (aplicativos construídos com segurança construídos proativamente desde o início).
5 Aproveite os relatórios para medir, gerenciar e melhorar os resultados
As métricas simplificadas usadas na Etapa 4 foram um ótimo ponto de partida para medir o sucesso, mas O conselho queria mais informações. Fail Fast sabia que fazer as perguntas certas resultou na medição das coisas certas. Eles começaram com perguntas como: Quantas falhas temos? Com que rapidez estamos consertando eles? Quem está enviando o código mais seguro/arriscado? Como nos comparamos com organizações semelhantes no setor? Fail Fast precisava de relatórios disponíveis sob demanda para que os líderes e equipes pudessem ver o status e a saúde em tempo real do programa de segurança do aplicativo. Dessa forma, eles poderiam estabelecer uma linha de base, identificar áreas para melhoria, definir metas quantitativas e acompanhar o progresso em relação a essas metas. Além de medir, gerenciar e monitorar a saúde de seu programa de segurança de aplicativos, seus relatórios também precisavam satisfazer as demandas de seu conselho e reguladores, fornecer garantia de segurança aos clientes e permitir que as equipes de entrada no mercado demonstrassem e alavancassem a segurança como uma vantagem competitiva no mercado. Usando a análise robusta da Veracode – incluindo benchmarking patenteado por pares e o relatório State of Software Security com informações sobre as tendências macro entre os clientes da Veracode – eles identificaram pontos fortes e fracos, analisaram o desempenho de falhas e remediação e priorizaram atividades de alto valor visando metas específicas de segurança de aplicativos.
6 Evite falhas de segurança por meio de educação e controles técnicos no processo CI/CD
Com grande parte da automação em andamento, o Fail Fast começou a trabalhar em maneiras de evitar que falhas de segurança insiram código em primeiro lugar. Eles reuniram equipes de segurança e desenvolvimento para concordar com mecanismos e controles que impedem que falhas de segurança em código primário, bibliotecas compartilhadas, componentes de terceiros e dependências de código aberto cheguem à produção. Este foi o início da promoção de uma cultura de codificação segura. Por meio de controles técnicos no processo CI/CD, eles estabeleceram um loop de feedback contínuo que monitora a conformidade com as políticas e garante que, se o código se desviar da política – ou se novas falhas forem criadas – as equipes sejam alertadas e as violações sejam abordadas. Além de estabelecer controles preventivos no pipeline, eles alavancaram os relatórios para rastrear a natureza dos problemas que estão sendo introduzidos e identificar lacunas de habilidades. Essas informações foram usadas para projetar programas de segurança e currículos de treinamento para direcionar áreas de preocupação. Eles também forneceram aos desenvolvedores ferramentas de remediação contextuais – e inteligentes – para ajudá-los a desenvolver
Por exemplo, eles notaram um certo CWE fazendo com que muitos aplicativos violassem a política, e lideraram um esforço de queima de CWE para se concentrar nessas descobertas. Em outro caso, uma equipe estava lutando para corrigir uma certa categoria de falha dentro do período de carência, então eles projetaram um currículo de treinamento de segurança que forneceu à equipe experiência prática na correção de código em aplicativos de amostra.
Software que é seguro desde o início. Com todas as demandas e preocupações concorrentes que os desenvolvedores enfrentam, soluções de segurança inteligentes que permitem que os desenvolvedores implementem uma alteração de código ou atualizem uma biblioteca vulnerável com uma solicitação de pull os libertam de grande parte do tempo e do esforço de corrigir manualmente falhas.
Em Resumo Embora a história da Fail Fast Technologies possa estar relacionada a muitas organizações, todas as jornadas para a maturidade da segurança de aplicativos são diferentes. Diferentes organizações têm necessidades e prioridades diferentes. Alguns precisam lidar com a dívida de segurança aparentemente intransponível em sua base de código legado. Outros priorizam o desenvolvimento rápido e seguro de aplicativos nativos da nuvem. Independentemente da jornada, o caminho para a maturidade converge em torno dos objetivos principais: visibilidade total do portfólio de aplicativos com varreduras automatizadas regulares; todos os aplicativos em conformidade com uma política de segurança bem definida; e a prevenção de novas falhas de chegar à produção.
Conclusão
DevSecOps não é um destino; é uma jornada. Não um estado a ser alcançado, mas um processo a ser promulgado e mantido. Você deve integrar e reintegrar a segurança e se adaptar continuamente para permanecer difundido (mas não invasivo) à medida que as necessidades de desenvolvimento e ferramentas mudam. Não importa a sua jornada, a Veracode apoia você a cada passo do caminho. A Plataforma de Segurança de Software Contínuo Veracode permite que você estabeleça segurança abrangente em torno de seus aplicativos legados e nativos da nuvem. Apoiamos você na integração perfeita da segurança em todo o seu SDLC, reunindo segurança e desenvolvimento e fornecendo um veículo para definir e implementar um conjunto de políticas de segurança que se alinham à criticidade de negócios e ao ambiente operacional do software em produção. Com as soluções, suporte e serviços da Veracode, você pode evitar e superar os desafios de proteger seu software do início ao fim.
