Usiamo un bel po 'di librerie open source esterne nei nostri progetti, prelevate da Maven Central ecc.
Mi chiedevo quale sia la prassi migliore per assicurarti di non introdurre alcun tipo di rischio per la sicurezza utilizzando queste dipendenze. Ne abbiamo parecchie e non è realistico riscrivere queste librerie.
Non sono sicuro che sia pertinente, ma in particolare sto parlando dello sviluppo mobile: app IOS e Android
Entrambi i framework e le librerie che usi hanno vulnerabilità. Alcune di queste vulnerabilità possono essere sfruttate per ottenere accesso non autorizzato alla tua applicazione / server / risorse.
Questo fatto, tuttavia, non significa che dovresti buttarli via e sviluppare un prodotto indipendente che non ha dipendenze.
La domanda che dovresti porre non è se introduci un rischio per la sicurezza usando una dipendenza, ma piuttosto se riesci a sostituire una dipendenza con una soluzione interna più sicura di la dipendenza .
Nella maggior parte dei casi, la risposta è quasi ovvia.
Se stai pensando a librerie e strutture sviluppate da società rinomate nel corso degli anni, o a quelle create da grandi comunità open source, è probabile che riescano a batterle in termini di sicurezza con una soluzione interna. Il loro codice è stato accuratamente testato, revisionato dal codice e regolarmente aggiornato.
Ho detto " quasi ovvio", perché c'è una cosa che puoi opporre a quelle librerie: molte persone guardano ai modi per sfruttarle e le vulnerabilità zero day potrebbero avere un impatto enorme su tutte le applicazioni che usano quelle librerie. La tua soluzione interna, probabilmente a codice chiuso, probabilmente non è così interessante per un utente malintenzionato ed è più oscura. Questo ti dà l'impressione di un leggero vantaggio; tuttavia, la sicurezza per oscurità è un noto anti-pattern, e se l'oscurità è l'unica cosa tra il tuo codice e l'attaccante, sei nei guai.
A volte è più complicato.
Se stai pensando alle biblioteche che non hanno molta attenzione o supporto, allora ci sono possibilità che tu possa fare di meglio se la biblioteca si occupa del tuo dominio di competenza. Essere in grado di vedere il codice sorgente può essere molto utile e mostrare la fonte a un esperto di sicurezza è il modo migliore per capire bene il livello di rischio associato all'uso della libreria.
Se sembra che la libreria contenga vulnerabilità possibili (o ovvie), puoi decidere di riscriverla da zero se la biblioteca viene abbandonata o è closed-source o contribuisce alla libreria per risolvere le vulnerabilità che altrimenti noti. Gli sviluppatori spesso dimenticano questa seconda soluzione, mentre di solito è la più economica e beneficia non solo di te, ma dell'intera comunità.
Leggi altre domande sui tag security code-security