Compartilhar via


Fortalecendo a segurança e a integração de repositório

Com essa atualização, estamos melhorando a segurança e a autenticação no Azure DevOps. A sobreposição de segredos para o OAuth do Azure DevOps torna a rotação de segredos integrada, enquanto o GitHub Advanced Security melhora a filtragem na página de visão geral da segurança, garantindo que a publicação de vários repositórios roteie corretamente os alertas de dependência e verificação de código.

As atualizações de imagem hospedadas no Azure Pipelines incluem ubuntu-24.04, Windows 2025 e mac-OS 15 Sequoia, garantindo uma experiência mais segura e confiável.

Confira as notas sobre a versão para obter detalhes.

Geral

GitHub Advanced Security para Azure DevOps

Azure Pipelines

Test Plans

Geral

Segredos sobrepostos para OAuth do Azure DevOps

Estamos entusiasmados em introduzir o novo recurso de segredos sobrepostos no Azure DevOps OAuth, projetado para aprimorar a segurança e simplificar rotações secretas. Esse recurso permite adicionar um novo segredo ao seu cliente OAuth enquanto o anterior permanece ativo, garantindo a operação contínua de seus aplicativos. Você pode gerenciar esses segredos programaticamente por meio da API ou por meio da interface do usuário da página de aplicativo do Visual Studio.

Como parte de melhorias de segurança contínuas, o OAuth do Azure DevOps está programado para ser preterido em 2026. Recomendamos que você migre para microsoft Entra ID OAuth para recursos de segurança aprimorados e investimentos de longo prazo. Nesse ínterim, recomendamos atualizar regularmente seus segredos usando nosso novo recurso de segredos sobrepostos.

Descontinuação de etiquetas de estatísticas de idiomas na página Resumo do Projeto

Nas próximas semanas, vamos descontinuar as etiquetas de estatísticas de idiomas da página de resumo do projeto. Remover essas marcas ajudará a otimizar o desempenho, resultando em tempos de carga mais rápidos e uma interface mais responsiva.

A atualização ocorrerá automaticamente, sem nenhuma ação necessária de sua parte.

Permissão de Planos de Entrega adicionada

Como parte de nossos aprimoramentos de segurança contínuos, introduzimos uma nova permissão no nível do projeto Gerenciar Planos de Entrega . Essa alteração foi implementada para impedir o acesso não intencional de leitura/gravação para usuários no grupo Leitores.

GitHub Advanced Security para Azure DevOps

Página de risco de visão geral de segurança aprimorada com novas colunas e opções de filtragem

Na guia Risco, você encontrará colunas recém-adicionadas exibindo alertas de segurança novos, corrigidos e descartados em toda a sua organização. Adicionamos opções de filtragem para refinar resultados por projeto, ferramenta (segredos, dependências ou resultados de verificação de código) e um filtro baseado em tempo para definir limites de pesquisa.

Além disso, a aplicação de um filtro adiciona um parâmetro de consulta de URL, permitindo que você compartilhe a exibição pré-filtrada com outras pessoas em sua organização.

Cenários de publicação de vários repositórios com suporte para a Segurança Avançada do GitHub para Azure DevOps

Anteriormente, quando uma definição de pipeline estava alojada em um repositório e o código-fonte a ser verificado pela Segurança Avançada do GitHub estava em outro, os resultados eram processados e enviados para o repositório errado. Em vez de publicar alertas no repositório com o código-fonte, eles apareceram no repositório em que o pipeline foi definido.

Agora, a verificação de dependência e a verificação de código roteiam corretamente os alertas para o repositório que contém o código-fonte verificado em cenários de vários repositórios.

Para habilitar esse recurso, defina a variável de ambiente de pipeline advancedsecurity.publish.repository.infer: true para inferir o repositório a ser publicado do repositório no diretório de trabalho.

Como alternativa, se você não realizar o checkout explicitamente de um repositório ou usar um alias para realizar o checkout, utilize a variável advancedsecurity.publish.repository: $[ convertToJson(resources.repositories['YourRepositoryAlias']) ].

Snippet de código YAML:

  trigger:
  - main

resources:
  repositories:
    - repository: BicepGoat
      type: git
      name: BicepGoat
      ref: refs/heads/main
      trigger:
        - main

jobs:
  # Explicit - `advancedsecurity.publish.repository` explicitly defines the repository to submit SARIF to.
  - job: "AdvancedSecurityCodeScanningExplicit"
    displayName: "🛡 Infrastructure-as-Code Scanning (Explicit)"
    variables:
      advancedsecurity.publish.repository: $[ convertToJson(resources.repositories['BicepGoat']) ]
    steps:
      - checkout: BicepGoat
      - task: TemplateAnalyzerSarif@1
        displayName: Scan with Template Analyzer
      - task: AdvancedSecurity-Publish@1
        displayName: Publish to IaC Scanning Results to Advanced Security


  # Infer - `advancedsecurity.publish.repository.infer` specifies that the `AdvancedSecurity-Publish` must
  # infer repository to submit SARIF to from the working directory on the build agent.
  - job: "AdvancedSecurityCodeScanningInfer"
    displayName: "🛡 Infrastructure-as-Code Scanning (Infer)"
    variables:
      advancedsecurity.publish.repository.infer: true
    steps:
      - checkout: BicepGoat
      - task: TemplateAnalyzerSarif@1
        displayName: Scan with Template Analyzer
      - task: AdvancedSecurity-Publish@1
        displayName: Publish to IaC Scanning Results to Advanced Security

Ganchos de serviço para alertas do GitHub Advanced Security para Azure DevOps (versão prévia)

Agora você pode configurar ganchos de serviço para eventos de alerta de Segurança Avançada do GitHub, incluindo:

  • Novo alerta criado
  • Dados de alerta alterados
  • Estado de alerta alterado

Assim como outros eventos de repositório, você pode filtrar por repositório e branch. Para alertas especificamente, você pode filtrar por tipo de alerta (dependências, verificação de código ou segredos) e gravidade do alerta.

Para participar da prévia, preencha o formulário de interesse de prévia ou envie um e-mail para nós !

O suporte ao pnpm v9 chega ao GitHub Advanced Security para verificação de dependência do Azure DevOps

Com o pnpm v8 atingindo o fim da vida útil no final de abril, a próxima atualização de verificação de dependência incluirá suporte para pnpm v9. Essa atualização vem em resposta à sua solicitação da Comunidade de Desenvolvedores para suporte ao pnpm v9.

Azure Pipelines

Atualizações de imagens hospedadas

Estamos distribuindo atualizações para manter os agentes hospedados do Azure Pipelines seguros e atuais. Essas atualizações incluem a adição de suporte ao Ubuntu-24.04, às imagens do Windows 2025 e ao macOS-15 Sequoia, ao mesmo tempo em que descontinuam imagens mais antigas, como o Ubuntu-20.04 e o Windows Server 2019.

Para obter mais detalhes, visite nossa postagem no blog .

O macOS-15 Sequoia está disponível em geral

A imagem macOS-15 estará disponível nos agentes hospedados do Azure Pipelines a partir de 1º de abril. Para usar essa imagem, atualize o arquivo YAML para incluir vmImage:'macos-15':

- job: macOS15
  pool:
    vmImage: 'macOS-15'
  steps:
  - bash: |
      echo Hello from macOS Sequoia
      sw_vers

Para o software macOS-15 instalado, consulte configuração de imagem.

A imagem macOS-14 ainda será usada ao especificar macOS-latest. Atualizaremos o macOS-latest para utilizar macOS-15 em abril.

A imagem do Windows-2025 está disponível na versão prévia

A imagem do windows-2025 já está disponível em preview para agentes hospedados no Azure Pipelines. Para usar essa imagem, atualize o arquivo YAML para incluir vmImage:'windows-2025':

- job: win2025
  pool:
    vmImage: 'windows-2025'
  steps:
  - pwsh: |
      Write-Host "(Get-ComputerInfo).WindowsProductName"
      Get-ComputerInfo | Select-Object WindowsProductName
      Write-Host "`$PSVersionTable.OS"
      $PSVersionTable.OS

Para o software Windows Server 2025 instalado, consulte configuração de imagem.

A imagem de pipeline mais recente do ubuntu começará a usar o ubuntu-24.04

Nas próximas semanas, os trabalhos de pipeline que especificam o ubuntu-latest começarão a usar o ubuntu-24.04 em vez do ubuntu-22.04.

Para obter diretrizes sobre tarefas que usam ferramentas que não estão mais na imagem ubuntu-24.04, consulte nossa postagem no blog . Para continuar usando o Ubuntu 22.04, use o rótulo de imagem ubuntu-22.04:

- job: ubuntu2404
  pool:
    vmImage: 'ubuntu-24.04'
  steps:
  - bash: |
      echo Hello from Ubuntu 24.04
      lsb_release -d
  - pwsh: |
      Write-Host "`$PSVersionTable.OS"
      $PSVersionTable.OS

A imagem de pipeline do ubuntu-20.04 foi descontinuada e será desativada em 1º de abril

Estamos descontinuando o suporte para a imagem do Ubuntu 20.04 no Azure Pipelines porque ela chegará ao fim do suporte em breve. Localize o plano de substituição com agendamento de brownout em nossa postagem no blog.

A federação de identidade de carga de trabalho usa o emissor do Entra

Há pouco mais de um ano, disponibilizamos a Federação de identidade de carga de trabalho em geral. A federação de identidade de carga de trabalho permite configurar uma conexão de serviço sem uma chave secreta. A identidade (registro de aplicativo, Identidade Gerenciada) que sustenta a conexão de serviço só pode ser usada para a finalidade pretendida: a conexão de serviço configurada na credencial federada da identidade.

Agora estamos alterando o formato da credencial federada para novas conexões de serviço do Azure e do Docker. As conexões de serviço existentes funcionarão como antes.

  Emissor do Azure DevOps Emissor do Entra (novas conexões de serviços)
Emissor https://vstoken.dev.azure.com/<organization id> https://login.microsoftonline.com/<Entra tenant id>/v2.0
Assunto sc://<organization name>/<project name>/<service connection name> <entra prefix>/sc/<organization id>/<service connection id>

Não há nenhuma alteração na configuração e a maneira como os tokens são obtidos permanece a mesma. As tarefas de pipeline não precisam ser atualizadas e funcionarão como anteriormente.

As etapas para criar uma conexão de serviço não estão mudando e, na maioria dos casos, o novo emissor não está visível. Ao configurar manualmente uma conexão de serviço do Azure, você verá as novas credenciais federadas exibidas:

Copie esses valores como antes ao criar uma credencial federada para um registro de aplicativo ou identidade gerenciada.

Automação

Ao criar uma conexão de serviço na automação com a API REST , use a credencial federada retornada pela API:

authorization.parameters.workloadIdentityFederationIssuer
authorization.parameters.workloadIdentityFederationSubject

Da mesma forma, ao criar uma conexão de serviço com o provedor Terraform azuredevops, o recurso azuredevops_serviceendpoint_azurerm retorna atributos workload_identity_federation_issuer e workload_identity_federation_subject.

Mais informações

tarefa Gradle@4

Uma nova tarefa Gradle@4 foi criada com suporte para Gradle 8.0. A opção de cobertura de código interna é removida da Gradle tarefa que começa com Gradle@4. Para usar a cobertura de código com o Gradle no pipeline:

A configuração da análise do SonarQube foi movida para as extensões SonarQube ou SonarCloud na tarefa Prepare Analysis Configuration.

Identidade do usuário que solicitou uma etapa para ser executada

Para melhorar a segurança de seus pipelines YAML, convém saber quem solicitou um estágio para ser executado. Para atender a essa necessidade, foram adicionadas duas novas variáveis predefinidas, Build.StageRequestedBy e Build.StageRequestedById. Essas variáveis são semelhantes às variáveis Build.RequestedFor e Build.RequestedForId, mas para uma etapa, não uma execução.

Quando um usuário dispara explicitamente um usuário, por exemplo, no caso de um estágio disparado manualmente ou executando novamente um estágio, sua identidade é usada para preencher as duas variáveis.

Test Plans

Publicar aprimoramentos de tarefa dos resultados da cobertura de código v2

Com esta versão, estamos incluindo várias melhorias na tarefa v2:

  • Suporte expandido para vários formatos de cobertura de código, incluindo: .coverage,.covx,.covb,.cjson,.xml,.lcov e pycov1.
  • Geração de um arquivo cjson abrangente (e um relatório de cobertura de código) que contém informações detalhadas de cobertura de código, como nomes de arquivo, linhas cobertas/não cobertas etc.
  • Suporte para cobertura diferente (cobertura de PR): v2 pode gerar comentários de PR de cobertura diferente para vários idiomas no mesmo pipeline.
  • Agora, a tarefa v2 dá suporte à tarefa Verificação de Qualidade de Build, que não tinha suporte na tarefa v1.

Exportar casos de teste com colunas personalizadas no XLSX

Agora você pode exportar casos de teste com colunas personalizadas no XLSX. Com base em seus comentários, os Planos de Teste dão suporte à exportação de casos de teste com colunas personalizadas, proporcionando maior flexibilidade e controle sobre os dados que você compartilha e analisa. Esse aprimoramento ajuda você a adaptar as exportações às suas necessidades, garantindo que as informações exportadas sejam relevantes e acionáveis.

Próximas etapas

Observação

Essas funcionalidades serão lançadas nas próximas duas a três semanas.

Vá até o Azure DevOps e dê uma olhada.

Como fornecer comentários

Adoraríamos ouvir o que você pensa sobre essas características. Use o menu de ajuda para relatar um problema ou fornecer uma sugestão.

fazer uma sugestão

Você também pode obter conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigado

Silviu Andrica