Quando pensi alla scansione dei segreti, la maggior parte delle persone pensa immediatamente ai repository di codice sorgente su piattaforme come GitHub, Gitlab e Bitbucket. Mentre la base di codice è una fonte che dovresti assolutamente monitorare, questa è solo una parte della storia di sicurezza dei segreti complessivi.
In effetti, i segreti che perde nel codice sono una delle principali preoccupazioni. Nel Gitguardian’s 2025 Rapporto sullo stato dei segreti Sprawlla scala di questo problema è aumentata drammaticamente. Solo nel 2024, oltre 23,7 milioni di nuovi segreti hardcoded sono stati aggiunti ai repository di GitHub pubblici – a Aumento del 25% Dall’anno precedente. E questo è solo GitHub.
Tuttavia, questa non è la storia completa. Il rapporto mostra anche che le molte esposizioni di segreti critici di oggi non sono nel tuo codice; Sono nei tuoi strumenti di collaborazione. Piattaforme come Lento, Jira, Confluenzae altri strumenti di gestione e produttività dei progetti sono diventati zone advert alto rischio per credenziali trapelate. Ancora peggio, i segreti trovati in questi sistemi hanno maggiori probabilità di essere critici, più difficili da rilevare e quasi del tutto distinti dalle credenziali in chiaro trovate nel codice sorgente.
I segreti sono tentosi ovunque si verificano lavori
In una tradizionale mentalità di sicurezza, Gestione dei segreti Inizia e termina nel repository. Una volta che il tuo staff ha adottato una soluzione di Vault e stai scansionando il codice e le pipeline CI/CD, sei sulla buona strada per segreti la maturità della gestione.
Se hai convinto i tuoi sviluppatori a standardizzare su strumenti di prevenzione come la scansione GIT pre-commit o gli strumenti incorporati nel loro editor di codice preferito, hai raggiunto un traguardo importante per una migliore sicurezza dei segreti.
La realtà è quella I segreti perdono in ogni strumento che il tuo staff tocca, Non solo piattaforme di codice e CI/CD ma attraverso l’space di lavoro digitale completa. App di messaggistica, sistemi di biglietteria, wiki interni e persino registri container sono ora campi di battaglia attivi per l’esposizione alle credenziali.
Nel nostro rapporto sullo stato dei segreti del 2025, abbiamo scoperto il fatto che:
- Il 38% dei segreti trovati negli strumenti di collaborazione erano classificato come critico o urgente, Rispetto al 31% nel codice sorgente.
- Solo il 7% dei segreti si sovrappone tra SCM (gestione del codice sorgente) e strumenti di collaborazione: questi sono per lo più esposizioni completamente separate.
Quest’ultimo fatto è estremamente allarmante e suggerisce che questi segreti potrebbero essere archiviati correttamente altrimenti ma vengono copiati in chiaro in strumenti di flusso di lavoro al di fuori della base di codice. Diamo un’occhiata più da vicino a quali sistemi sono coinvolti.
Piattaforme di messaggistica: Slack e Microsoft Groups
La chat è veloce. La chat è informale. Ed è esattamente per questo che è pericoloso. Slack continua advert essere uno dei più noti hotspot per la perdita di segreti, specialmente in incidenti in tempo reale, ingegneria di ingegneria o submit mortem. Ma non è più solo. Microsoft Groupsora una piattaforma di base in molti ambienti aziendali, affronta gli stessi rischi.
Gli sviluppatori spesso condividono le credenziali rapide per aiutare i compagni di squadra a debug senza pensare a ciò che accade se vengono violati. Troppo spesso, una volta che gli account di servizio o i token API sono pubblicati in thread, sono completamente dimenticati, ma questi thread rimangono persistenti negli ambienti aziendali per anni. La cronologia dei messaggi viene mantenuta indefinitamente in molte organizzazioni, esponendo segreti che a volte sono Mai ruotato.
I staff di sicurezza non mancano spesso le capacità di accesso o di scansione in questi ecosistemi di messaggistica. E a differenza dei repository di codice, non esiste un concetto di richieste o recensioni pull, solo un flusso infinito di testo, file e collegamenti non monitorati.
Sistemi di biglietteria: Jira e ServiceNow
Mentre JIRA è stata a lungo una piattaforma di pianificazione centrale per molti staff di sviluppo, ServiceNow sta rapidamente emergendo come un vettore di rischio critico, in particolare nelle operazioni IT, nella sicurezza e nei flussi di lavoro di supporto.
In entrambi i sistemi, Secrets and techniques superficie quando i staff di supporto incollano le credenziali per riprodurre bug o assistere i clienti. Gli ingegneri troppo spesso attaccano tronchi contenenti intestazioni o token sensibili, il che ha senso in superficie, poiché le squadre corrono per trovare trigger alla radice e combattere gli incendi, ma la scia di segreti che lasciano dietro è un incubo in attesa di accadere.
Entrambe le piattaforme sono spesso percepite come “solo interne” o “sicure”, ma la storia mostra il contrario. I biglietti sono trascurati negli audit di accesso, sono difficili da monitorare su vasta scala e diventano repository a lungo termine per i segreti dimenticati.
Infatti, 6,1% dei biglietti JIRA Analizzato nello studio conteneva segreti, molti dei quali erano ancora validi al momento del rilevamento.
ServiceNow presenta rischi simili, soprattutto a causa della sua forte integrazione con flussi di lavoro di automazione e utenti non tecnici che potrebbero non riconoscere un segreto quando ne vedono uno.
Piattaforme di documentazione: confluenza
La confluenza rimane una parte critica del moderno stack di collaborazione, fornendo un modo semplice e semplice per tutti di documentare le proprie conoscenze in una piattaforma ricercabile e centralizzata. Sfortunatamente se i staff stanno anche posizionando le loro credenziali in chiaro nel proprio wiki interno, diventa una grande responsabilità.
È un luogo comune per trovare information di configurazione dell’ambiente con segreti reali incorporati. È facile aggiungere diagrammi di architettura che includono token di accesso o stringhe di connessione del database per comodità. Per i staff che si stanno rapidamente espandendo o piegando i nuovi membri a causa di un’acquisizione, la documentazione di onboarding potrebbe contenere credenziali “solo per far funzionare le persone”.
Questi documenti sono persistenti, raramente aggiornati e spesso trascurati nelle revisioni della sicurezza. Una volta che un segreto atterra in una pagina di confluenza, è indicizzato, ricercabile e disponibile per chiunque abbia le autorizzazioni di accesso, che sono spesso ampie per impostazione predefinita. Se un aggressore ottiene l’accesso, i segreti sono la prima cosa che cercheranno.
Perché gli strumenti di collaborazione sono così pericolosi per i segreti
Ci sono tre motivi chiave per cui le piattaforme di collaborazione sono ambienti particolarmente pericolosi per l’espansione segreta:
1. Non erano costruiti pensando ai segreti
Questi strumenti danno la priorità alla produttività e alla velocità, non alla gestione di informazioni sicure. A differenza delle piattaforme di gestione del controllo delle fonti, strumenti come Slack o JIRA non hanno alcuna scansione dei segreti nativi, scoping di accesso o protezioni pre-sottoposto. Mentre la scansione pre-commit è possibile automatizzare in un flusso di lavoro degli sviluppatori, impedire l’incollaggio di una credenziale in chiaro in un campo di testo in un biglietto o una finestra di chat è quasi impossibile da prevenire.
2. Troppe mani, troppo poca consapevolezza
I segreti non perdono solo gli sviluppatori. I product supervisor, il personale di supporto, gli ingegneri di controllo qualità e praticamente tutti gli altri con accesso possono incollare inconsapevolmente credenziali sensibili in un biglietto o thread. Una volta pubblicati, quei segreti possono vivere per sempre, sepolti nel backlog.
3. Nessun ciclo di vita efficace per ciò che viene condiviso
In una base di codice, un segreto con codice rigido può essere contrassegnato, ruotato e sostituito. In Slack? Story segreto può essere ripubblicato su più canali, condiviso in screenshot o addirittura appuntato. È invisibile alla maggior parte tradizionale Strumenti di rilevamento dei segreti e completamente al di fuori di normali flussi di lavoro di revisione del codice.
Il falso senso di sicurezza negli spazi privati
Uno dei presupposti più pericolosi che le organizzazioni fanno è credere che, poiché uno spazio è privato, è sicuro. Ma i biglietti privati JIRA, i canali di allentamento interno e gli spazi di confluenza limitati non immune al compromesso. Attacchi di phishing, furto di token e movimento laterale possono dare agli aggressori l’accesso agli strumenti interni, in cui i segreti sono semplicemente seduti lì, spesso non monitorati.
Nell’analisi di Gitguardian, i repository privati avevano 8 volte più probabilità di contenere segreti rispetto a quelli pubblici. La stessa tendenza vale per gli strumenti di produttività. Le persone si comportano più con noncuranza in spazi privati, supponendo che l’oscurità sia uguale alla sicurezza.
Come gestire le perdite dei segreti al di fuori del codice
Come con tutto il resto in sicurezza, la soluzione Richiede che allineiamo persone, processi e strumenti. Questo inizia con consapevolezza. Anche leggere questo articolo è un passo nella giusta direzione. Assicurarsi che la tua squadra sia a conoscenza dei pericoli è un primo passo molto positivo verso l’eliminazione dei problemi prima che inizino.
Tuttavia, la sola consapevolezza non è la soluzione. Il playbook per affrontare questa sfida prevede anche:
- Distribuzione del rilevamento di segreti in tempo reale su Slack, JIRA e Confluence utilizzando strumenti che sono costruiti appositamente per le piattaforme di collaborazione.
- Consolidare gli avvisi tra i sistemi: non trattare un segreto in Slack e Jira come incidenti separati se sono le stesse credenziali.
- Agisci velocemente: le credenziali valide vengono spesso sfruttate entro poche ore dall’esposizione. I flussi di lavoro di rotazione e revoca dovrebbero essere automatizzati ove possibile.
- Stabilire i playbook interni per la gestione dei segreti trovati in ambienti non codi e assegnare una chiara proprietà per la bonifica.
Richiedi più produttività e meno perdite dagli strumenti di collaborazione
Lo stack di produttività del tuo staff sta diventando la tua più grande superficie di attacco non monitorata.
Non è solo che i segreti finiscono su queste piattaforme; È che sono condivisi in situazioni advert alta urbenza, da un gruppo più ampio di utenti e con molte meno garanzie in atto. Dal debug alle distribuzioni all’onboarding, i segreti vengono copiati, incollati e dimenticati negli spazi non intesi per assicurarli.
E gli aggressori lo sanno.
