Ignorare gli avvisi di analisi delle dipendenze in Sicurezza avanzata

L'analisi delle dipendenze in Sicurezza avanzata rileva i componenti open source usati nel codice sorgente e identifica se sono presenti vulnerabilità associate. Eventuali vulnerabilità rilevate dai componenti open source vengono contrassegnate come avvisi. Con questo aggiornamento, è possibile ignorare gli avvisi di analisi delle dipendenze in Sicurezza avanzata che si ritiene essere un rischio falso positivo o accettabile.

In Azure Repos è stato modificato il comportamento predefinito per rimuovere l'autorizzazione "Modifica criteri" durante la creazione di un nuovo ramo.

Per altre informazioni su queste funzionalità, vedere le note sulla versione.

Sicurezza avanzata di GitHub per Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Generali

Avvisi ignorati per gli avvisi di analisi delle dipendenze in Sicurezza avanzata

È ora possibile ignorare tutti gli avvisi di analisi delle dipendenze che si ritiene siano un falso positivo o un rischio accettabile. Queste sono le stesse opzioni di chiusura per l'analisi dei segreti e gli avvisi di analisi del codice in Sicurezza avanzata che è attualmente possibile usare.

Dismiss a dependency scanning alert

Si noti che potrebbe essere necessario eseguire di nuovo la pipeline di rilevamento con l'attività di analisi delle dipendenze e assicurarsi di disporre delle Advanced Security: dismiss alerts autorizzazioni per ignorare questi avvisi.

Per altre informazioni sui messaggi di chiusura degli avvisi, vedere Ignorare gli avvisi di analisi delle dipendenze.

Azure Boards

È stato apportato un piccolo miglioramento per copiare l'URL dell'elemento di lavoro da diverse aree in Azure Boards. Semplificando l'accesso diretto a un elemento di lavoro specifico.

Image for copy link context menu item on backlog

Il collegamento copia è stato aggiunto ai menu di scelta rapida nel modulo dell'elemento di lavoro, nel backlog e nel backlog delle attività.

Nota

Questa funzionalità sarà disponibile solo con l'anteprima di New Boards Hubs.

Azure Pipelines

Le attività kubernetes ora supportano kubelogin

Sono state aggiornate le attività di KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 e AzureFunctionOnKubernetes@1 per supportare kubelogin. In questo modo, è possibile specificare come destinazione servizio Azure Kubernetes configurata con l'integrazione di Azure Active Directory.

Kubelogin non è preinstallato nelle immagini ospitate. Per assicurarsi che le attività indicate in precedenza usino kubelogin, installarle inserendo l'attività KubeloginInstaller@0 prima dell'attività che dipende da essa:

 - task: KubeloginInstaller@0

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

Miglioramenti all'API REST di Approvazioni

Approvazioni aumentare la sicurezza della pipeline YAML offrendo la possibilità di esaminare manualmente una distribuzione nell'ambiente di produzione. È stata aggiornata l'API REST di query Approvazioni per renderla più potente. A questo momento, si:

  • Non è necessario specificare un elenco di approvalIdelementi. Tutti i parametri sono ora facoltativi.
  • Può specificare un elenco di userIds per recuperare l'elenco delle approvazioni in sospeso per questi utenti. Attualmente, l'API REST restituisce l'elenco delle approvazioni per le quali gli utenti vengono assegnati in modo esplicito come responsabili approvazione.
  • Può specificare l'oggetto state delle approvazioni da restituire, pendingad esempio .

Ecco un esempio: GET https://dev.azure.com/fabrikamfiber/fabrikam-chat/_apis/pipelines/approvals?api-version=7.1-preview.1&userId=47acd774-9773-6c31-bbb6-5a0585695d19&state=pending restituisce

{
    "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"
                }
            }
        }
    ]
}

Disabilitare un controllo

Sono stati eseguiti controlli di debug meno noiosi. In alcuni casi, un controllo richiama la funzione di Azure o richiama l'API REST non funziona correttamente ed è necessario correggerlo. In precedenza, è stato necessario eliminare tali controlli, per evitare che blocchino erroneamente una distribuzione. Dopo aver corretto il controllo, è necessario aggiungerlo nuovamente e configurarlo correttamente, assicurandosi che tutte le intestazioni necessarie siano impostate o che i parametri di query siano corretti. Questo è noioso.

È ora possibile disabilitare un controllo. Il controllo disabilitato non verrà eseguito nelle valutazioni successive della suite di controllo.

Disable a check image.

Dopo aver corretto il controllo errato, è sufficiente abilitarlo.

Enable a check image.

Aggiornamenti alle pianificazioni cron YAML

Nelle pipeline YAML è possibile definire trigger pianificati usando la cron proprietà YAML.

Il funzionamento della proprietà batch è stato aggiornato. In breve, se si imposta batch su true, la pianificazione Cron non verrà eseguita se è in corso un'altra esecuzione della pipeline pianificata. Questo avviene indipendentemente dalla versione del repository della pipeline.

Nella tabella seguente viene descritto come always e batch interagire.

Sempre Batch Comportamento
false false La pipeline viene eseguita solo se è presente una modifica rispetto all'ultima esecuzione pianificata della pipeline pianificata
false true La pipeline viene eseguita solo se è presente una modifica rispetto all'ultima esecuzione pianificata della pipeline pianificata e non è prevista alcuna esecuzione della pipeline in corso
true false Le esecuzioni della pipeline sono in base alla pianificazione cron
true true Le esecuzioni della pipeline sono in base alla pianificazione cron

Si supponga always: false , ad esempio, che e batch: true. Si supponga che esista una pianificazione cron che specifica che la pipeline deve essere eseguita ogni 5 minuti. Si supponga che sia presente un nuovo commit. Entro 5 minuti, la pipeline avvia l'esecuzione pianificata. Il completamento di un'esecuzione della pipeline richiede 30 minuti. Entro questi 30 minuti, non viene eseguita alcuna esecuzione pianificata, indipendentemente dal numero di commit. L'esecuzione pianificata successiva viene eseguita solo al termine dell'esecuzione pianificata corrente.

La pipeline YAML può contenere più pianificazioni cron ed è possibile che la pipeline esegua fasi/processi diversi in base alla pianificazione cron eseguita. Ad esempio, si dispone di una compilazione notturna e di una compilazione settimanale e si vuole che durante la compilazione settimanale la pipeline raccolga più statistiche.

Questo è possibile introducendo una nuova variabile di sistema predefinita denominata Build.CronSchedule.DisplayName che contiene la displayName proprietà di una pianificazione cron.

Nuovi interruttori per controllare la creazione di pipeline classiche

L'anno scorso è stata avviata un'impostazione di configurazione pipeline per disabilitare la creazione di pipeline di compilazione e versione classiche.

In risposta ai commenti e suggerimenti, abbiamo suddiviso l'interruttore iniziale in due: uno per le pipeline di compilazione classiche e uno per le pipeline di versione classiche, i gruppi di distribuzione e i gruppi di attività.

Disable creation

Se l'organizzazione dispone dell'interruttore Disable creation of classic build and release pipelines attivato, entrambi i nuovi interruttori sono attivati. Se l'interruttore originale è disattivato, entrambi i nuovi interruttori sono disattivati.

Azure Repos

Rimozione dell'autorizzazione "Modifica criteri" per l'autore di rami

In precedenza, quando è stato creato un nuovo ramo, è stata concessa l'autorizzazione per modificare i criteri in tale ramo. Con questo aggiornamento il comportamento predefinito viene modificato in modo da non concedere questa autorizzazione, anche se l'impostazione "Gestione autorizzazioni" viene attivata per il repository.

Permission management image.

Sarà necessario concedere l'autorizzazione "Modifica criteri" concessa in modo esplicito (manualmente o tramite l'API REST) tramite l'ereditarietà delle autorizzazioni di sicurezza o tramite l'appartenenza a un gruppo.

Passaggi successivi

Nota

Queste funzionalità verranno implementate nelle prossime due o tre settimane.

Passare ad Azure DevOps e dare un'occhiata.

Come fornire commenti e suggerimenti

Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usare il menu ? per segnalare un problema o fornire un suggerimento.

Make a suggestion

È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.

Grazie,

Silviu Andrica