Dispense alertas de verificação de dependência na Segurança Avançada
Artigo
A verificação de dependência em Segurança Avançada deteta os componentes de código aberto usados em seu código-fonte e identifica se há alguma vulnerabilidade associada. Qualquer vulnerabilidade encontrada de componentes de código aberto é sinalizada como um alerta. Com esta atualização, você pode descartar alertas de verificação de dependência na Segurança Avançada que você acredita ser um risco falso positivo ou aceitável.
No Azure Repos, alteramos o comportamento padrão para remover a permissão "Editar políticas" ao criar uma nova ramificação.
Confira as notas de versão para saber mais sobre esses recursos.
Supressão de alertas para alertas de análise de dependências na Segurança Avançada
Agora você pode descartar quaisquer alertas de verificação de dependência que você acredita ser um risco falso positivo ou aceitável. Essas são as mesmas opções de desligamento para alertas de varredura secreta e verificação de código na Segurança Avançada que você pode usar atualmente.
Observe que talvez seja necessário executar novamente o pipeline de deteção com a tarefa de verificação de dependência, bem como garantir que você tenha as Advanced Security: dismiss alerts permissões para descartar esses alertas.
Para saber mais sobre demissões de alertas, consulte Ignorar alertas de verificação de dependência.
Azure Boards
Copiar link para item de trabalho
Fizemos uma pequena melhoria para copiar a URL do item de trabalho de várias áreas nos Painéis do Azure. Facilitando a obtenção do link direto para um item de trabalho específico.
O link Copiar foi adicionado aos menus de contexto no formulário de item de trabalho, lista de pendências e lista de pendências de tarefas.
Nota
Este recurso só estará disponível com a visualização dos Novos Hubs dePainéis.
Kubelogin não está pré-instalado em imagens hospedadas. Para garantir que as tarefas acima mencionadas usem kubelogin, instale-o inserindo a tarefa KubeloginInstaller@0 antes da tarefa que depende dela:
- task: KubeloginInstaller@0
- task: HelmDeploy@0
# arguments do not need to be modified to use kubelogin
Melhorias na API REST de aprovações
As aprovações aumentam a segurança do seu pipeline YAML, dando-lhe a possibilidade de rever manualmente uma implementação para produção. Atualizamos a API REST de consulta de aprovações para torná-la mais poderosa. Agora, você:
Não é necessário especificar uma lista de approvalIds. Todos os parâmetros agora são opcionais.
Pode especificar uma lista de userIds para recuperar a lista de aprovações pendentes nesses usuários. Atualmente, a API REST retorna a lista de aprovações para as quais os usuários são explicitamente atribuídos como aprovadores.
Pode especificar as state aprovações a serem devolvidas, por exemplo, pending.
Aqui está um exemplo: GET https://dev.azure.com/fabrikamfiber/fabrikam-chat/_apis/pipelines/approvals?api-version=7.1-preview.1&userId=00aa00aa-bb11-cc22-dd33-44ee44ee44ee&state=pending retorna
Tornamos as verificações de depuração menos entediantes. Às vezes, uma verificação Invoke Azure Function ou Invoke REST API não funciona corretamente e você precisa corrigi-la. Anteriormente, você tinha que excluir essas verificações, para evitar que elas bloqueassem erroneamente uma implantação. Depois de corrigir a verificação, você teve que adicioná-la de volta e configurá-la corretamente, certificando-se de que todos os cabeçalhos necessários estão definidos ou os parâmetros de consulta estão corretos. Isso é tedioso.
Agora, você pode simplesmente desativar uma verificação. A verificação desabilitada não será executada em avaliações subsequentes do conjunto de verificação.
Depois de corrigir a verificação errada, você pode apenas ativá-la.
Atualizações dos horários do YAML cron
Em pipelines YAML, você pode definir gatilhos agendados usando a cron propriedade YAML.
Atualizámos o funcionamento da propriedade batch. Resumindo, se definir batch como true, a agenda cron não será executada se outra execução de pipeline agendada estiver em curso. Isto é independentemente da versão do repositório do pipeline.
A tabela a seguir descreve como always e batch interage.
Sempre
Batch
Comportamento
false
false
O pipeline é executado somente se houver uma alteração em relação à última execução de pipeline agendada bem-sucedida
false
true
O pipeline é executado somente se houver uma alteração em relação à última execução de pipeline agendada bem-sucedida e não houver nenhuma execução de pipeline agendada em andamento
true
false
O pipeline funciona de acordo com o cronograma cron
true
true
O pipeline funciona de acordo com o cronograma cron
Por exemplo, assuma always: false e batch: true. Suponha que há uma programação cron que especifica que o pipeline deve ser executado a cada 5 minutos. Imagine que há um novo compromisso. Dentro de 5 minutos, o gasoduto inicia sua execução programada. Imagine que uma execução de pipeline leva 30 minutos para ser concluída. Dentro desses 30 minutos, nenhuma corrida programada ocorre, independentemente do número de compromissos. A próxima execução agendada acontece somente depois que a execução agendada atual terminar.
Seu pipeline YAML pode conter vários cronogramas cron, e você pode querer que seu pipeline execute diferentes estágios / trabalhos com base em quais cron schedule é executado. Por exemplo, você tem uma compilação noturna e uma compilação semanal, e deseja que, durante a compilação semanal, seu pipeline colete mais estatísticas.
Tornamos isso possível introduzindo uma nova variável de sistema predefinida chamada Build.CronSchedule.DisplayName que contém a displayName propriedade de um cronograma cron.
Novas alternâncias para controlar a criação de pipelines clássicos
No ano passado, lançamos uma definição de configuração de Pipelines para desabilitar a criação de pipelines clássicos de compilação e lançamento.
Em resposta aos seus comentários, dividimos a alternância inicial em duas: uma para pipelines de compilação clássicos e outra para pipelines de versão clássicos, grupos de implantação e grupos de tarefas.
Se a sua organização tiver a Disable creation of classic build and release pipelines alternância ativada, ambas as novas alternâncias estarão ativadas. Se a alternância original estiver desativada, ambas as novas alternâncias estarão desativadas.
Repositórios do Azure
Removendo a permissão "Editar políticas" para o criador da ramificação
Anteriormente, quando você criava uma nova ramificação, você recebia permissão para editar políticas nessa ramificação. Com esta atualização, estamos a alterar o comportamento predefinido para não conceder esta permissão, mesmo que a definição “Gestão de permissões” esteja ativada para o repositório.
Precisará da permissão “Editar políticas” concedida explicitamente (manualmente ou através da API REST) através da herança de permissões de segurança ou através de uma associação a um grupo.
Próximos passos
Nota
Esses recursos serão lançados nas próximas duas a três semanas.
Esta certificação mede sua capacidade de realizar as seguintes tarefas técnicas: Projetar e implementar processos e comunicações, projetar e implementar uma estratégia de controle do código-fonte, projetar e implementar pipelines de criação e liberação, desenvolver um plano de segurança e conformidade e implementar uma estratégia de instrumentação.