Policy gates: trave as vulnerabilidades antes da produção

Porque é que os alertas não bastam

A maioria das ferramentas de segurança reporta depois do facto. Uma conclusão chega a um painel, alguém faz a triagem, segue um ticket para a equipa responsável e, entretanto, a versão continua a avançar. Se a conclusão passou despercebida ou se a análise nunca viu o pacote, a vulnerabilidade está em produção antes de alguém decidir o que quer que seja.

Os policy gates também podem travar um build em tempo real, antes de a versão avançar.

O que um gate pode travar

Regra	O que acontece
Conclusões no build	Um build com conclusões que a sua política exclui é bloqueado.
Uma CVE específica	Depois de a sua equipa decidir que uma CVE não pode ser distribuída, os builds que a contêm são bloqueados.
Uma versão maliciosa conhecida	Uma versão maliciosa com uma CVE publicada, como a do xz, é assinalada e pode ser bloqueada da mesma forma.
Uma licença	As regras de política de licenças podem bloquear um build que traga uma licença que excluiu.

Um gate só é tão bom quanto aquilo que vê

Um gate baseado na análise de um lockfile só consegue bloquear o que o lockfile lista. O CRACI vê o tráfego que entra em cada build, pelo que os seus gates trabalham a partir do que o job realmente obteve:

• Dependências transitivas a qualquer profundidade. Consulte dependências transitivas.
• Dependências ocultas, como código descarregado por scripts de instalação, scripts de build do Rust que fazem descargas durante o build e a imagem base de um build de contentor.
• Pacotes restaurados de uma cache de CI, que são registados e marcados como provenientes da cache.

Todos os componentes de uma SBOM do CRACI estiveram no build, pelo que um gate nunca trabalha a partir de um pacote apenas deduzido. Para o raciocínio completo, consulte SBOM geradas durante o build.

Gates e política de egress têm funções diferentes

Risco	O que o trava
Uma dependência com uma CVE conhecida que excluiu	Policy gate
Uma licença que excluiu	Policy gate
Uma ligação a um host de que o build não precisa	Política de egress, definida como negação por defeito
Um novo pacote malicioso ainda sem aviso de segurança	Não é assinalado enquanto não existir um aviso de segurança. Uma política de egress configurada com negação por defeito impede-o, ainda assim, de enviar os seus segredos para um host de que o build não precisa.

Quando surge uma nova CVE

1. O CRACI reavalia as SBOM monitorizadas e assinala o que é afetado.
2. A sua equipa de segurança faz a triagem e envia-a à equipa responsável pela correção.
3. O histórico de builds mostra que builds a continham e, por isso, durante quanto tempo esteve afetado.
4. A equipa responsável distribui a correção, e um policy gate mantém a CVE fora dos builds seguintes.

A correção continua a ser sua. O gate garante que fica corrigida. Consulte acompanhamento de vulnerabilidades.

O que os gates não fazem

• Sem análise de alcançabilidade. Um gate baseia-se em saber se um pacote está no build, não em saber se o seu código chama a função vulnerável.
• Sem deteção de malware. São os avisos de segurança que alimentam o gate, pelo que um pacote malicioso totalmente novo não é apanhado por ele.
• Sem análise de código. O SAST e a análise de segredos ficam fora do âmbito por opção, e há muitas ferramentas excelentes que funcionam a par do CRACI.

Policy gates: perguntas frequentes

O que é um policy gate?

Uma regra que trava um build quando este viola a sua política. Em vez de reportar um problema para alguém tratar mais tarde, o gate impede o build de avançar.

Em que é que um policy gate difere de um alerta de scanner?

Um alerta depende de alguém agir a tempo. Um gate atua por si só. Os gates do CRACI trabalham também a partir de um registo do que o build obteve, pelo que podem apanhar pacotes que a análise de um lockfile nunca veria.

Posso bloquear uma CVE específica?

Sim. Um policy gate pode bloquear builds que contenham uma CVE específica, para que uma vulnerabilidade sobre a qual a sua equipa já decidiu não regresse num build posterior.

Um gate pode bloquear uma licença?

Sim. Cada pacote registado traz a sua licença declarada, e as regras de política de licenças podem bloquear um build com base numa licença.

Um gate trava malware novo?

Não por si só. Uma versão maliciosa conhecida com uma CVE publicada é assinalada como qualquer outra vulnerabilidade, e um gate pode bloquear os builds que a contenham. Um novo pacote malicioso não é assinalado enquanto não existir um aviso de segurança. É uma política de egress configurada com negação por defeito que limita os danos nesse intervalo.

Que sistemas de CI funcionam com policy gates?

GitHub Actions, em runners do CRACI. Outros sistemas de CI estão no roadmap.