Política de segurança, como código.
Escreve o teu nível de segurança uma vez e cada análise, equipa e pipeline cumpre-o.
policy.yamlOrganizaçãoAplicada
- BloquearDescobertas SAST críticas
- BloquearInjeção de SQL num branch protegido
- AvisarCVSS 7.0 ou mais
- ExcluídoRelatórios legacy, risco aceite
Escrita uma vez. Aplicada em cada merge.
policy.yamlavaliado em cada análise
name: Block Critical Vulnerabilitiesscope: ORGANIZATIONpriority: 50enabled: truerules: - name: Block Critical SAST Findings action: block criteria: - scanner_type eq SAST - severity eq CRITICALDefine as regras uma vez, herdadas em todo o lado.
A linha de base da tua organização chega a todas as equipas e projetos. Um projeto pode torná-la mais rigorosa, nunca mais branda.
AcmeOrganização
Block Critical Vulnerabilitiesseverity eq CRITICAL → block- PaymentsEquipaherdada
payments-apiherdadacheckout-webherdada+ severity eq HIGH → blockmais rigorosa, nunca mais branda
- PlatformEquipaherdada
infraherdadadocs-siteherdada
Começa por um repositório.
Liga o GitHub, o GitLab, o Bitbucket ou o Azure DevOps, escolhe um repositório e a primeira análise arranca.
Em detalhe
O que uma regra pode dizer
Escreve a regra. Bloqueia o merge. Regista a exceção.
10 tipos de regra, 8 operadores, lógica AND / OR. De um simples limiar CVSS a um CWE específico num branch protegido.
policy.yamlOrganizaçãoAplicada
- BloquearDescobertas SAST críticasscanner_type eq SASTAND severity eq CRITICAL
- BloquearInjeção de SQL num branch protegidoCWE-89AND main
- AvisarCVSS 7.0 ou maisCVSS 4.0
- ExcluídoRelatórios legacy, risco aceitelegacy/reports/**2026-12-31
10 tipos de regra, 8 operadores, lógica AND / OR. De um simples limiar CVSS a um CWE específico num branch protegido.
Gestão de políticas, em resumo
O que é a política de segurança como código?
Os teus requisitos de segurança vivem em YAML versionado, ao lado do teu código. A CybeDefend avalia a política em vigor em cada análise de SAST, SCA, segredos, contentores, IaC e CI/CD, para que as regras acompanhem o repositório.
Qual é a diferença entre bloquear e alertar?
Bloquear interrompe a pipeline e regista a violação. Alertar regista-a e deixa a pipeline continuar, a forma segura de introduzir uma nova regra antes de a tornar obrigatória.
Como funciona a hierarquia de organização, equipa e projeto?
As políticas propagam-se de cima para baixo. A organização define uma linha de base que as equipas e os projetos herdam e só podem tornar mais rigorosa, por isso nenhuma diretriz da empresa é anulada em silêncio.
A avaliação de políticas torna a minha pipeline mais lenta?
Não. As políticas são avaliadas de forma assíncrona, com um tempo limite configurável, por isso a barreira nunca atrasa as análises nem os deploys.
Posso criar uma exceção para um ficheiro ou um risco aceite?
Sim. Cada política suporta exclusões por padrão glob, com âmbito definido e datas de expiração opcionais, e podes marcar uma descoberta como risco aceite, com uma justificação. Ambas deixam registo de auditoria.