Em Segurança → Configurações há o Padrão da organização e cada projeto segue essa configuração padrão. Todo projeto segue o padrão até que alguém defina sua própria configuração; Usar o padrão retorna à configuração padrão. Proprietários e administradores alteram as configurações; os membros as veem apenas como leitura.
Observar e aplicar
Cada proteção possui dois estados distintos:
- Observar: detectar, registrar e exibir. Os Achados aparecem em Segurança, e o
Coroid Securityverifica nas pull requests e os relata sem impedir a conclusão. - Aplicar: impedir a conclusão da verificação. Uma alteração que introduz um Achado com gravidade igual ou superior à definida faz com que a verificação falhe, e as tarefas do próprio Coroid não abrem uma pull request após esse ponto.
A aplicação tem três opções por escopo:
| Opção | Significado |
|---|---|
| Herdar (padrão) | Aplicar a proteção somente após a passagem pelo critério de prontidão da plataforma. |
| Aplicar | O mesmo, selecionado explicitamente para este escopo. |
| Apenas observar | Nunca impedir a conclusão da verificação, independentemente do que a plataforma fizer. |
Toda proteção começa no modo observar. O Coroid ativa a aplicação por proteção somente após ela passar pelo critério de prontidão: para dependências, os testes de cobertura e um período de observação sem bloqueios incorretos; para regras de segredos e código, o calibramento descrito abaixo e o mesmo período de observação. Até então, uma proteção configurada como Herdar ou Aplicar permanece no modo observar, e a configuração reflete isso. Após a passagem pelo critério, todas as configurações que deixaram de ser Herdar passam a aplicar; quem escolheu Apenas observar continua apenas observando.
A aplicação não equivale a "GitHub impede a fusão". O GitHub bloqueia a fusão
apenas quando o repositório exigir a verificação Coroid Security verificar. Consulte
Permissões do GitHub e a verificação de Segurança do Coroid.
Regras calibradas
As proteções contra segredos vazados e a varredura de código aplicam-se somente com versões de detetor que passaram no calibramento: precisão e recall medidos em um conjunto rotulado de código real e segredos sintéticos, taxa de bloqueios incorretos medida ao reproduzir alterações mescladas reais, cada erro reportado registrado como caso que deve continuar aprovado, e 14 dias de observação sem bloqueios incorretos.
Uma nova versão de detetor nunca assume a aplicação por conta própria. A última versão aprovada continua aplicando a proteção enquanto a nova versão observa paralelamente, e só assume a aplicação após seu próprio calibramento ser aprovado. Se nenhuma versão aprovada puder ser executada, uma proteção configurada para aplicar reportará sua indisponibilidade e a verificação falhará, em vez de ser aprovada sem verificação.
As configurações
| Proteção | Ativar | Ajustar |
|---|---|---|
| Dependências vulneráveis | Observar | Aplicação; "Aplicar em ou acima de" (padrão: alto) |
| Corrigir dependências vulneráveis | Ligado ou desligado | "Abrir tarefa de correção em ou acima de" (padrão: alto); limite de correção do pull request por projeto (padrão: 5, até 50); orçamento de horas do agente, conforme o padrão da organização |
| Segredos vazados | Observar | Aplicação. Somente no padrão da organização: bloquear novos segredos e a maior alteração analisada |
| Varredura de código | Observar | Aplicação; seu próprio comando de varredura; a lista de regras |
| Revisão de Segurança nas pull requests | Observar | Aplicação; "Aplicar em ou acima de" (padrão: alto) |
| Alertas de segurança do GitHub | Observar | Nenhum |
| Auditoria de Segurança | Ligado ou desligado | Frequência: diária, semanal (padrão) ou mensal |
Algumas proteções dependem de outras:
- Revisão de Segurança nas pull requests requer que a função Coroid Review esteja ativada no projeto no Controle de Qualidade. Se Coroid Review estiver desativado, a linha indicará isso e a proteção não terá efeito.
- Corrigir dependências vulneráveis no padrão da organização também ativa ou desativa o mandato interno de correções de Segurança. Consulte Corrigir pull requests.
- Auditoria de Segurança segue seu plano a menos que você altere: ativada nos planos pagos, desativada no plano Gratuito. Consulte Auditoria de Segurança.
A Segurança segue o que o Controle de Qualidade determinar.
As proteções da Segurança não dependem dos controles do Controle de Qualidade. Desativar o anti-slop no Controle de Qualidade desativa suas regras de qualidade, mas não as regras de código da Segurança. Nos pull requests, Coroid Security publica sua própria verificação, independentemente de o projeto ter um gráfico de Entrega publicado ou não.
A configuração do Scanner vem de Coroid
Os Scanners rodam com a configuração Coroid construída a partir dessas definições e das exceções aceitas na Segurança, nunca a partir de arquivos na alteração em teste. Uma alteração que adiciona ou edita a configuração do scanner (osv-scanner.toml,
.gitleaks.toml, .gitleaksignore, .github/secret_scanning.yml,
.secrets.baseline e similares) é verificada com base na configuração do commit base e recebe um security.policy-changed resultado de detecção. Um arquivo do repositório pode propor uma exceção; ela só entra em vigor após ser aceita por um proprietário ou administrador na Segurança. A mesma regra se aplica às tarefas de correção próprias do Coroid: um agente não pode fazer com que sua própria verificação seja aprovada alterando o que está excluído.
As Configurações acompanham a organização.
As security configurações fazem parte do conjunto de configurações da organização, juntamente com as outras políticas de qualidade, assim como o modelo de ameaças mais recente de cada projeto. Exceções, resultados de detecção e evidências são resultados, não configurações, e não são transferidos. Consulte Portabilidade de configurações.