Mindre är säkrare: hur Obsidian minskar risken för attacker mot leveranskedjan Supply chain-attacker är skadliga uppdateringar som smyger sig in i öppen källkod som används av många appar. Så här designar vi Obsidian för att säkerställa att appen är en säker och privat miljö för dina tankar. Mindre är säkrare Det kan låta självklart, men det främsta sättet att minska risken för attacker i leveranskedjan är att undvika att vara beroende av kod från tredje part. Obsidian har ett lågt antal beroenden jämfört med andra appar i vår kategori. Se en lista över bibliotek med öppen källkod på vår sida Krediter. Funktioner som Bases och Canvas implementerades från grunden istället för att importera färdiga bibliotek. Detta ger oss full kontroll över vad som körs i Obsidian. - För små nyttofunktioner implementerar vi nästan alltid om dem i vår kod. - För medelstora moduler gafflar vi dem och håller dem i vår kodbas om licenserna tillåter det. - För stora bibliotek som pdf.js, Mermaid och MathJax inkluderar vi kända bra, versionslåsta filer och uppgraderar bara ibland, eller när säkerhetskorrigeringar landar. Vi läser viktig information, tittar på ändringar uppströms och testar noggrant innan vi byter. Den här metoden håller vårt beroendediagram grunt med få underberoenden. En mindre yta minskar risken för att en skadlig uppdatering slinker igenom. Vad som faktiskt levereras i appen? Endast en handfull paket är en del av appen du kör, t.ex. Electron, CodeMirror moment.js. De andra paketen hjälper oss att bygga appen och skickar aldrig till användare, t.ex. esbuild eller eslint. Fästa versioner och lås filer Alla beroenden är strikt versionsfästa och checkas in med en låsfil. Låsfilen är sanningskällan för byggen så vi får deterministiska installationer. Detta ger oss en enkel verifieringskedja när vi granskar ändringar. Vi kör inte skript efter installationen. Detta förhindrar paket från att exekvera godtycklig kod under installationen. Långsamma, avsiktliga uppgraderingar När vi gör beroendeuppdateringar gör vi följande: 1. Läs beroendets ändringslogg rad för rad. 2. Kontrollera underberoenden som introduceras av den nya versionen. 3. Diff uppströms när ändringsuppsättningen är stor eller riskfylld. 4. Kör automatiserade och manuella tester på olika plattformar och kritiska användarvägar. 5. Checka in den nya låsfilen först när dessa granskningar har godkänts. I praktiken uppdaterar vi sällan beroenden eftersom de i allmänhet fungerar och inte kräver frekventa ändringar. När vi gör det behandlar vi varje förändring som om vi tog ett nytt beroende. Tiden är en buffert Vi har inte bråttom med uppgraderingar. Det finns en fördröjning mellan uppgradering av ett beroende och push-överföring av en version. Den luckan fungerar som ett fönster för tidig varning: communityn och säkerhetsforskare upptäcker ofta skadliga versioner snabbt. När vi är redo att leverera har ekosystemet vanligtvis flaggat för eventuella problematiska utsläpp. — Det finns ingen enskild åtgärd som kan eliminera riskerna i leveranskedjan. Men att välja färre beroenden, grunda grafer, exakta versionsstift, ingen efterinstallation och en långsam, granskningstung uppgraderingstakt gör Obsidian mycket mindre sannolikt att påverkas och ger oss ett långt fönster för att upptäcka problem innan koden når användarna. Om du är nyfiken på vår bredare syn på säkerhet kan du läsa vår säkerhetssida och tidigare granskningar.