Descartar alertas de examen de dependencias en Advanced Security

El examen de dependencias en Advanced Security detecta los componentes de código abierto usados en el código fuente e identifica si hay alguna vulnerabilidad asociada. Las vulnerabilidades encontradas de componentes de código abierto se marcan como una alerta. Con esta actualización, puede descartar las alertas de examen de dependencias en Advanced Security que cree que es un riesgo falso positivo o aceptable.

En Azure Repos, hemos cambiado el comportamiento predeterminado para quitar el permiso "Editar directivas" al crear una nueva rama.

Consulte las notas de la versión para obtener más información sobre estas características.

GitHub Advanced Security para Azure DevOps

• Rechazos de alertas para alertas de análisis de dependencias en Advanced Security

Azure Boards

• Copiar vínculo al elemento de trabajo

Azure Pipelines

• Las tareas de Kubernetes ahora admiten kubelogin
• Actualizaciones de las programaciones cron de YAML
• Deshabilitar una comprobación
• Mejoras en la API REST de aprobaciones
• Nuevas alternancias para controlar la creación de canalizaciones clásicas

Azure Repos

• Eliminación del permiso "Editar directivas" al creador de la rama

General

Rechazos de alertas para alertas de análisis de dependencias en Advanced Security

Ahora puede descartar cualquier alerta de análisis de dependencias que cree que es un riesgo falso positivo o aceptable. Estas son las mismas opciones de descarte para el examen de secretos y las alertas de análisis de código en Advanced Security que puede usar actualmente.

Tenga en cuenta que es posible que tenga que volver a ejecutar la canalización de detección con la tarea de análisis de dependencias, así como asegurarse de que tiene los Advanced Security: dismiss alerts permisos para descartar estas alertas.

Para más información sobre los despidos de alertas, consulte Descartar alertas de examen de dependencias.

Azure Boards

Copiar vínculo al elemento de trabajo

Hemos realizado una pequeña mejora para copiar la dirección URL del elemento de trabajo de varias áreas de Azure Boards. Facilitar la obtención del vínculo directo a un elemento de trabajo específico.

El vínculo de copia se ha agregado a los menús contextuales del formulario del elemento de trabajo, el trabajo pendiente y el trabajo pendiente de tareas.

Nota:

Esta característica solo estará disponible con la versión preliminar de New Boards Hubs.

Azure Pipelines

Las tareas de Kubernetes ahora admiten kubelogin

Hemos actualizado las tareas KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 y AzureFunctionOnKubernetes@1 para admitir kubelogin. Esto le permite dirigirse a Azure Kubernetes Service (AKS) configurado con la integración de Azure Active Directory.

Kubelogin no está preinstalado en imágenes hospedadas. Para asegurarse de que las tareas mencionadas anteriormente usan kubelogin, instálela insertando la tarea KubeloginInstaller@0 antes de la tarea que depende de ella:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Mejoras en la API REST de aprobaciones

Las aprobaciones aumentan la seguridad de la canalización de YAML al ofrecer la posibilidad de revisar manualmente una implementación en producción. Se ha actualizado la API REST de consulta de aprobaciones para que sea más eficaz. Ahora, usted:

• No es necesario especificar una lista de approvalIds. Ahora todos los parámetros son opcionales.
• Puede especificar una lista de userIds para recuperar la lista de aprobaciones pendientes en estos usuarios. Actualmente, la API REST devuelve la lista de aprobaciones para las que los usuarios se asignan explícitamente como aprobadores.
• Puede especificar el state de las aprobaciones que se van a devolver, por ejemplo, pending.

Este es un ejemplo: 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 devuelve

{
    "count": 2,
    "value":
    [
        {
            "id": "87436c03-69a3-42c7-b5c2-6abfe049ee4c",
            "steps": [],
            "status": "pending",
            "createdOn": "2023-06-27T13:58:07.417Z",
            "lastModifiedOn": "2023-06-27T13:58:07.4164237Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers": [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabricam-chat/_apis/pipelines/approvals/87436c03-69a3-42c7-b5c2-6abfe049ee4c"
                }
            }
        },
        {
            "id": "2549baca-104c-4a6f-b05f-bdc4065a53b7",
            "steps": [],
            "status": "pending",
            "createdOn": "2023-06-27T13:58:07.417Z",
            "lastModifiedOn": "2023-06-27T13:58:07.4164237Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers": [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabricam-chat/_apis/pipelines/approvals/2549baca-104c-4a6f-b05f-bdc4065a53b7"
                }
            }
        }
    ]
}

Deshabilitación de una comprobación

Hemos realizado comprobaciones de depuración menos tediosas. A veces, una comprobación invocar función de Azure o Invocar API REST no funciona correctamente y debe corregirla. Anteriormente, tenía que eliminar estas comprobaciones para evitar que bloqueasen erróneamente una implementación. Una vez corregido la comprobación, tenía que volver a agregarla y configurarla correctamente, asegurándose de que todos los encabezados necesarios están establecidos o de que los parámetros de consulta son correctos. Esto es tedioso.

Ahora, solo puede deshabilitar una comprobación. La comprobación deshabilitada no se ejecutará en las evaluaciones posteriores del conjunto de comprobaciones.

Una vez que corrija la comprobación errónea, solo puede habilitarla.

Actualizaciones de las programaciones cron de YAML

En las canalizaciones de YAML, puede definir desencadenadores programados mediante la cron propiedad YAML.

Actualizamos cómo funciona la propiedad batch. En pocas palabras, si establece batch como true, la programación cron no se ejecutará si hay otra ejecución de canalización programada en curso. Esta acción se realiza independientemente de la versión del repositorio de canalización.

La siguiente tabla describe cómo interactúan always e batch.

Siempre	Batch	Comportamiento
false	false	La canalización solo se ejecuta si hay un cambio con respecto a la última ejecución de canalización programada correcta.
false	true	La canalización solo se ejecuta si hay un cambio con respecto a la última ejecución de canalización programada correcta y no hay ninguna ejecución de canalización programada en curso.
true	false	Ejecuciones de canalización según la programación cron
true	true	Ejecuciones de canalización según la programación cron

Por ejemplo, suponga always: false que y batch: true. Supongamos que hay una programación cron que especifica que la canalización se debe ejecutar cada 5 minutos. Imagine que hay una nueva confirmación. En un plazo de 5 minutos, la canalización inicia su ejecución programada. Imagine que una ejecución de canalización tarda 30 minutos en completarse. En estos 30 minutos, no se realiza ninguna ejecución programada, independientemente del número de confirmaciones. La siguiente ejecución programada solo se produce después de que finalice la ejecución programada actual.

La canalización de YAML puede contener varias programaciones cron y es posible que quiera que la canalización ejecute diferentes fases o trabajos en función de las ejecuciones de programación cron. Por ejemplo, tiene una compilación nocturna y una compilación semanal, y desea que durante la compilación semanal de la canalización recopile más estadísticas.

Para ello, presentamos una nueva variable de sistema predefinida denominada Build.CronSchedule.DisplayName que contiene la displayName propiedad de una programación cron.

Nuevas alternancias para controlar la creación de canalizaciones clásicas

El año pasado, iniciamos una configuración de Pipelines para deshabilitar la creación de canalizaciones de compilación y versión clásicas.

En respuesta a los comentarios, hemos dividido el botón de alternancia inicial en dos: uno para canalizaciones de compilación clásicas y otro para canalizaciones de versión clásicas, grupos de implementación y grupos de tareas.

Si su organización tiene activado el Disable creation of classic build and release pipelines botón de alternancia, ambos de los nuevos botóns de alternancia están activados. Si el botón de alternancia original está desactivado, ambos nuevos botón de alternancia están desactivados.

Azure Repos

Eliminación del permiso "Editar directivas" al creador de la rama

Anteriormente, al crear una nueva rama, se le concede permiso para editar directivas en esa rama. Con esta actualización, estamos cambiando el comportamiento predeterminado para que no se conceda este permiso aunque la configuración "Administración de permisos" esté activada para el repositorio.

Necesitará que se le conceda el permiso "Editar directivas" explícitamente (ya sea manualmente o a través de la API de REST) mediante la herencia de permisos de seguridad o a través de la pertenencia a grupos.

Pasos siguientes

Nota:

Estas características se implementarán en las próximas dos a tres semanas.

Vaya a Azure DevOps y eche un vistazo.

Vaya a Azure DevOps.

Cómo enviar sus comentarios

Nos encantaría escuchar lo que piensas sobre estas características. Use el menú de ayuda para notificar un problema o proporcionar una sugerencia.

También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.

Gracias,

Silviu Andrica