Att hämta beroenden direkt från Git löser färre problem än det skapar

Att peka ett projekts beroenden mot en Git-adress istället för npm eller PyPI låter som en genväg förbi supply chain-attacker. I praktiken byter du ut ett känt problem mot flera obekanta. Du får full spårbarhet till exakt kod men förlorar det som paketregister faktiskt bygger, nämligen versionslösning, byggda artefakter och en gemensam måttstock för vad ”version 3.2.1” betyder. För de flesta svenska utvecklare är svaret enkelt: håll dig till registret och hämta från VCS bara när du har en konkret anledning.

Ett paketregister är mer än en nedladdningsplats

Skillnaden märks direkt när du tänker på vad ett register gör som en Git-repo inte gör. npm och PyPI serverar en färdig, publicerad artefakt. Koden är byggd, testad mot ett publiceringsflöde och märkt med en version som följer semantisk versionshantering. När du skriver `^3.2.0` i din `package.json` vet pakethanteraren exakt vilka versioner som räknas som kompatibla och kan räkna ut ett helt beroendeträd åt dig utan att du klonar en enda repo.

En Git-adress ger dig bara en commit. Ingen versionslogik, ingen kompatibilitetsgaranti, ingen automatisk lösning av vad tio olika bibliotek gemensamt kräver. Du får rå källkod, ofta utan de build-steg som paketet normalt går igenom innan det publiceras. Ett TypeScript-bibliotek på npm levereras kompilerat till JavaScript. Samma bibliotek klonat direkt från GitHub kan kräva att du bygger det själv eller så saknas byggresultatet helt.

Det är precis det som händer när team försöker låsa ett beroende till en specifik commit för att slippa registret. De vinner determinism i vilken kod som hämtas men får bygg- och kompatibilitetsproblem i knät istället. Det är samma typ av avvägning som gör att AI förändrar hur utvecklare löser problem i stort, nya verktyg löser inte alltid de problem man tror.

Med VCS flyttar du bara var attackytan finns

Argumentet för VCS är oftast tillit. Efter en rad kapade npm-paket vill fler veta exakt vad de kör. En commit-hash är omöjlig att förfalska på samma sätt som ett omärkt paket i ett register och du ser hela historiken bakom koden. Det finns något i det. GitHub är samtidigt både internets ryggrad och dess största risk och att peka rakt mot en repo betyder att du litar på att kontot bakom den inte kapas.

Problemet är att du inte tar bort attackytan, du flyttar den. I registret litar du på att paketet inte manipulerats efter publicering. Med VCS litar du på att repo-ägarens konto är säkert, att en tvingad `force push` inte skrivit om historiken och att den tagg du pekar mot inte flyttats i tysthet. Git-taggar är inte oföränderliga. En commit-hash är det men då förlorar du samtidigt förmågan att få säkerhetsuppdateringar automatiskt, eftersom hashen är fryst för alltid.

Det stora arbetet med att säkra öppen källkod, som IBM och Red Hats satsning på 5 miljarder dollar, riktar sig mot registrens svagheter av en anledning. Registren är där merparten av koden faktiskt hämtas och det är där skyddet gör mest nytta.

Go visar hur versionslösning borde fungera

Go tog en annan väg än npm och gjorde VCS till en förstklassig källa för moduler. Där hämtas beroenden ofta direkt från Git men språket byggde en tydlig modell runt det. Systemet kallas Minimal Version Selection och väljer den lägsta version som uppfyller alla krav i projektet, i stället för den senaste möjliga. Google beskriver logiken i dokumentationen för Go-moduler.

Poängen är inte att Go hämtar från VCS, utan att språket gav VCS-hämtning en versionsdisciplin. En modulsökväg pekar på en repo, versioner uttrycks som semantiska taggar och en proxy plus en checksumdatabas ser till att du får samma bytes varje gång. Utan det lagret hade du bara haft rå Git-hämtning med alla dess brister.

När det faktiskt är rätt val

Det räcker med att förstå grundprincipen: hämta från VCS när registret inte ger dig det du behöver. Ett internt bibliotek som aldrig ska publiceras publikt hör hemma i din egen Git, inte på npm. En bugg du behöver fixa akut kan pekas mot din egen fork tills patchen är uppe i registret. Ett paket som ligger opublicerat men vars kod du behöver får du bara via repot.

För allt annat är registret rätt. Du får versionslösning, byggda artefakter, snabbare installationer och ett ekosystem av verktyg som scannar efter kända sårbarheter. Byt inte bort det för en känsla av kontroll som visar sig kosta mer i underhåll än den ger i trygghet.

FAQ

Kan jag blanda VCS-beroenden och registerpaket i samma projekt?

Ja. Både npm och pip låter dig peka enstaka beroenden mot en Git-adress medan resten hämtas från registret. Det är vanligt att använda VCS bara för en fork eller ett internt bibliotek och låta allt annat gå via npm eller PyPI som vanligt.

Blir installationen långsammare om jag hämtar från Git?

Oftast ja. En Git-hämtning innebär att pakethanteraren klonar en repo och ibland bygger koden lokalt, medan registret levererar en färdig artefakt över ett nätverk optimerat för just det. Skillnaden märks tydligast i CI-pipelines som installerar beroenden från grunden vid varje körning.

Är en commit-hash säkrare än ett versionsnummer?

En commit-hash är oföränderlig och kan inte peka på annan kod i efterhand, vilket ett flyttbart versionsnummer eller en tagg kan. Nackdelen är att en fryst hash aldrig får säkerhetsuppdateringar automatiskt, så du måste själv hålla koll på och byta ut den när sårbarheter dyker upp.