Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Stiamo espandendo il supporto di GitHub Advanced Security per includere risultati con posizioni degli URI, offrendo una copertura più ampia dagli strumenti di scansione dei container e di analisi dinamica.
È stato anche migliorato il modo in cui le richieste pull di GitHub si connettono agli elementi di lavoro di Azure Boards, semplificando l'aggiornamento degli stati degli elementi di lavoro quando le richieste pull vengono unite.
Dai un'occhiata alle note di rilascio per i dettagli.
Generale
- Gestire ambiti con privilegi elevati, decoratori della pipeline ed estensioni non pubblicate
- Segreti sovrapposti per le app OAuth
Sicurezza avanzata di GitHub per Azure DevOps
Azure Boards:
Generale
Gestire ambiti con privilegi elevati, decoratori della pipeline ed estensioni non pubblicate
Le estensioni di Azure DevOps migliorano le funzionalità e i flussi di lavoro del prodotto, ma quelli con ambiti con privilegi elevati possono comportare diversi rischi.
È stata aggiunta una nuova funzionalità che contrassegna questi ambiti nella pagina di amministrazione di ogni organizzazione e nella pagina di installazione di Visual Studio Marketplace, consentendo agli amministratori di prendere decisioni informate. Anche le estensioni e i decoratori della pipeline non pubblicati vengono contrassegnati per la consapevolezza da parte dell'amministratore e le azioni appropriate.
Per altre informazioni, visitare la pagina della documentazione .
Segreti sovrapposti per le app OAuth
Azure DevOps ha introdotto segreti sovrapposti per le app OAuth, una nuova funzionalità disponibile sia nell'interfaccia utente che nell'API progettata per semplificare la rotazione dei segreti e ridurre i tempi di inattività.
Con segreti sovrapposti, gli sviluppatori possono generare un nuovo segreto mentre quello precedente rimane valido, garantendo l'accesso ininterrotto durante le rotazioni dei segreti. Con questo aggiornamento, si riduce anche il periodo di validità del segreto predefinito a 60 giorni. Man mano che le app OAuth di Azure DevOps sono prossime alla deprecazione prevista nel 2026, questo aggiornamento offre un miglioramento cruciale della sicurezza per i team che ancora dipendono da queste applicazioni. Provalo oggi per semplificare la gestione dei segreti e migliorare la resilienza. Per altre informazioni, vedere il post di blog.
Sicurezza avanzata di GitHub per Azure DevOps
Ora, Sicurezza Avanzata accetta risultati con percorsi URI
In precedenza, Advanced Security rifiutò i file SARIF contenenti risultati con URI elencati come percorso di avviso. Questo in genere influisce sugli strumenti di analisi dei contenitori e sugli strumenti di analisi dinamica delle applicazioni. Sicurezza avanzata può ora accettare e visualizzare in modo condizionale i risultati di questi strumenti.
Per abilitare questa funzionalità, impostare la variabile advancedsecurity.publish.allowmissingpartialfingerprints
della pipeline .
trigger: none
variables:
advancedsecurity.publish.allowmissingpartialfingerprints: true
jobs:
- job: "AdvancedSecurityPublish"
displayName: "🛡 Publish ZAP SARIF"
steps:
- task: AdvancedSecurity-Publish@1
displayName: Publish to ZAP SARIF to Advanced Security
inputs:
SarifsInputDirectory: $(Build.SourcesDirectory)/sarifs/
Azure Boards (Pannelli di Azure)
Integrazione di GitHub: supporto per la transizione di stato
È stato ampliato il supporto per collegare le richieste pull di GitHub agli elementi di lavoro di Azure Boards. In precedenza, solo la Fixes AB#{ID}
parola chiave era supportata. Con questo aggiornamento, è ora possibile usare {State or Category} AB#{ID}
per eseguire automaticamente la transizione degli elementi di lavoro allo stato desiderato durante l'unione.
Se la descrizione della richiesta pull di GitHub include un nome di stato ,ad esempio Validate AB#1234
, lo stato dell'elemento di lavoro collegato verrà aggiornato di conseguenza. Se il nome dello stato non viene riconosciuto, viene verificato se corrisponde a una categoria di stato ( ad esempio Resolved
). In caso affermativo, l'elemento di lavoro viene passato al primo stato disponibile all'interno di tale categoria.
Se non viene trovato alcuno stato o categoria corrispondente, la parola chiave viene ignorata e lo stato dell'elemento di lavoro non verrà aggiornato.
Infine, la Fixes AB#{ID}
parola chiave continua a funzionare come previsto, impostando come predefinito il valore di stato "Chiuso".
Passaggi successivi
Annotazioni
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à. Usa il menu di aiuto per segnalare un problema o fornire un suggerimento.
È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.
Grazie,
Dan Hellem