Mindre er tryggere: hvordan Obsidian reduserer risikoen for angrep i forsyningskjeden Forsyningskjedeangrep er ondsinnede oppdateringer som sniker seg inn i åpen kildekode som brukes av mange apper. Slik designer vi Obsidian for å sikre at appen er et sikkert og privat miljø for tankene dine. Mindre er tryggere Det høres kanskje åpenbart ut, men den primære måten vi reduserer risikoen for forsyningskjedeangrep på er å unngå å være avhengig av tredjepartskode. Obsidian har et lavt antall avhengigheter sammenlignet med andre apper i vår kategori. Se en liste over åpen kildekode-biblioteker på vår Kreditt-side. Funksjoner som baser og kanvas ble implementert fra bunnen av i stedet for å importere hyllebiblioteker. Dette gir oss full kontroll over hva som kjører i Obsidian. - For små verktøyfunksjoner implementerer vi dem nesten alltid på nytt i koden vår. - For mellomstore moduler forgrener vi dem og holder dem inne i kodebasen vår hvis lisensene tillater det. - For store biblioteker som pdf.js, Mermaid og MathJax inkluderer vi kjente gode, versjonslåste filer og oppgraderer bare av og til, eller når sikkerhetsrettinger lander. Vi leser produktmerknader, ser på oppstrømsendringer og tester grundig før vi bytter. Denne tilnærmingen holder avhengighetsgrafen vår grunn med få underavhengigheter. Et mindre overflateareal reduserer sjansen for at en ondsinnet oppdatering slipper gjennom. Hva som faktisk leveres i appen Bare en håndfull pakker er en del av appen du kjører, for eksempel Electron, CodeMirror, moment.js. De andre pakkene hjelper oss med å bygge appen og sender aldri til brukere, for eksempel esbuild eller eslint. Versjonsfesting og låsefiler Alle avhengigheter er strengt versjonsfestet og utført med en låsefil. Låsefilen er kilden til sannhet for bygg, så vi får deterministiske installasjoner. Dette gir oss et enkelt revisjonsspor når vi gjennomgår endringer. Vi kjører ikke skript etter installasjon. Dette hindrer pakker i å kjøre vilkårlig kode under installasjonen. Langsomme, bevisste oppgraderinger Når vi gjør avhengighetsoppdateringer, gjør vi følgende: 1. Les avhengighetens endringslogg linje for linje. 2. Sjekk underavhengigheter introdusert av den nye versjonen. 3. Diff oppstrøms når endringssettet er stort eller risikabelt. 4. Kjør automatiserte og manuelle tester på tvers av plattformer og kritiske brukerveier. 5. Utfør den nye låsefilen først etter at disse vurderingene er bestått. I praksis oppdaterer vi sjelden avhengigheter fordi de vanligvis fungerer og ikke krever hyppige endringer. Når vi gjør det, behandler vi hver endring som om vi tar en ny avhengighet. Tid er en buffer Vi forhaster oss ikke med oppgraderinger. Det er en forsinkelse mellom oppgradering av avhengighet og pushing av en utgivelse. Dette gapet fungerer som et tidlig varselvindu: fellesskapet og sikkerhetsforskere oppdager ofte ondsinnede versjoner raskt. Når vi er klare til å sende, har økosystemet vanligvis flagget eventuelle problematiske utgivelser. — Ingen enkelt tiltak kan eliminere risiko i forsyningskjeden. Men å velge færre avhengigheter, grunne grafer, nøyaktige versjonspinner, ingen etterinstallasjon og en langsom, gjennomgangstung oppgraderingsfrekvens sammen gjør det mye mindre sannsynlig at Obsidian blir påvirket, og gir oss et langt vindu for å oppdage problemer før koden når brukerne. Hvis du er nysgjerrig på vår bredere tilnærming til sikkerhet, kan du se sikkerhetssiden vår og tidligere revisjoner.