Use as políticas de segurança da Snyk para priorizar correções com mais eficiência

As políticas de segurança da Snyk ficaram muito mais poderosas: agora contam com uma nova ação e duas novas condições para ajudar as equipes de desenvolvimento e segurança a avaliar riscos e direcionar recursos com mais eficiência.

Para quem desenvolve, quanto menos “ruído”, melhor. Ter que corrigir problemas que simplesmente não são importantes nem relevantes desperdiça um tempo valioso de desenvolvimento e provavelmente gera frustração e desconfiança. Com certeza, isso não ajuda os desenvolvedores a assumir mais responsabilidade e protagonismo pela segurança na organização.

As políticas de segurança ajudam a priorizar os problemas que precisam ser resolvidos e a ignorar por completo aqueles que podem esperar até que os mais críticos sejam corrigidos. Aplicadas em diferentes etapas do SDLC, as políticas também podem evitar que componentes vulneráveis ou fora de conformidade passem despercebidos. Elas são parte integrante da estrutura de governança da organização e seguem os padrões de segurança e conformidade aceitos internamente.

O mecanismo de regras aprimorado das políticas de segurança da Snyk inclui uma nova ação, Ignorar, e novas condições (CVE e ID da Snyk). Com isso, você ganha mais flexibilidade e granularidade na governança e pode adotar estratégias de priorização mais eficazes em toda a organização.

Ignore vulnerabilidades em massa

Uma política de segurança da Snyk contém uma regra ou um conjunto de regras que define exatamente como as vulnerabilidades de segurança devem ser tratadas. As regras acionam ações com base em uma condição ou em um conjunto de condições. Até agora, essas regras permitiam uma única ação: ajustar a gravidade das vulnerabilidades. Com base no CWE de uma vulnerabilidade e/ou na existência de uma exploração, os usuários podiam alterar seu nível de gravidade.

Agora você também pode ignorar completamente vulnerabilidades específicas. Isso pode ser feito com base nas condições já disponíveis e nas duas novas condições que acabamos de incluir: CVE e ID da Snyk. Esse recurso pode ajudar você a reduzir o backlog de vulnerabilidades de várias maneiras.

Por exemplo, você pode configurar uma política de segurança para ignorar vulnerabilidades sem uma exploração conhecida:

Com a nova condição CVE combinada com os atributos do projeto, você também pode ignorar uma vulnerabilidade específica que sabe não ser relevante para determinados tipos de aplicação:

Também é possível ignorar uma categoria inteira de vulnerabilidades usando a condição CWE:

Gerenciamento granular de políticas

Os projetos são diferentes entre si e provavelmente exigem limites distintos de segurança e conformidade. Por exemplo, um projeto essencial para os negócios precisa de um controle mais rigoroso do que um projeto interno, isolado em um ambiente de desenvolvimento e testes.

A Snyk oferece a granularidade necessária para decidir exatamente como aplicar políticas na organização. Elas podem ser aplicadas a um projeto ou a um grupo de projetos usando tags e atributos do projeto — dois tipos de metadados que podem ser adicionados aos projetos manualmente ou automaticamente pela API da Snyk, permitindo agrupá-los por características em comum. Outra opção é aplicar políticas a organizações específicas dentro de um grupo da Snyk (consulte nossa documentação para saber mais sobre as hierarquias de grupos, organizações e projetos da Snyk).

Vamos ver um exemplo, desta vez usando as políticas de licenças da Snyk.

A equipe jurídica da organização X concluiu que é necessário impor limites de conformidade extremamente rigorosos a todos os serviços de frontend essenciais para os negócios em produção. Por outro lado, ela não está tão preocupada com a conformidade de projetos internos ainda em desenvolvimento.

Como primeiro passo, a organização X garante que os atributos Critical, Production e Frontend sejam adicionados aos projetos relevantes na Snyk.

Em seguida, como segundo passo, uma nova política de licenças é criada. Com os atributos recém-adicionados, a política é atribuída aos projetos relevantes. Na própria política, é possível definir gravidade alta para qualquer licença copyleft identificada nos projetos, como as licenças GPL-3.0 e AGPL-3.0.

Aplicação em todo o SDLC

Depois de criadas, as políticas de segurança e licenças da Snyk são aplicadas a todos os projetos relevantes e cumpridas nas diferentes etapas do SDLC. Isso começa já no ambiente de desenvolvimento local, no IDE ou na CLI, passa pelos fluxos de trabalho baseados em Git e pelo CI/CD e segue até a produção. Esses vários pontos de controle de segurança e conformidade garantem que os problemas sejam identificados o quanto antes no processo de desenvolvimento, quando corrigi-los custa menos tempo e esforço.

Por exemplo, nos projetos do GitHub monitorados pela Snyk, toda nova solicitação de pull criada por um desenvolvedor colaborador é verificada em relação às políticas de segurança e licenças atribuídas ao projeto. Assim, códigos vulneráveis ou fora de conformidade não podem ser enviados ao repositório, sempre de acordo com os padrões internos da organização.

No exemplo abaixo, estou tentando adicionar o pacote fullpage.js para incluir rolagem em tela cheia na minha aplicação JavaScript. Embora passe na verificação de segurança (a versão mais recente do pacote não tem vulnerabilidades conhecidas), ele não passa na verificação de licença por incluir a licença GPLv3, que viola nossa política de licenças.

Ao clicar no link Detalhes, você encontra mais informações e contexto sobre o teste reprovado:

Da mesma forma, as políticas entram em vigor no CI/CD para garantir que os builds estejam em conformidade com os limites de segurança e conformidade. No exemplo abaixo, um fluxo de trabalho de build do GitHub Actions falhou porque os testes da Snyk identificaram uma vulnerabilidade de alta gravidade.

Segurança e velocidade não são incompatíveis

Na segurança de aplicações, as políticas têm o papel fundamental de equilibrar o desenvolvimento rápido com a segurança. Esse equilíbrio varia de uma organização para outra, mas, quando implementadas corretamente, as políticas garantem que as equipes de desenvolvimento e segurança atuem dentro dos limites de segurança e conformidade aceitos pela organização, sem deixar de maximizar a produtividade.

Mas, para isso, as políticas precisam…

• ser flexíveis o bastante para permitir regras granulares e sua aplicação em toda a organização

• complementar os processos e fluxos de trabalho de desenvolvimento, sem criar obstáculos

• permitir priorizar problemas com eficiência para maximizar a segurança e a produtividade

• oferecer visibilidade clara às pessoas ou equipes responsáveis pelo gerenciamento sobre quais regras estão sendo aplicadas e onde

• contar com governança adequada para serem gerenciadas de forma centralizada e garantir a conformidade.

Esses são recursos essenciais das políticas da Snyk. Para saber mais sobre as políticas da Snyk e como usá-las, consulte nossa documentação técnica.