Duas proteções analisam o próprio código: Varredura de código executa regras fixas em cada alteração e no branch padrão, e Revisão de segurança em pull requests verifica os problemas de segurança identificados pela Coroid Review antes que algum deles possa fazer com que um pull request seja reprovado.
Varredura de código
Regras do Coroid
O time de Segurança é responsável por essas regras. Elas faziam parte das regras anti-slop no Controle de Qualidade e agora estão aqui, portanto cada uma tem seu local específico:
| Regra | Procura por |
|---|---|
security.hardcoded-secret | Credenciais escritas no código. Veja Segredos vazados. |
security.tls-disabled | Verificação de certificado TLS desativada. |
security.auth-removed | Guards de autenticação ou permissão, decorators ou middleware removidos ou comentados. |
security.cors-wildcard-credentials | Qualquer origem permitida junto com credenciais. |
security.sql-concat | SQL construído a partir de strings interpoladas e passado para uma função de consulta. |
security.eval | Código executado a partir de entrada: eval, new Function, não sanitizado dangerouslySetInnerHTML. |
security.remote-script-exec | Scripts baixados sendo enviados diretamente para um shell ou interpretador. |
security.policy-changed | Alterações na configuração do scanner. Veja Proteções e aplicação de regras. |
deps.nonexistent | Novas dependências que não existem em seu registro. |
deps.known-malicious | Novas dependências com aviso de pacote malicioso. |
deps.suspicious-new | Novas dependências publicadas há menos de 30 dias, com pouquíssimos downloads, nome semelhante a um pacote popular em uma ou duas letras, ou com mudança recente de mantenedor. |
deps.install-script | Novas dependências npm que executam um script ao serem instaladas. |
As regras de higiene de dependências, versões não fixadas e divergência entre manifest e lockfile permanecem no Controle de Qualidade como parte das regras anti-slop. Veja Anti-slop.
As regras são executadas em alterações, na mesma varredura que a verificação anti-slop do Controle de Qualidade, e no branch padrão a cada push e uma vez por dia, independentemente de a anti-slop estar ativada. O time de Segurança, e não as configurações da anti-slop, decide a ação de cada regra. Segurança → Configurações → Varredura de código lista todas elas. Até que a varredura de código passe a ser aplicada, cada regra mantém a ação que tinha no Controle de Qualidade; assim, uma regra configurada para bloquear continuará bloqueando.
Seu próprio comando de varredura
Se seu projeto já possui um scanner de segurança, insira seu comando em
Seu próprio comando de varredura na seção Varredura de código. Ele é executado como
security_scan verificação em cada alteração. Deixe esse campo vazio para desativá-lo.
Resultados de ferramentas externas como SonarQube, Snyk ou Semgrep também podem chegar ao Coroid como evidências de revisão. Veja Provedores de evidências de revisão.
Revisão de segurança em pull requests
A Coroid Review analisa pull requests no Controle de Qualidade. Quando identifica um problema de segurança, não o inclui na revisão como texto livre. Em vez disso, reporta o problema como uma reivindicação estruturada: tipo de vulnerabilidade, arquivo e linhas afetadas, e gravidade. O time de Segurança registra cada reivindicação como Ainda não confirmado.
A verificação independente
Para reivindicações críticas e de alta gravidade, o Coroid realiza uma verificação independente: um modelo separado e limitado que analisa o arquivo mencionado na reivindicação, no commit principal do pull request, e precisa identificar o problema por conta própria. Se conseguir, a reivindicação se torna uma descoberta estática validada. Se o código que determina o problema estiver em outro arquivo, a verificação não consegue confirmá-la e a reivindicação permanece sem confirmação.
Essa verificação consome créditos da sua organização como qualquer outro trabalho de modelo, dentro de limites fixos definidos pelo pull request. Quando os créditos ou horas são esgotados, ela não é executada e a revisão indica: "Um possível problema de segurança não pôde ser verificado: os créditos ou horas da organização foram esgotados."
O que faz com que a revisão seja reprovada
| Observar | Aplicar | |
|---|---|---|
| Uma reivindicação confirmada igual ou superior ao limite (alta por padrão) | Neutro, "DESCOBERTA CONFIRMADA" | A verificação da Coroid Review falha, "DESCOBERTA CONFIRMADA" |
| Uma reivindicação que não foi confirmada | Nunca falha | Nunca falha |
Uma reivindicação crítica ou de alta gravidade, confirmada e com aplicação de regra, faz com que a Coroid Review seja reprovada mesmo quando a revisão está configurada como consultiva no Controle de Qualidade. Essa é a única exceção à regra de que revisões consultivas nunca falham. Uma revisão que solicita alterações apenas devido a reivindicações de segurança não confirmadas é considerada consultiva.
A revisão de segurança requer que a Coroid Review esteja ativada para o projeto. Quando a Coroid Review está desativada, essa informação aparece na linha correspondente em Segurança → Configurações.
O que chega ao GitHub
Antes que qualquer texto de revisão, comentário ou verificação chegue ao GitHub, ele passa pela porta de publicação. Em um repositório público, ou em um cuja visibilidade o Coroid não consegue confirmar, uma questão de segurança que ainda não é pública é substituída por "O Coroid identificou uma possível questão de segurança; os detalhes estão em Coroid", com um link. Veja Divulgação.