GitHub en PyPI vertragen voortaan updates om hackers minder ruimte te geven. Beide platformen bouwden een nieuwe tijdslimiet in hun software. GitHub geeft zijn tool Dependabot een standaard wachttijd van drie dagen. PyPI weigert nieuwe bestanden bij releases die ouder zijn dan veertien dagen. De twee maatregelen lijken klein, maar raken een hardnekkig probleem. Aanvallers misbruiken namelijk de snelheid waarmee ontwikkelaars nieuwe pakketten binnenhalen. Wie automatisch de nieuwste versie installeert, haalt soms binnen enkele minuten kwaadaardige code binnen. Door bewust te wachten, krijgen beveiligingsonderzoekers tijd om die code te ontdekken. GitHub en PyPI kiezen dus voor vertraging als verdedigingsmiddel.
De aanleiding ligt in een reeks aanvallen van het afgelopen jaar. Beide ecosystemen kregen meerdere keren te maken met zogeheten supply chain-aanvallen. Daarbij kapen criminelen een populair softwarepakket waarvan duizenden projecten afhankelijk zijn. Bekende voorbeelden zijn de aanvallen op de npm-pakketten ‘chalk’ en ‘debug’. Ook de operatie ‘s1ngularity’, de campagne ‘Shai-Hulud’ en de aanval ‘GhostAction’ richtten schade aan. Telkens verspreidde de schadelijke code zich razendsnel via automatische updates. GitHub kondigde vorige maand al veranderingen aan om npm beter te beveiligen. De nieuwe tijdmaatregelen vormen de volgende stap in dat proces. PyPI, de officiële pakketbron voor Python, sluit zich daar nu bij aan.
Dependabot is de updatedienst van GitHub voor softwareafhankelijkheden. De tool leest bestanden waarin staat welke pakketten een project gebruikt. Zodra een pakket een nieuwe versie krijgt, opent Dependabot een pull request. Beheerders zien zo direct dat er een update klaarstaat. Precies die snelheid vormde tot nu toe een risico. Een aanvaller die een kwaadaardige versie publiceert, kreeg zo gratis een uitnodiging in duizenden projecten. De nieuwe wachttijd van 72 uur haalt die vanzelfsprekendheid weg. Dependabot stelt het updatevoorstel simpelweg drie dagen uit. In die periode kunnen beveiligingsbedrijven en beheerders het pakket alsnog van het platform halen.
Beveiligingstools ontdekken schadelijke npm-pakketten vaak binnen enkele minuten. Toch verdwijnt de dreiging daarmee niet meteen. Beheerders en leveranciers moeten het pakket namelijk nog handmatig verwijderen. Tussen de ontdekking en het opruimen zit dus een kwetsbaar tijdvenster. In dat venster halen ontwikkelaars de besmette code alsnog binnen. GitHub noemt drie dagen een evenwicht tussen veiligheid en actualiteit. Wachten beschermt tegen riskante releases, maar te lang wachten houdt verbeteringen tegen. Gebruikers bepalen zelf een kortere of langere termijn via de instelling ‘cooldown’. Wie snel wil blijven werken, verkort de wachttijd dus eenvoudig.
GitHub wijst zelf op de grenzen van deze aanpak. Een wachttijd helpt niet tegen een aanvaller die maanden onopgemerkt blijft. Bij zo’n langdurige compromittering biedt drie dagen geen enkele bescherming. Het bedrijf raadt daarom aanvullende maatregelen aan. Ontwikkelaars leggen versies het beste vast in zogeheten lockfiles. Zo pinnen zij precies welke versie hun project gebruikt. Daarnaast adviseert GitHub tokens met een beperkte reikwijdte. Zo’n token geeft een aanvaller minder mogelijkheden na diefstal. Tot slot schakelen teams onnodige installatiescripts beter uit in hun CI-omgeving. Juist die scripts voeren kwaadaardige code vaak ongemerkt uit.
PyPI kiest voor een andere invalshoek met een grens van veertien dagen. Beheerders voegen na die periode geen nieuwe bestanden meer toe aan een release. De maatregel richt zich op zogeheten release poisoning. Bij die techniek vergiftigt een aanvaller een oude, vertrouwde versie van een pakket. Daarvoor gebruikt hij een gestolen publicatietoken of een gekaapte workflow. Ontwikkelaars vertrouwen zo’n bestaande release meestal blind. PyPI onderzocht hoe vaak beheerders legitiem later bestanden uploaden. Slechts een zeer klein deel van de projecten doet dat na twee weken. De hinder blijft dus beperkt, terwijl het risico flink daalt.
Opvallend genoeg reageert PyPI niet op een concreet incident. Het platform bevestigde geen enkele eerdere aanval via release poisoning. Toch sluit het die route nu preventief af. Die keuze past bij een bredere verschuiving in de opensourcewereld. Beheerders wachten niet langer op schade, maar dichten gaten vooraf. Voor ontwikkelaars betekenen beide maatregelen vooral een kleine gewenning. Updates verschijnen iets later en oude releases liggen sneller vast. Daar staat een duidelijk voordeel tegenover. Automatische verspreiding van kwaadaardige pakketten verloopt daardoor een stuk moeizamer. Wie zijn softwareketen echt wil beschermen, combineert deze rem met pinning en strak tokenbeheer.
