In che modo un monitor ha pubblicato vulnerabilità in un piccolo team di sviluppo?

A livello di scala, è meglio controllare continuamente l'automazione, ma la parte più importante: l'automazione

Per RHEL, CentOS, Fedora, e così via c'è yum-cron. Puoi anche specificare la severità della sicurezza: critica se desideri solo patch critiche.

Per Debian, Ubuntu, ecc. ci sono aggiornamenti non presidiati con concetti simili.

Se crei applicazioni o installa app personalizzate, assicurati di essere coperto anche da lì. Inoltre, c'è l'infrastruttura per garantire l'applicazione delle patch. Automatizzarlo il più possibile. La gente sosterrà che questo può rompere le cose. Ecco perché ti consiglio di automatizzare il più possibile - ma non così tanto da rompere le cose. Se si installano automaticamente solo patch di sicurezza critiche, è molto meno probabile che si verifichino problemi. Scopri come automatizzarlo almeno così tanto. Anche se si ha una politica che non si automatizza direttamente senza approvazione umana: automatizza la raccolta di tutte le informazioni, scarica le patch e dispone di un meccanismo di spinta o di trazione, pronto per l'attivazione dei capelli.

OWASP ha un sacco di ottime capacità di integrazione tramite Controllo dipendenza - con anche un'interfaccia web per questo attraverso questo progetto - link

Si possono integrare concetti simili per costruire server e progetti di integrazione continua / implementazione continua molto facilmente. Questi ambienti sono attrezzati per questo tipo di automazione. Esistono anche molte soluzioni commerciali: è facile trovarle online.

Non sono a conoscenza di tale servizio che potrebbe essere adattato alle esigenze comunicate, sebbene non sia sicuro che l'intelligenza esista per crearne una che fornisca valore senza un'attenzione continua significativa da parte del consumatore.

Posso pensare a 4 gruppi di fonti di informazione a cui prestare attenzione, elencati di seguito. A meno che le circostanze specifiche della tua attività richiedano attenzione a noi-cert, bugtraq o cvedetails, non includerei quelle in un elenco di fonti utili.

I 4 set sono:

• sistema operativo
• fornitore di infrastrutture
• singoli fornitori di software
• piattaforma di sviluppo / librerie

La regola generale è che, in assenza di una fonte aggregabile configurabile, le principali fonti individuali a cui prestare attenzione sono i fornitori del software e dell'infrastruttura utilizzati, sia in un contesto operativo che in un contesto di sviluppo. Per quelli, segui entrambi gli elenchi specifici di sicurezza e comunicati, oltre al loro blog tecnico generale. Il blog di Ubuntu è dove sono state distribuite notizie sulla loro risposta a POODLE (es. link ).

Il sistema operativo è uno strato in questo sandwich. Sotto il sistema operativo, se i server sono virtualizzati in un ambiente cloud, questa regola comprende il provider di cloud: AWS, Google, Digital Ocean, ecc. AWS in generale ha blog per ciascun servizio principale: quelli che comunicano informazioni rilevanti da un contesto di sicurezza .

Se la piattaforma di virtualizzazione o cloud include anche container, vale la pena seguire gli annunci di blog, sicurezza e rilasci del provider di contenitori upstream - Docker, contenitori Linux, ecc.

Sopra il sistema operativo sono singole applicazioni. Questi possono essere forniti dal fornitore del sistema operativo ma sono comunque fonti indipendenti di notizie e informazioni, poiché il filtro di curazione del provider del sistema operativo escluderà il contesto importante relativo alle funzionalità e alla configurazione di queste applicazioni.

L'importanza di occuparsi di questi dipende dal loro ruolo nella tua infrastruttura e il loro ruolo può essere valutato su due dimensioni-

• quanto sono visibili a fonti di traffico potenzialmente dannose
• quanto sono importanti in termini di protezione del tuo sostentamento

Potresti avere un database importante che a sua volta non è esposto pubblicamente a traffico potenzialmente malevolo, ma è comunque desiderabile partecipare alle loro versioni, all'elenco di sicurezza e al blog tecnico in quanto importanti informazioni di configurazione architetturale e difensiva verranno comunicate lì che non verranno vieni attraverso altre fonti.

Allo stesso modo, probabilmente esegui server web nginx o apache e qualche tipo di server applicazioni. Ubuntu, naturalmente, raccoglie ed elabora le informazioni dalle versioni, dagli annunci sulla sicurezza e dai blog tecnici di questi progetti, ma anche in questo caso il loro filtro di curazione escluderà specifici problemi di configurazione e implementazione che questi progetti informeranno direttamente sui loro utenti.

Come negozio di sviluppo web, presumibilmente il tuo team lavora su una o più piattaforme - Nodo, Rails, Spring, React, qualunque cosa - consumando le versioni di piattaforma dei principali fornitori e anche degli sviluppatori di librerie che operano in quell'ecosistema e poi produrre software per i tuoi clienti. Seguendo gli annunci e il blog sia della piattaforma che dei fornitori di biblioteche di cui si consuma il lavoro e tenersi aggiornati sulle dipendenze, è importante. Qui ci sono alcuni nuovi servizi che si concentrano sulla ricerca e la cura delle vulnerabilità rilevate attraverso l'analisi statica delle piattaforme e delle librerie di sviluppo, e quindi l'integrazione di tali informazioni in flussi di lavoro di integrazione / consegna continui: questi servizi meritano considerazione per il tuo team.

La regola generale è di nuovo- se si consuma un servizio o un'applicazione come dipendenza nella propria infrastruttura operativa, o se si consuma un'applicazione o una libreria nella propria infrastruttura di sviluppo, quindi seguendo gli annunci di quei specifici fornitori upstream è a questo attuale stato di maturità del settore importante per la sicurezza.

I provider downstream che confezionano e distribuiscono software da upstream in genere non risolvono i casi di utilizzo di configurazione e distribuzione che sono sensibili alla sicurezza e che i fornitori di software upstream dedicano molto tempo a riflettere.

Infine, questo è un sacco di materiale potenziale da seguire, che a sua volta è un punto importante sulla superficie di attacco. Poiché tutto il software contiene vulnerabilità, più si consuma e si utilizza la superficie di attacco più ampia diventa. Consumare un software per la sua funzionalità e non partecipare al suo flusso a monte è una forma di debito tecnico fuori bilancio.

Spero che sia utile.

In passato ho adottato un approccio un po 'diverso.

Dato che i distributori di Linux stanno attivamente monitorando le sorgenti upstream per le nuove versioni ho usato il sistema di gestione dei pacchetti (nel mio caso yast mentre stavo eseguendo SuSe) dalla riga di comando per elencare tutti gli aggiornamenti richiesti.

Non mi fido di questo ciecamente; ho invece controllato una cronologia degli aggiornamenti confrontando il ritardo tra il CVE in fase di pubblicazione e un aggiornamento in fase di pubblicazione. Il divario è stato nella media di 3 giorni. Tuttavia, riconosco che una patch rilasciata rapidamente non è garantita e che spesso esistono altre mitigazioni disponibili oltre ad aspettare una correzione da parte del fornitore (qualcosa che diverse società di software di grandi dimensioni non sembrano riconoscere).

Non sono esportato su apt, ma mi aspetto che dovrebbe essere possibile identificare gli aggiornamenti richiesti usando attitudine .