Perguntas frequentes | Azul

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

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

Por exemplo, o CredScan (Verificador de Credenciais) analisa arquivos dentro da estrutura de pastas do repositório de código. Por causa dessa análise, você pode executar as tarefas de build do CredScan and Publish Security Analysis Logs em um build autônomo para obter resultados.

Para outras ferramentas como BinSkim que analisam artefatos pós-build, a compilação é necessária primeiro.

Sim. Você pode introduzir uma quebra de build quando qualquer ferramenta relata um problema ou problema em seu arquivo de log. Adicione a tarefa de build pós-análise e marque a caixa de seleção para qualquer ferramenta para a qual você deseja interromper o build.

Na interface do usuário da tarefa Pós-Análise, você pode optar por interromper o build quando qualquer ferramenta relatar erros somente ou erros e avisos.

Normalmente, as tarefas de build 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 build qualquer coisa que normalmente passa para uma ferramenta de linha de comando.

Diferenças perceptíveis:

• As ferramentas são executadas na pasta de origem do agente $(Build.SourcesDirectory) ou no %BUILD_SOURCESDIRECTORY%. Um exemplo é C:\agent_work\1\s.
• Os caminhos nos argumentos podem ser relativos à raiz do diretório de origem listada anteriormente. Os caminhos também podem ser absolutos. Você obtém caminhos absolutos usando variáveis de build 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 build, esse local será substituído por um caminho para nossa localização conhecida de logs no agente de build
• Alguns outros argumentos de linha de comando são alterados para algumas ferramentas. Um exemplo é a adição ou remoção de opções que garantem que nenhuma GUI seja iniciada.

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

As tarefas de build filtram algumas entradas do usuário. Para essa pergunta especificamente, eles atualizam o local do arquivo de saída gerado para ser um local comum no agente de build. Para obter mais informações sobre esse local, consulte as perguntas a seguir.

As tarefas de build 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.

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

Na maioria dos casos, sim.

No entanto, o Azure DevOps não dá suporte à execução de tarefas em pipelines de versão 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 falha com uma mensagem de erro descritiva.

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

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

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

Perguntas frequentes específicas da tarefa

Perguntas específicas para tarefas de build são listadas nesta seção.

Aqui estão os 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, conforme mostrado no exemplo a seguir.

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

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. Ele também pode ser a parte de nome base de um caminho de arquivo completo ou um nome de arquivo. Não há suporte para curingas.

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

Exemplos de regras de supressão válidas:

• < >\src\JS\lib\angular.js InputPath – 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"
    }
  ]
}

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

• Azure Key Vault
• do Azure AD (Azure Active Directory)
• MSI (Identidade de Serviço Gerenciado) do Azure AD
• Identidades gerenciadas para os recursos do Azure
• identidades gerenciadas no Serviço de Aplicativo do Azure e no Azure Functions
• biblioteca AppAuthentication

Para obter mais informações, consulte a postagem no blog Gerenciando segredos com segurança no cloud.

O Verificador de Credenciais depende de um conjunto de pesquisadores de conteúdo que normalmente são 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. Mas você também pode implementar seus próprios pesquisadores personalizados.

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

• Name: o nome do pesquisador descritivo a ser usado nos arquivos de saída do Verificador de Credenciais. Recomendamos que você use a convenção de nomenclatura de maiúsculas e minúsculas para nomes de pesquisa.

• 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 pesquisa por meio de expressões regulares (regex).
  • O valor RuleId para um pesquisador personalizado deve ter seu próprio namespace. Os exemplos incluem o namespace CSCAN-<>0010, o Namespace CSCAN-<>0020 e o Namespace CSCAN-<>0030.
  • Um nome de pesquisador totalmente qualificado é a combinação de um valor RuleId e um nome de pesquisador. Exemplos incluem CSCAN0010. KeyStoreFiles e CSCAN0020. Base64EncodedCertificate.

• ResourceMatchPattern: Regex de extensões de arquivo para verificar no searcher.

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

• ContentSearchFilters: uma matriz de cadeias de caracteres contendo instruções regex para filtrar falsos positivos específicos do searcher.

• 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 de campo de sugestões para uma correspondência usando o formato de relatório PREfast.

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

  

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

A mensagem de erro completa:

"Erro: o projeto foi restaurado usando Microsoft.NETCore.App versão x.x.x, mas com as configurações atuais, a versão y.y.y seria usada em vez disso. Para resolver esse problema, verifique se as mesmas configurações são usadas para restauração e para operações subsequentes, como compilar ou publicar. Normalmente, esse problema pode ocorrer se a propriedade RuntimeIdentifier for definida durante a compilação ou publicação, mas não durante a restauração."

Como as tarefas de Analisadores Roslyn são executadas como parte da compilação, a árvore de origem no computador de build deve estar em um estado compilável.

Uma etapa entre a compilação principal e as etapas dos Analisadores Roslyn pode ter colocado a árvore de origem em um estado que impede a construção. Essa etapa extra provavelmente é dotnet.exede publicação. Tente duplicar a etapa que faz uma restauração do NuGet pouco antes da etapa Analisadores Roslyn. Essa etapa duplicada pode colocar a árvore de origem de volta em 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 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 aos Analisadores Roslyn. A execução do comando csc.exe /version deve relatar um valor de versão 2.6 ou posterior.

Às vezes, um arquivo .csproj pode substituir a instalação do Visual Studio do computador de build fazendo 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 ao Microsoft.Net.Compilers. Caso contrário, verifique se a versão do pacote referenciado também é 2.6 ou posterior.

Tente obter o caminho de 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 Roslyn Analisadores. Eles podem ser semelhantes a /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#, acesse Microsoft.Net.Compilers. Para obter a versão instalada, execute csc.exe /version em um prompt de comando. Verifique se você faz referência a um pacote NuGet do Microsoft.Net.Compilers que é a versão 2.6 ou posterior.

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

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

Próximas etapas

Se você precisar de assistência adicional, o Suporte à Análise de Código de Segurança da Microsoft estará disponível de segunda a sexta-feira das 9h às 17h no Horário Padrão do Pacífico.

• Integração: consulte nossa documentação de integração

• Suporte: Envie um email para nossa equipe suporte à Análise de Código de Segurança da Microsoft