Mai puțin este mai sigur: cum reduce Obsidian riscul de atacuri ale lanțului de aprovizionare Atacurile lanțului de aprovizionare sunt actualizări rău intenționate care se strecoară în codul sursă deschis folosit de multe aplicații. Iată cum proiectăm Obsidian pentru a ne asigura că aplicația este un mediu sigur și privat pentru gândurile tale. Mai puțin este mai sigur Poate părea evident, dar principalul mod în care reducem riscul de atacuri ale lanțului de aprovizionare este să evităm dependența de codul terților. Obsidian are un număr scăzut de dependențe în comparație cu alte aplicații din categoria noastră. Vedeți o listă de biblioteci open source pe pagina noastră de credite. Funcții precum Bases și Canvas au fost implementate de la zero în loc să importe biblioteci standard. Acest lucru ne oferă control deplin asupra a ceea ce rulează în Obsidian. - Pentru funcțiile utilitare mici, aproape întotdeauna le reimplementăm în codul nostru. - Pentru modulele medii le bifurcăm și le păstrăm în baza noastră de cod dacă licențele permit acest lucru. - Pentru biblioteci mari precum pdf.js, Mermaid și MathJax, includem fișiere bine cunoscute, blocate de versiune și actualizăm doar ocazional sau când ajung remedieri de securitate. Citim notele de lansare, ne uităm la modificările din amonte și testăm temeinic înainte de a comuta. Această abordare menține graficul nostru de dependență superficial, cu puține subdependențe. O suprafață mai mică scade șansa ca o actualizare rău intenționată să se strecoare prin el. Ce se livrează de fapt în aplicație Doar câteva pachete fac parte din aplicația pe care o rulați, de exemplu Electron, CodeMirror moment.js. Celelalte pachete ne ajută să construim aplicația și să nu le livrăm niciodată utilizatorilor, de exemplu esbuild sau eslint. Fixarea versiunilor și blocarea fișierelor Toate dependențele sunt strict fixate pe versiune și validate cu un fișier de blocare. Fișierul de blocare este sursa de adevăr pentru construcții, astfel încât să obținem instalări deterministe. Acest lucru ne oferă o pistă de audit simplă atunci când revizuim modificările. Nu rulăm scripturi post-instalare. Acest lucru împiedică pachetele să execute cod arbitrar în timpul instalării. Upgrade-uri lente și deliberate Când facem actualizări de dependență, noi: 1. Citiți jurnalul de modificări al dependenței rând cu rând. 2. Verificați subdependențele introduse de noua versiune. 3. Diferența în amonte atunci când setul de modificări este mare sau riscant. 4. Rulați teste automate și manuale pe platforme și căi critice ale utilizatorilor. 5. Confirmați noul fișier de blocare numai după ce trec aceste recenzii. În practică, rareori actualizăm dependențele, deoarece acestea funcționează în general și nu necesită modificări frecvente. Când o facem, tratăm fiecare schimbare ca și cum am lua o nouă dependență. Timpul este un tampon Nu ne grăbim să facem upgrade-uri. Există o întârziere între actualizarea oricărei dependențe și împingerea unei versiuni. Acest decalaj acționează ca o fereastră de avertizare timpurie: comunitatea și cercetătorii de securitate detectează adesea rapid versiunile rău intenționate. Până când suntem gata de livrare, ecosistemul a semnalat de obicei orice lansări problematice. — Nicio măsură nu poate elimina riscul lanțului de aprovizionare. Dar alegerea mai puținelor dependențe, grafice superficiale, pini de versiune exacti, fără postinstalare și o cadență de actualizare lentă și grea de recenzii fac ca Obsidian să fie mult mai puțin probabil să fie afectat și ne oferă o fereastră lungă pentru a detecta problemele înainte ca codul să ajungă la utilizatori. Dacă sunteți curios despre abordarea noastră mai largă în materie de securitate, consultați pagina noastră de securitate și auditurile anterioare.