Skip to main content

Recapitulação da SnykCon: conte com a automação para melhorar a conformidade e obter ciclos de feedback mais rápidos

Escrito por:
wordpress-sync/Feature_Automation

13 de abril de 2022

0 minutos de leitura

A automação é um componente chave de DevSecOps porque aumenta a eficiência. Automatizar o trabalho no ciclo de vida de desenvolvimento de software ajuda a integrar várias ferramentas ao seu fluxo de trabalho, além de permitir que desenvolvedores, mantenedores e defensores da segurança se concentrem em encontrar soluções criativas para problemas difíceis, em vez de perderem tempo em tarefas manuais tediosas.

Duas das apresentações na SnykCon 2021 se concentraram na automação. Sam Hodgkinson e Ben Davies, da Citrix, detalharam como usaram a automação para simplificar o processo de aprovação de licenças de código aberto. David Wiggs, da Bain, fez uma apresentação detalhada do uso da automação para habilitar pipelines como serviço, explicando como a equipe dele integrou a segurança nos seus pipelines de CI/CD. Ambas as sessões destacaram o uso da automação para fortalecer um fluxo de trabalho de desenvolvimento.

Automação de aprovações de licenças de código aberto

Muitas pessoas conhecem software de código aberto, mas poucas sabem sobre o licenciamento de código aberto. O código-fonte aberto é escrito por desenvolvedores e está disponível gratuitamente para uso público. \_Licenças_ de código aberto distinguem como e quando você pode usar um pacote de código aberto. A automação é capaz de detectar e analisar licenças de código aberto no seu código. Isso alerta sobre as restrições de licenciamento aplicáveis a pacotes de código aberto para que você possa compará-las com suas políticas legais internas, garantindo assim que seu código esteja pronto para uso.

O desafio enfrentado

Os engenheiros da Citrix queriam uma maneira de descobrir todas as licenças de código aberto dentro de um projeto e, ao mesmo tempo, oferecer suporte aos vários gerenciadores de pacotes e linguagens utilizados em toda a organização. Também queriam controlar as compilações de CI/CD com base na conformidade das licenças e colaborar com a equipe jurídica a fim de criar políticas mais claramente definidas para todos.

Sam e Ben começaram a procurar ajuda na plataforma da Snyk. Eles estavam empenhados em criar um fluxo de trabalho contínuo e focado em recursos humanos que não gerasse pontos problemáticos para os engenheiros (ou para a equipe jurídica) e gostaram das interações simplificadas com os usuários que desenvolveram com as ferramentas da Snyk.

Em seguida, a dupla cogitou trazer todo o processo de políticas do framework jurídico para uma API automatizada, com o objetivo de tornar sua solução extensível de acordo com as necessidades futuras.

Usando os resultados fornecidos pela Snyk, Sam e Ben foram capazes de tomar decisões políticas com sua API de política e fornecer feedback prático para os desenvolvedores tomarem decisões sobre políticas que foram aprovadas ou negadas.

A solução criada

Eles criaram um pipeline de CI/CD, começando com o código-fonte que passa diretamente pela Snyk CLI. A Snyk analisa o código-fonte e retorna as informações da licença. Essas informações passam por um gate de licença que decide se deve “reprovar” uma parte do código com base no uso da licença. O código que passa pelo gate de licença é enviado a uma API de política, que responde com sim ou não (as políticas são provenientes da equipe jurídica da Citrix). Esse processo é totalmente automatizado em 90% dos casos. Outros casos podem gerar um tíquete para análise manual por alguém da equipe jurídica. No entanto, essa análise não é perdida; ela é retornada à API de política para aprovação, e o desenvolvedor pode continuar a trabalhar.

“Ao implementar a automação completa... reduzimos um processo de duas semanas e a maioria das decisões de políticas (90% delas) a poucos segundos. O que é ótimo.”

Citrix

Ben Davies

Software Engineer of Engineering Productivity, Citrix

A Citrix produziu um mecanismo de política personalizado com base em um framework jurídico complexo. A Snyk ajudou sua equipe a superar barreiras técnicas para automatizar totalmente o processo, possibilitando a segurança por todo o pipeline de CI/CD. O tempo de resolução também foi reduzido. Com um processo automatizado, a maioria das decisões de políticas ocorre em questão de segundos. Sam e Ben agora ativam as ferramentas da Snyk como parte da configuração de desenvolvimento, e a tecnologia cuida de si mesma.

Fechamento do ciclo de feedback

A introdução da segurança em um pipeline de desenvolvimento de software não é uma ideia nova, mas as pessoas geralmente se concentram na mecânica de um pipeline, e não em como o pipeline propriamente dito é usado. David Wiggs, da Bain, lançou a seguinte pergunta: os desenvolvedores estão usando o pipeline de desenvolvimento de software que você fornece e estão obtendo o que precisam dele? Pense em ferramentas de segurança e ferramentas de teste como \_produtos_ que os desenvolvedores usam. Se o seu pipeline é um produto, seus usuários (os desenvolvedores) estão tendo sucesso com ele?

Três pilares para automação

O modelo de “pipeline como serviço” começa com um repositório funcional. Em seguida, você pode introduzir um repositório de “ações personalizadas” que define de onde os pipelines recebem etapas. Você pode ter um repositório para ferramentas; um wrapper de APIs, uma ferramenta de repositório ou qualquer automação específica de ferramenta.

Esses três primeiros pilares minimizam o número de locais onde alterações são feitas e rastreadas. Quando os usuários sugerem maneiras de melhorar seu processo, você pode fazer essas alterações em um só lugar, em vez de repeti-las em vários locais.

Invocação do fluxo de trabalho

Esse layout prepara você para as seguintes etapas:

  1. O fluxo de trabalho do pipeline é acionado (pense nisso como uma "execução" do pipeline), e ocorre o check-out do repositório de ações personalizadas.

  2. O arquivo action.yml faz o check-out de um repositório específico da ferramenta de segurança.

  3. Scripts específicos da ferramenta são executados. Dessa forma, solicitações ou atualizações de recursos são feitas em um local central, e todos os usuários que consumirem uma ação personalizada herdarão a alteração.

Vamos examinar essa mesma arquitetura de pipeline de baixo para cima, começando com o repositório de ferramentas de segurança. Esse repositório pode conter scripts que definem várias funções. Por exemplo, você pode chamar um script do PowerShell que usa a API da Snyk para ver se um determinado repositório está na plataforma da Snyk. Se não estiver, ele importará esse repositório. Nesse ponto, alguns scripts estão sendo executados, e o restante da arquitetura permite que sejam herdados para um determinado repositório de trabalho.

Agora vamos subir uma camada. O repositório de ações personalizadas faz o check-out do repositório de ferramentas de segurança e executa um script específico de segurança. Com ações compostas, é possível orquestrar vários comandos em uma única etapa. Isso cria uma camada de abstração que simplifica a experiência do usuário, mas que também permite chamar vários scripts e introduzir dependências.

Isso acontece dentro do arquivo action.yml, que permite estabelecer versões sem necessariamente ter que introduzir alterações em vários repositórios de trabalho.

Na camada superior, você permite que um repositório de trabalho veja a ação personalizada do GitHub. À medida que o fluxo de trabalho no repositório de trabalho é inicializado, ele faz o check-out do repositório de ações personalizadas e traz seu conteúdo para o tempo de execução. Você fará um check-out aninhado novamente, o que permite aproveitar o arquivo action.yml e os scripts que residem no repositório de ferramentas, tudo no tempo de execução do repositório de trabalho.

“\[Integrar a segurança ao pipeline] é uma excelente maneira de retornar essas informações aos desenvolvedores, sem que eles precisem sair de suas bases centrais.”

David Wiggs

Manager, Bain

Do ponto de vista do usuário, você introduziu vários scripts personalizados de maneira “nativa” e adicionou segurança ao pipeline usando ferramentas da Snyk com ações do GitHub. Se as ações do GitHub puderem integrar ferramentas de segurança em um pipeline, os desenvolvedores não precisarão sair dos espaços de trabalho que já conhecem (GitHub) para obter informações de segurança sobre o processo de desenvolvimento. No fim das contas, você criou um loop de feedback mais rápido “nos bastidores” sem pedir aos desenvolvedores que façam alterações em vários lugares.

Exploração da automação para fluxos de trabalho melhores

A automação pode fornecer eficiência para toda a organização. Essas apresentações descrevem dois exemplos de como usar a automação a seu favor, mas há muito mais. A plataforma da Snyk fornece muitas ferramentas para incorporar a automação a fluxos de trabalho e também para integrar padrões de segurança perfeitamente a todo o processo de desenvolvimento.

wordpress-sync/Feature_Automation

Quer experimentar?

Snyk interviewed 20+ security leaders who have successfully and unsuccessfully built security champions programs. Check out this playbook to learn how to run an effective developer-focused security champions program.