Perguntas frequentes | Azure

Observação

Desde 31 de dezembro de 2022, a extensão MSCA (Microsoft Security Code Analysis) está desativada. O MSCA foi substituído pela extensão Microsoft Security DevOps do Azure DevOps. Siga as instruções descritas em Configurar para instalar e configurar a extensão.

Perguntas frequentes gerais

Posso instalar a extensão na minha instância do Azure DevOps Server (antigo Team Foundation Server do Visual Studio) em vez de em uma instância do Azure DevOps?

Não. A extensão não está disponível para download e instalação do Azure DevOps Server (antigo Team Foundation Server do Visual Studio).

É necessário executar Code Analysis de Segurança da Microsoft com minha compilação?

Talvez. Depende do tipo de ferramenta de análise. O código-fonte pode ser a única coisa necessária ou a saída da compilação pode ser necessária.

Por exemplo, o Verificador de Credenciais (CredScan) analisa arquivos dentro da estrutura de pastas do repositório de códigos. Devido a essa análise, você pode executar as tarefas de compilação CredScan e Publicar Logs de Análise de Segurança em uma compilação autônoma para obter resultados.

Para outras ferramentas como BinSkim que analisam os artefatos de pós-compilação, a compilação é deve ser executada primeiro.

Posso interromper minha compilação quando os resultados forem encontrados?

Sim. Você pode introduzir uma quebra de compilação quando uma ferramenta relatar um problema no arquivo de log. Adicione a tarefa de compilação pós-análise e marque a caixa de seleção das ferramentas cuja compilação você quer interromper.

Na interface do usuário da tarefa de pós-análise, você pode optar por interromper a compilação quando uma ferramenta relatar somente erros ou erros e avisos.

Como os argumentos de linha de comando no Azure DevOps são diferentes dos argumentos nas ferramentas de área de trabalho autônomas?

Normalmente, as tarefas de compilação do Azure DevOps são wrappers diretos em torno dos argumentos de linha de comando das ferramentas de segurança. Você pode passar como argumentos para uma tarefa de compilação tudo o que normalmente passaria para uma ferramenta de linha de comando.

Diferenças perceptíveis:

  • Ferramentas executadas na pasta de origem do agente $(Build.SourcesDirectory) ou de %BUILD_SOURCESDIRECTORY%. Um exemplo é C:\agent_work\1\s.
  • Os caminhos nos argumentos podem ser relativos à raiz do diretório de origem listado anteriormente. Os caminhos também podem ser absolutos. Você obtém caminhos absolutos usando variáveis de compilação do Azure DevOps ou executando um agente local com locais de implantação conhecidos de recursos locais.
  • As ferramentas fornecem automaticamente um caminho ou pasta de arquivo de saída. Se você fornecer um local de saída para uma tarefa de compilação, esse local será substituído por um caminho para nosso local conhecido de logs no agente de build
  • Alguns outros argumentos de linha de comando são alterados em algumas ferramentas. Um exemplo é a adição ou remoção de opções que garantem que nenhuma GUI seja iniciada.

Posso executar uma tarefa de compilação como o Verificador de Credenciais em vários repositórios em uma compilação do Azure DevOps?

Não. Não há suporte para a execução de ferramentas de desenvolvimento seguro em vários repositórios em um único pipeline.

O arquivo de saída especificado não está sendo criado ou não consigo encontrar o arquivo de saída que especifiquei

As tarefas de compilação filtram a entrada do usuário. Para essa questão, especificamente, elas atualizam o local do arquivo de saída gerado para ser um local comum no agente de build. Saiba mais sobre esse local nas perguntas a seguir.

Onde os arquivos de saída são gerados pelas ferramentas salvas?

As tarefas de compilação adicionam automaticamente caminhos de saída a esse local conhecido no agente de build: $(Agent.BuildDirectory)_sdt\logs. Como padronizamos esse local, todas as equipes que produzem ou consomem logs de análise de código têm acesso à saída.

Posso colocar uma compilação em fila para executar essas tarefas em um agente de build hospedado?

Sim. Todas as tarefas e ferramentas na extensão podem ser executadas em um agente de build hospedado.

Observação

A tarefa de compilação Scanner Antimalware exige um agente de build que tenha o Windows Defender habilitado. O Visual Studio 2017 (e posterior) hospedado fornece um agente desse tipo. Não é possível executar essa tarefa no agente hospedado do Visual Studio 2015.

Embora as assinaturas não possam ser atualizadas nesses agentes, elas não podem ter mais de três horas.

Posso executar essas tarefas de compilação como parte de um pipeline de lançamento em vez de um pipeline de build?

Na maioria dos casos, não.

No entanto, o Azure DevOps não dá suporte a tarefas em execução em pipelines de lançamento quando essas tarefas publicam artefatos. Essa falta de suporte impede que a tarefa Publicar logs de análise de segurança seja executada com êxito em um pipeline de lançamento. Em vez disso, a tarefa falhará com uma mensagem de erro descritiva.

De onde as tarefas de compilação baixam as ferramentas?

As tarefas de compilação podem baixar os pacotes NuGet das ferramentas pelo feed Gerenciamento de Pacotes do Azure DevOps. As tarefas de compilação também podem usar o Gerenciador de Pacotes de Nó, que deve ser pré-instalado no agente de build. Um exemplo dessa instalação é o comando npm install tslint.

De que maneira a instalação da extensão afeta a minha organização do Azure DevOps?

Após a instalação, as tarefas de compilação de segurança fornecidas pela extensão ficam disponíveis para todos os usuários da organização. Quando você cria ou edita um Pipeline do Azure, essas tarefas estão disponíveis na lista de coleção de tarefas de compilação. Caso contrário, instalar a extensão na organização do Azure DevOps não terá nenhum efeito. A instalação não modifica configurações de conta, de projeto ou pipelines.

A instalação da extensão modifica o Azure Pipelines existente?

Não. A instalação da extensão disponibiliza as tarefas de compilação de segurança para adição aos pipelines. Você ainda precisará adicionar ou atualizar as definições de build, para que as ferramentas possam trabalhar com o processo de compilação.

Perguntas frequentes específicas sobre tarefa

As perguntas específicas para tarefas de compilação estão listadas nesta seção.

Verificador de credenciais

Quais são os cenários e exemplos de supressão comuns?

Trazemos detalhes de dois dos cenários de supressão mais comuns.

Para suprimir todas as ocorrências de um determinado segredo dentro do caminho especificado

A chave de hash do segredo do arquivo de saída CredScan é necessária, como mostrado no exemplo a seguir.

{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "hash": "CLgYxl2FcQE8XZgha9/UbKLTkJkUh3Vakkxh2CAdhtY=",
        "_justification": "Secret used by MSDN sample, it is fake."
    }
  ]
}

Aviso

A chave de hash é gerada por uma parte do valor correspondente ou do conteúdo do arquivo. Qualquer revisão de código-fonte pode alterar a chave de hash e desabilitar a regra de supressão.

Para suprimir todos os segredos em um arquivo especificado ou suprimir o próprio arquivo de segredos

A expressão de arquivo pode ser um nome de arquivo. Ela também pode ser a parte do nome de base de um caminho de arquivo completo ou um nome de arquivo. Não há suporte para caracteres curinga.

Os exemplos a seguir mostram como suprimir o arquivo <InputPath>\src\JS\lib\angular.js

Exemplos de regras de supressão válidas:

  • <InputPath>\src\JS\lib\angular.js – suprime o arquivo no caminho especificado
  • \src\JS\lib\angular.js
  • \JS\lib\angular.js
  • \lib\angular.js
  • angular.js – suprime qualquer arquivo com o mesmo nome
{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "file": "\\files\\AdditonalSearcher.xml", 
        "_justification": "Additional CredScan searcher specific to my team"
    },
    {
        "file": "\\files\\unittest.pfx", 
        "_justification": "Legitimate UT certificate file with private key"
    }
  ]
}

Aviso

Todos os segredos adicionados futuramente ao arquivo também serão suprimidos automaticamente.

Quais são as diretrizes recomendadas para gerenciar os segredos?

Os seguintes recursos ajudam você a gerenciar com segurança segredos e acessar informações confidenciais de dentro dos aplicativos:

Para obter mais informações, confira a postagem de blog Gerenciar segredos com segurança na nuvem.

Posso escrever meus próprios pesquisadores personalizados?

O Verificador de Credenciais depende de um conjunto de pesquisadores de conteúdo normalmente definidos no arquivo buildsearchers.xml. O arquivo contém uma matriz de objetos serializados XML que representam um objeto ContentSearcher. O programa é distribuído com um conjunto de pesquisadores bem testados. No entanto, também é possível implementar pesquisadores personalizados.

Um pesquisador de conteúdo é definido da seguinte maneira:

  • Nome: o nome descritivo do pesquisador que será usado em arquivos de saída do Verificador de Credenciais. Recomendamos que você use a convenção de nomenclatura de minúsculas concatenadas para nomes de pesquisador.

  • RuleId: a ID opaca estável do pesquisador:

    • Um pesquisador padrão do Verificador de Credenciais recebe um valor RuleId como CSCAN0010, CSCAN0020 ou CSCAN0030. O último dígito é reservado para potencialmente mesclar ou dividir grupos de pesquisadores por meio de regex (expressões regulares).
    • O valor de RuleId para um pesquisador personalizado deve ter o próprio namespace. Os exemplos incluem CSCAN-<Namespace>0010, CSCAN-<Namespace>0020, e CSCAN-<Namespace>0030.
    • Um nome do pesquisador totalmente qualificado é a combinação de um valor de RuleId e um nome de pesquisador. Os exemplos incluem CSCAN0010.KeyStoreFiles e CSCAN0020.Base64EncodedCertificate.
  • ResourceMatchPattern: regex de extensões de arquivo para verificar em comparação ao pesquisador.

  • ContentSearchPatterns: uma matriz de cadeias de caracteres que contém instruções regex correspondentes. Se nenhum padrão de pesquisa for definido, todos os arquivos correspondentes ao valor de ResourceMatchPattern serão retornados.

  • ContentSearchFilters: uma matriz de cadeias de caracteres que contém instruções regex para filtrar falsos positivos específicos do pesquisador.

  • MatchDetails: uma mensagem descritiva, instruções de mitigação ou ambas a serem adicionadas para cada correspondência do pesquisador.

  • Recomendação: o conteúdo do campo de sugestões para uma correspondência usando o formato de relatório PREfast.

  • Severidade: um inteiro que reflete o nível de severidade de um problema. O nível de severidade mais alto tem o valor de 1.

    XML mostrando a configuração do Verificador de Credenciais

Analisadores Roslyn

Quais os erros comuns ao usar a tarefa Analisadores Roslyn?

O projeto foi restaurado usando uma versão incorreta do Microsoft.NETCore.App

A mensagem de erro completa:

"Erro: o projeto foi restaurado usando a versão Microsoft.NETCore.App x.x.x, mas a versão y.y.y deveria ter sido usada para as configurações atuais. Para resolver esse problema, verifique se as mesmas configurações são usadas para restauração e para as operações seguintes, como build ou publicação. Normalmente, esse problema pode ocorrer se a propriedade RuntimeIdentifier é definida durante o build ou a publicação, mas não durante a restauração."

Como as tarefas Analisadores Roslyn são executadas durante a compilação, a árvore de origem no computador de compilação precisa estar em um estado compilável.

Uma etapa entre a compilação principal e os Analisadores Roslyn pode ter colocado a árvore de origem em um estado que impede a compilação. Essa etapa extra é provavelmente publicar dotnet.exe. Tente duplicar a etapa que faz uma restauração do NuGet logo antes da etapa dos Analisadores Roslyn. Essa etapa duplicada pode devolver a árvore de origem a um estado compilável.

csc.exe não pode criar uma instância do analisador

A mensagem de erro completa:

"'csc.exe' saiu com o código de erro 1 -- Uma instância do analisador AAAA não pode ser criada a partir de C:\BBBB.dll : Não foi possível carregar o arquivo ou assembly 'Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35' ou uma de suas dependências. O sistema não pode localizar o arquivo especificado."

Verifique se o compilador dá suporte a Analisadores Roslyn. Executar o comando csc.exe /version deve relatar um valor de versão de 2.6 ou mais recente.

Às vezes, um arquivo .csproj pode substituir a instalação do Visual Studio do computador de compilação ao fazer referência a um pacote do Microsoft.Net.Compilers. Se você não pretende usar uma versão específica do compilador, remova as referências a Microsoft.Net.Compilers. Caso contrário, confira se a versão do pacote referenciado também é 2.6 ou mais recente.

Tente obter o caminho do log de erros, que é especificado na opção csc.exe /errorlog. A opção e o caminho aparecem no log para a tarefa de compilação Analisadores Roslyn. Ele será algo como /errorlog:F:\ts-services-123_work\456\s\Some\Project\Code\Code.csproj.sarif

A versão do compilador C# não é recente o suficiente

Para obter as versões mais recentes do compilador C#, vá para Microsoft.Net.Compilers. Para obter a versão instalada, execute csc.exe /version em um prompt de comando. Certifique-se de fazer referência a um pacote NuGet do Microsoft.Net.Compilers versão 2.6 ou mais recente.

Os logs do MSBuild e do VSBuild não foram encontrados

A tarefa de compilação de Analisadores Roslyn precisa consultar o Azure DevOps para obter o log do MSBuild da tarefa de compilação do MSBuild. Se a tarefa do analisador for executada imediatamente após a tarefa do MSBuild, o log ainda não estará disponível. Coloque outras tarefas entre a tarefa do MSBuild e a tarefa Analisadores Roslyn. Exemplos de outras tarefas incluem o BinSkim e o Scanner Antimalware.

Próximas etapas

Se precisar de assistência adicional, o suporte à análise de código de segurança da Microsoft está disponível de segunda a sexta-feira, das 9h às 17h, hora oficial do Pacífico.