Auditoria de dependências de pacotes quanto a vulnerabilidades de segurança
Uma auditoria de segurança para gerenciadores de pacotes como o NuGet é um processo que envolve a análise da segurança dos pacotes incluídos em um projeto de software. Isso envolve identificar vulnerabilidades, avaliar riscos e fazer recomendações para melhorar a segurança. A auditoria pode incluir uma revisão dos próprios pacotes, bem como quaisquer dependências e seus riscos associados. O objetivo da auditoria é identificar e mitigar quaisquer vulnerabilidades de segurança que possam ser exploradas por invasores, como injeção de código ou ataques de cross-site scripting.
Também temos uma postagem no blog que aborda nosso método de ação recomendado quando um pacote com uma vulnerabilidade conhecida for usado pelo seu projeto e ferramentas para ajudar a obter mais informações.
NuGet | SDK .NET | Visual Studio | Recurso |
---|---|---|---|
5.9 | .NET 5 SDK (5.0.200) | N/D | dotnet list package --vulnerable |
6.8 | .NET 8 SDK (8.0.100) | Visual Studio 2022 17.8 | NuGetAudit para PackageReference |
6.10 | N/D | Visual Studio 2022 17.10 | NuGetAudit para packages.config |
6.11 | .NET 8 SDK (8.0.400) | Visual Studio 2022 17.11 | NuGetAuditSuppress para PackageReference |
6.12 | .NET 9 SDK (9.0.100) | Visual Studio 2022 17.12 | Fontes de auditoria. NuGetAuditSuppress para packages.config. |
O comando restore
é executado automaticamente quando você executa uma operação de pacote comum, como carregar um projeto pela primeira vez, adicionar um novo pacote, atualizar uma versão do pacote ou remover um pacote do seu projeto em seu IDE favorito.
Suas dependências são verificadas em relação a uma lista de vulnerabilidades conhecidas fornecida por suas fontes de auditoria.
- Na linha de comando, navegue para o diretório do projeto ou solução.
- Execute
restore
usando suas ferramentas preferidas (ou seja, dotnet, MSBuild, NuGet.exe, VisualStudio etc). - Revise os avisos e resolva as vulnerabilidades de segurança conhecidas.
A auditoria pode ser configurada por meio das propriedades do MSBuild em um arquivo do .csproj
ou do MSBuild sendo avaliado como parte do seu projeto.
Recomendamos que a auditoria seja configurada no nível de repositório.
Propriedade do MSBuild | Padrão | Valores possíveis | Observações |
---|---|---|---|
NuGetAuditMode | all | direct e all |
Se você quiser auditar apenas as dependências de nível superior, poderá definir o valor como direct . NuGetAuditMode não é aplicável a projetos packages.config. |
NuGetAuditLevel | low | low , moderate , high e critical |
O nível mínimo de gravidade a ser informado. Se você quiser ver os avisos de moderate , high e critical (exceto low ), defina o valor como moderate |
NuGetAudit | true | true e false |
Se não desejar receber relatórios de auditoria de segurança, você pode recusar completamente a experiência definindo o valor como false |
Observação: no .NET 8, o valor padrão de NuGetAuditMode é direct
.
Portanto, definir SdkAnalysisLevel como 8.0.400
altera o valor padrão de NuGetAuditMode adequadamente.
A restauração baixa o recurso VulnerabilityInfo
de um servidor para verificar a lista de pacotes que cada projeto está usando.
A lista de fontes é definida pelo elemento auditSources
em NuGet.Config e o aviso NU1905 é gerado se qualquer uma das fontes de auditoria não fornecer nenhuma informação de vulnerabilidade.
Se auditSources
não estiver definido ou for apagado sem a adição de nenhuma fonte, o sistema usará packageSources
e o aviso NU1905 será suprimido.
Como uma mitigação comum para os ataques de substituição de pacote é o uso de uma única fonte de pacote que faz upstream do nuget.org, de modo que o NuGet não esteja configurado para usar nuget.org como uma fonte de pacote, é possível definir as fontes de auditoria para usar nuget.org (ou qualquer outra fonte que forneça informações de vulnerabilidade) sem também usá-lo como uma fonte de pacote.
A fonte de dados para o banco de dados de vulnerabilidades do nuget.org é o GitHub Advisory Database. Observe que o protocolo V2 foi preterido, portanto, se o nuget.config ainda estiver usando o ponto de extremidade V2, você deverá migrar para o ponto de extremidade V3.
<configuration>
<auditSources>
<clear />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</auditSources>
</configuration>
As fontes de auditoria estão disponíveis desde o NuGet 6.12, SDK .NET 9.0.100 e Visual Studio 2022 17.12.
Antes dessa versão, a Auditoria do NuGet usará apenas fontes de pacote para baixar informações de vulnerabilidade.
No momento, as fontes de auditoria não são usadas no dotnet list package --vulnerable
.
Você pode optar por excluir comunicados específicos do relatório de auditoria adicionando um novo item NuGetAuditSuppress
do MSBuild para cada comunicado.
Defina um item NuGetAuditSuppress
com os metadados de Include=
definidos para a URL de consultoria que você deseja suprimir.
<ItemGroup>
<NuGetAuditSuppress Include="https://github.com/advisories/XXXX" />
</ItemGroup>
De forma semelhante às outras propriedades de configuração de auditoria do NuGet, os itens NuGetAuditSuppress
podem ser definidos no nível do projeto ou do repositório.
O NuGetAuditSuppress
está disponível para projetos PackageReference a partir do NuGet 6.11, do Visual Studio 17.11 e do SDK do .NET 8.0.400.
Ele está disponível para packages.config com o Visual Studio 17.12 e NuGet 6.12.
Código do aviso | Motivo |
---|---|
NU1900 | Erro ao se comunicar com a origem do pacote ao obter informações sobre vulnerabilidade. |
NU1901 | Pacote com baixa gravidade detectado |
NU1902 | Pacote com gravidade moderada detectado |
NU1903 | Pacote com alta gravidade detectado |
NU1904 | Pacote com gravidade crítica detectado |
NU1905 | Uma fonte de auditoria não fornece um banco de dados de vulnerabilidades |
Você pode personalizar sua compilação para tratar esses avisos como erros para tratar avisos como erros ou tratar avisos como não erros.
Por exemplo, se você já estiver usando <TreatWarningsAsErrors>
para tratar todos os avisos (C#, NuGet, MSBuild, etc) como erros, poderá usar <WarningsNotAsErrors>$(WarningsNotAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsNotAsErrors>
para evitar que vulnerabilidades descobertas no futuro interrompam sua compilação.
Como alternativa, se você quiser manter vulnerabilidades baixas e moderadas como avisos, mas tratar vulnerabilidades altas e críticas como erros, e você não estiver usando o TreatWarningsAsErrors
, você poderá usar o <WarningsAsErrors>$(WarningsAsErrors);NU1903;NU1904</WarningsAsErrors>
.
Observação
As propriedades do MSBuild para gravidade da mensagem, como NoWarn
e TreatWarningsAsErrors
, não são compatíveis com projetos packages.config.
Após a restauração bem-sucedida de um projeto, o dotnet list package
tem um argumento --vulnerable
para filtrar os pacotes com base em quais pacotes têm vulnerabilidades conhecidas.
Observe que --include-transitive
não é padrão, portanto, deve ser incluído.
Também temos uma postagem no blog que aborda nosso método de ação recomendado quando um pacote com uma vulnerabilidade conhecida for usado pelo seu projeto e ferramentas para ajudar a obter mais informações.
Se vulnerabilidades de segurança forem encontradas e houver atualizações disponíveis para o pacote, você poderá:
- Editar o
.csproj
ou outro local de versão do pacote (Directory.Packages.props
) com uma versão mais recente contendo uma correção de segurança. - Use a interface do usuário do Gerenciador de Pacotes NuGet no Visual Studio para atualizar o pacote individual.
- Execute o comando
dotnet add package
com o respectivo ID do pacote para atualizar para a versão mais recente.
Se houver uma vulnerabilidade conhecida nas dependências transitivas de um pacote de nível superior, você terá estas opções:
- Adicione a versão do pacote fixo como uma referência direta do pacote. Observação: certifique-se de remover essa referência quando uma nova atualização de versão do pacote estiver disponível e certifique-se de manter os atributos definidos para o comportamento esperado.
- Use o Gerenciamento Central de Pacotes com a funcionalidade de fixação transitiva.
- Suprima o aviso até que ele possa ser resolvido.
- Registre um problema no rastreador do pacote de nível superior para solicitar uma atualização.
Caso exista uma vulnerabilidade conhecida em um pacote sem uma correção de segurança, você poderá fazer o seguinte.
- Verifique se há fatores atenuantes descritos no relatório de avisos.
- Use um pacote sugerido se o pacote estiver marcado como preterido ou for abandonado.
- Se o pacote for de código aberto, considere contribuir com uma correção.
- Abra um problema no rastreador de problemas do pacote.
Revise o consultor de segurança para obter quaisquer fatores atenuantes que possam permitir que você continue usando o pacote com a vulnerabilidade. A vulnerabilidade pode existir somente quando o código é usado em uma estrutura específica, sistema operacional ou uma função especial é chamada.
Caso um comunicado de segurança seja relatado para o pacote que você está usando e o pacote esteja marcado como preterido ou pareça abandonado, considere usar qualquer pacote alternativo sugerido que o autor do pacote tenha declarado ou um pacote composto por funcionalidade semelhante que seja mantido.
Se não existir uma correção para o comunicado de segurança, você poderá sugerir alterações que resolvam a vulnerabilidade em uma solicitação pull no repositório de código aberto do pacote ou entrar em contato com o autor por meio da seção Contact owners
na página de detalhes do pacote NuGet.org.
Se você não quiser corrigir a vulnerabilidade ou não conseguir atualizar ou substituir o pacote, abra um problema no rastreador de problemas do pacote ou no método de contato preferido.
No NuGet.org, você pode navegar até a página de detalhes do pacote e clicar em Report package
, o que orientará você para entrar em contato com o autor.
Se nenhuma vulnerabilidade de segurança for encontrada, isso significa que pacotes com vulnerabilidades conhecidas não foram encontrados no gráfico de pacotes no momento em que você verificou.
Como o banco de dados de consultoria pode ser atualizado a qualquer momento, recomendamos verificar regularmente sua saída dotnet restore
e garantir o mesmo em seu processo de integração contínua.
Os recursos de auditoria de segurança são cruciais para manter a segurança e a integridade dos projetos de software. Esses recursos fornecem uma camada adicional de proteção contra vulnerabilidades de segurança e garantem que você possa usar pacotes de código aberto com confiança.