O módulo Segurança mantém um inventário de todos os pacotes instalados por cada projeto e os compara com os avisos publicados, de modo que uma versão vulnerável seja detectada quando chegar a um pull request, e novamente quando um novo aviso identificar uma versão já em uso.
O inventário
A cada nova referência da branch padrão e pelo menos uma vez por dia, o Coroid lê os arquivos de bloqueio do projeto com OSV-Scanner, vinculado a uma versão específica e verificado contra seu checksum publicado. O scanner recebe apenas os arquivos de dependências, uma configuração gerada pelo Coroid, sem acesso à rede ou credenciais. O próprio osv-scanner.toml não tem efeito.
Segurança → Dependências exibe o inventário de cada projeto: os pacotes e suas versões instaladas, qual manifesto declara cada um, quais são vulneráveis, a cobertura de cada arquivo e quando os dados do aviso foram lidos pela última vez. Exportar CycloneDX baixa o inventário como um arquivo CycloneDX 1.5. Ele lista apenas as vulnerabilidades para descobertas que já são públicas. Veja Divulgação.
O que o Coroid lê integralmente
A cobertura é por arquivo de bloqueio, não por repositório. Em um monorepo, cada arquivo de bloqueio forma um grupo próprio com sua cobertura individual; portanto, os resultados de um arquivo de bloqueio completo permanecem válidos mesmo quando outro manifesto estiver parcial.
| Arquivo | Ecossistema | Versões exatas | Dependências transitivas completas | Cobertura |
|---|---|---|---|---|
package-lock.json | npm | Sim | Sim | Completo |
npm-shrinkwrap.json | npm | Sim | Sim | Completo |
pnpm-lock.yaml | npm | Sim | Sim | Completo |
yarn.lock | npm | Sim | Sim | Completo |
requirements.txt | PyPI | Sim | Não | Parcial |
go.mod | Go | Sim | Não | Parcial |
Esta tabela é gerada a partir dos fixtures dos próprios testes do Coroid executados pelo scanner; portanto, só muda quando os testes forem atualizados.
- Espaços de trabalho npm, pnpm e Yarn: um
package.jsonsem seu próprio arquivo de bloqueio é coberto pelo arquivo de bloqueio raiz. Umpackage.jsonque não corresponde mais ao seu arquivo de bloqueio é considerado parcial até que o arquivo de bloqueio seja regenerado. - Arquivos de bloqueio npm precisam ser da versão 2 ou 3. Entradas de pnpm e Yarn provenientes de git, arquivo local ou patch são consideradas parciais.
requirements.txtcobrir apenas versões vinculadas com==.- Outros arquivos de dependências (
package.jsonsem arquivo de bloqueio,pyproject.toml,poetry.lock,Pipfile,Cargo.lock,Gemfile.lock,pom.xml, Gradle, Composer, NuGet e outros) são encontrados e exibidos como parciais, indicando o nome do arquivo; assim, um projeto nunca é considerado coberto quando na verdade não está.
Avisos
O Coroid lê os avisos de OSV, que também contém os avisos do GitHub, para cada ecossistema utilizado pelos seus projetos. A cada hora, ele lê o que há de novo ou alterado desde a leitura anterior, e uma vez por dia lê tudo. A correspondência utiliza os inventários armazenados, portanto não precisa de acesso ao seu repositório.
O objetivo do Coroid é corresponder 95% dos novos avisos com todos os inventários em até 60 minutos após sua aparição nos dados de aviso que ele lê, e mede o tempo necessário para cada correspondência. Não pode garantir um prazo a partir da divulgação original de uma vulnerabilidade: isso depende do momento em que o aviso é publicado.
Se os dados do aviso estiverem atrasados mais de 90 minutos ou se a última leitura falhar, Visão geral e Dependências exibirão "Fonte de avisos atrasada desde…", e a cobertura de nenhum projeto será considerada completa enquanto durar esse estado.
Quando um aviso é retirado, o Coroid recalcula o que ainda se aplica dos avisos restantes para a mesma vulnerabilidade. Uma descoberta é marcada como "Já não se aplica" somente quando nenhum aviso se aplicar, nunca como corrigida.
Em pull requests
A verificação Coroid Security analisa os arquivos de bloqueio alterados pelo pull request, tanto na base quanto na referência, e conta apenas as versões vulneráveis introduzidas pela alteração:
- Observar: a verificação é aprovada ou relata informações neutras indicando o que foi encontrado.
- Imposição: uma alteração que introduz uma versão vulnerável conhecida com gravidade igual ou superior ao nível definido (alta por padrão) faz com que a verificação falhe. A cobertura parcial de um arquivo lockfile afetado pela alteração também gera falha na verificação, indicando o motivo e como executá-la novamente.
A mesma verificação é executada nos pull requests de correção e de funcionalidades do próprio Coroid antes que eles sejam abertos. Para saber como essa verificação funciona, como exigir sua execução e como executá-la novamente, consulte Permissões do GitHub e a verificação de Segurança do Coroid.
Notificações
O primeiro inventário completo de um repositório constitui uma linha de base silenciosa: seus resultados aparecem em Segurança e ninguém recebe notificação. Depois disso, a detecção de uma nova dependência crítica notifica os proprietários e administradores da organização uma única vez, por meio do sistema de notificações, por e-mail quando o e-mail está habilitado e no Slack quando o Slack está conectado. Para um aviso público, o sistema de notificações informa o nome do pacote e do aviso; para casos ainda não divulgados publicamente, apenas indica que uma descoberta crítica requer atenção. Consulte Divulgação.