Minder is veiliger: hoe Obsidian het risico van aanvallen op de toeleveringsketen vermindert Aanvallen op de toeleveringsketen zijn kwaadaardige updates die zich een weg banen in open source code die door veel apps wordt gebruikt. Hier is hoe we Obsidian ontwerpen om ervoor te zorgen dat de app een veilige en privé omgeving voor je gedachten is. Minder is veiliger Het mag voor de hand liggend klinken, maar de belangrijkste manier waarop we het risico van aanvallen op de toeleveringsketen verminderen, is door niet afhankelijk te zijn van code van derden. Obsidian heeft een laag aantal afhankelijkheden in vergelijking met andere apps in onze categorie. Zie een lijst van open source bibliotheken op onze Credits-pagina. Functies zoals Bases en Canvas zijn vanaf nul geïmplementeerd in plaats van kant-en-klare bibliotheken te importeren. Dit geeft ons volledige controle over wat er in Obsidian draait. - Voor kleine hulpfuncties implementeren we ze bijna altijd opnieuw in onze code. - Voor middelgrote modules forkeren we ze en houden ze binnen onze codebase als de licenties het toestaan. - Voor grote bibliotheken zoals pdf.js, Mermaid en MathJax, voegen we bekende, versie-gebonden bestanden toe en upgraden we alleen af en toe, of wanneer beveiligingsfixes beschikbaar komen. We lezen release-opmerkingen, kijken naar upstream-wijzigingen en testen grondig voordat we overschakelen. Deze aanpak houdt onze afhankelijkheidsgrafiek ondiep met weinig sub-afhankelijkheden. Een kleiner oppervlak verlaagt de kans dat een kwaadaardige update erdoorheen glipt. Wat er daadwerkelijk in de app zit Slechts een handvol pakketten maakt deel uit van de app die je draait, bijvoorbeeld Electron, CodeMirror, moment.js. De andere pakketten helpen ons de app te bouwen en worden nooit naar gebruikers verzonden, bijvoorbeeld esbuild of eslint. Versie-pinning en lockfiles Alle afhankelijkheden zijn strikt versie-gebonden en gecommitteerd met een lockfile. De lockfile is de bron van waarheid voor builds, zodat we deterministische installaties krijgen. Dit geeft ons een duidelijke audittrail bij het beoordelen van wijzigingen. We voeren geen postinstall-scripts uit. Dit voorkomt dat pakketten willekeurige code uitvoeren tijdens de installatie. Langzame, doordachte upgrades Wanneer we afhankelijkheidsupdates doen,: 1. Lezen we de changelog van de afhankelijkheid regel voor regel. 2. Controleren we sub-afhankelijkheden die door de nieuwe versie zijn geïntroduceerd. 3. Diffen we upstream wanneer de wijzigingsset groot of riskant is. 4. Voeren we geautomatiseerde en handmatige tests uit op verschillende platforms en kritieke gebruikerspaden. 5. Committ de nieuwe lockfile alleen nadat deze beoordelingen zijn goedgekeurd. In de praktijk updaten we zelden afhankelijkheden omdat ze over het algemeen goed werken en geen frequente wijzigingen vereisen. Wanneer we dat doen, behandelen we elke wijziging alsof we een nieuwe afhankelijkheid nemen. Tijd is een buffer We haasten upgrades niet. Er is een vertraging tussen het upgraden van een afhankelijkheid en het uitbrengen van een release. Die kloof fungeert als een vroegtijdige waarschuwing: de gemeenschap en beveiligingsonderzoekers detecteren vaak snel kwaadaardige versies. Tegen de tijd dat we klaar zijn om te verzenden, heeft het ecosysteem meestal problematische releases gemarkeerd. — Geen enkele maatregel kan het risico van de toeleveringsketen volledig elimineren. Maar het kiezen van minder afhankelijkheden, ondiepe grafieken, exacte versie-pins, geen postinstall en een langzame, beoordelingszware upgrade-cyclus samen maken Obsidian veel minder waarschijnlijk om getroffen te worden, en geven ons een lange periode om problemen te detecteren voordat code gebruikers bereikt. Als je nieuwsgierig bent naar onze bredere benadering van beveiliging, zie dan onze beveiligingspagina en eerdere audits.