Meno è più sicuro: come Obsidian riduce il rischio di attacchi alla catena di fornitura Gli attacchi alla catena di fornitura sono aggiornamenti malevoli che si infiltrano nel codice open source utilizzato da molte app. Ecco come progettiamo Obsidian per garantire che l'app sia un ambiente sicuro e privato per i tuoi pensieri. Meno è più sicuro Può sembrare ovvio, ma il modo principale in cui riduciamo il rischio di attacchi alla catena di fornitura è evitare di dipendere da codice di terze parti. Obsidian ha un numero ridotto di dipendenze rispetto ad altre app nella nostra categoria. Consulta un elenco delle librerie open source nella nostra pagina Crediti. Funzionalità come Bases e Canvas sono state implementate da zero invece di importare librerie pronte all'uso. Questo ci dà il pieno controllo su ciò che viene eseguito in Obsidian. - Per piccole funzioni di utilità, quasi sempre le re-implementiamo nel nostro codice. - Per moduli medi, li fork-iamo e li manteniamo all'interno del nostro codice se le licenze lo consentono. - Per grandi librerie come pdf.js, Mermaid e MathJax, includiamo file noti e bloccati per versione e aggiorniamo solo occasionalmente, o quando arrivano correzioni di sicurezza. Leggiamo le note di rilascio, guardiamo i cambiamenti upstream e testiamo a fondo prima di effettuare il passaggio. Questo approccio mantiene il nostro grafo delle dipendenze poco profondo con poche sotto-dipendenze. Una superficie più piccola riduce la possibilità che un aggiornamento malevolo sfugga. Cosa viene effettivamente spedito nell'app Solo un numero limitato di pacchetti fa parte dell'app che esegui, ad esempio Electron, CodeMirror, moment.js. Gli altri pacchetti ci aiutano a costruire l'app e non vengono mai spediti agli utenti, ad esempio esbuild o eslint. Blocco delle versioni e lockfile Tutte le dipendenze sono rigorosamente bloccate per versione e impegnate con un lockfile. Il lockfile è la fonte di verità per le build, quindi otteniamo installazioni deterministiche. Questo ci fornisce una chiara traccia di audit quando rivediamo le modifiche. Non eseguiamo script postinstall. Questo impedisce ai pacchetti di eseguire codice arbitrario durante l'installazione. Aggiornamenti lenti e deliberati Quando facciamo aggiornamenti delle dipendenze, noi: 1. Leggiamo il changelog della dipendenza riga per riga. 2. Controlliamo le sotto-dipendenze introdotte dalla nuova versione. 3. Diff upstream quando il set di cambiamenti è grande o rischioso. 4. Eseguiamo test automatizzati e manuali su piattaforme e percorsi utente critici. 5. Impegniamo il nuovo lockfile solo dopo che queste revisioni sono state superate. In pratica, aggiorniamo raramente le dipendenze perché generalmente funzionano e non richiedono cambiamenti frequenti. Quando lo facciamo, trattiamo ogni cambiamento come se stessimo prendendo una nuova dipendenza. Il tempo è un buffer Non affrettiamo gli aggiornamenti. C'è un ritardo tra l'aggiornamento di qualsiasi dipendenza e la pubblicazione di una release. Quella lacuna funge da finestra di avviso precoce: la comunità e i ricercatori di sicurezza spesso rilevano rapidamente versioni malevole. Quando siamo pronti a spedire, l'ecosistema ha solitamente segnalato eventuali rilasci problematici. — Nessuna singola misura può eliminare il rischio della catena di fornitura. Ma scegliere meno dipendenze, grafi poco profondi, pin di versione esatti, nessun postinstall e un ritmo di aggiornamento lento e ricco di revisioni insieme rendono Obsidian molto meno probabile che venga impattato e ci danno una lunga finestra per rilevare problemi prima che il codice raggiunga gli utenti. Se sei curioso riguardo al nostro approccio più ampio alla sicurezza, consulta la nostra pagina sulla sicurezza e le audit passate.