Wat zit er in je code verborgen?

Zelfs eenvoudige projecten kunnen snel groeien en die neiging wordt versterkt door het gemak waarmee bestaande stukjes code of knooppuntbibliotheken kunnen worden geïntegreerd.

Het is nog steeds enigszins beheersbaar als je de enige bent die die code schrijft, maar het wordt moeilijker als de code door een aantal ontwikkelaars en teams wordt geschreven, zoals normaal het geval is.

Zelfs de teamleider, degene die verantwoordelijk is voor het goedkeuren van alle pull-aanvragen, kan niet elke regel code, elke functie en elke variabele kennen.

Een kwestie van vertrouwen

Dat is een van de redenen waarom de kleine codewijziging eind 2020 plaatsvond in de Orion-app, in het geval later bekend als Zonnewinden, bleef zo ​​lang onopgemerkt. De hele verandering bestond uit slechts enkele tientallen regels code, en die waren erg goed verborgen in de oorspronkelijke klasse.

Het gewijzigde product was correct ondertekend, dus er was geen reden om dit te vermoeden, en ontwikkelingsteams vertrouwden op de eigenaar van de code.

Pas onlangs hebben we vernomen dat NPM een “logisch gebrek'waarmee kwaadwillende actoren frauduleuze bibliotheken als legitiem konden laten doorgaan. In principe stond NPM toe dat iemand als beheerder van een pakket kon worden toegevoegd zonder deze gebruikers hiervan op de hoogte te stellen of hun toestemming te verkrijgen. 

Hierdoor konden pakketten met malware worden gemaakt en deze zonder hun medeweten aan vertrouwde, populaire beheerders worden toegewezen. Een geval van misplaatst vertrouwen kan een problematische kwetsbaarheid betekenen die verborgen is in uw code.

Een andere veel voorkomende praktijk om te overwegen is dat ontwikkelaars code uit bestaande bibliotheken of StackOverFlow kopiëren en plakken voor gebruik in hun eigen code of om opnieuw te uploaden naar nieuwe bibliotheken. Als u dat doet, vergroot u de kans dat ook onveilige en kwetsbare code wordt gekopieerd die nu in wezen niet meer wordt gevolgd. Zelfs als de originele code een CVE krijgt en uiteindelijk wordt hersteld, is de problematische functie die je hebt gekopieerd onzichtbaar en kan deze elke codebase besmetten die er jarenlang gebruik van zou maken. 

In een recent onderzoek uitgevoerd aan de Universiteit van Kansas (“Wat de vork? Verborgen codeklonen vinden in npm”), illustreren de onderzoekers hoe het gebruik van zelfs volledig doorgelichte pakketten onveilig kan zijn.

Wat kun je eraan doen?

U kunt de ondertekende producten en updates van leveranciers dus niet vertrouwen. Het kan zijn dat uw eigen code al is aangepast of aangevuld, vanwege al die externe bibliotheken en code die erin zijn verwerkt. Wat kunt u dan doen om er echt zeker van te zijn dat u geen kwaadaardige bestanden op uw systeem installeert?

Er zijn een paar dingen die u kunt doen:

1. Vraag een volledige SBOM aan bij elke bibliotheekeigenaar of programmaleverancier die u opneemt. Een SBOM kan u helpen erachter te komen wat alle 'ingrediënten' in de bibliotheek of het product zijn. Als u bovendien iets in de bibliotheek of het product vindt dat niet in de SBOM staat, moet dit als verdacht worden beschouwd. U kunt meer leren over wat een SBOM is hier.
2. Vraag een vertrouwde verklaring aan van de leverancier of bibliotheekeigenaar dat er een integriteitscontrole is uitgevoerd en dat u krijgt wat u verwacht. U hoeft niet alleen op de eigen verzekering van de verkoper te vertrouwen.
   
3. Gebruik bij het installeren van pakketten de npm CLI-vlag --ignore-scripts om te voorkomen dat scripts van pakketten van derden worden uitgevoerd tijdens de installatiefase.
4. Gebruik een pakket-lock.json bestand om pakketversienummers te vergrendelen. Wanneer u gebruik maakt van een pakket-lock.json u vergrendelt niet alleen de pakketversies die u gebruikt, maar ook hun afhankelijkheden. Het risico is dat u geen geautomatiseerde pakketupdates binnenhaalt die oplossingen voor verschillende bugs kunnen bevatten. Maar als u veel moeite heeft gedaan om een ​​bepaalde versie te verifiëren en niets anders wilt toevoegen zonder deze eerst te verifiëren, dan is het vergrendelen van uw versienummers de beste optie.

volgend nieuwe voorschriftenwordt verwacht dat de meeste mensen in de zeer nabije toekomst SBOM’s zullen gaan gebruiken. Hoe meer bedrijven om SBOM’s en andere attesten zullen vragen, hoe meer organisaties en beheerders hieraan zullen moeten voldoen.