Lang leve het automatisch downloaden van libraries... JOLO, JOLO, JOLO!!!

Ah shit here we go again

Kunnen de boys die zo over de zeik gaan van curated app stores (Apple, Google) en developers die moeten identificeren hier even komen kijken hoe mooi een volledig open model met free anonymous uploads door iedereen werkt ?

Er is niks mis met het importeren van code, maar houd je dan wel aan de veiligheidsregels:
- Gebruik waar mogelijk betrouwbare bronnen. (Recursief, dus check ook de imports van de imports!)
- Vertrouw je de bron niet, dan lees je de code door voordat je het importeert.
- Set de versie van je import vast, updates moet je handmatig verifiëren.
- Ga ervan uit dat je toch een keertje per ongeluk malware zal uitvoeren en heb dus mitigaties en herstelplannen.

De meeste mensen hebben geen tijd om dat allemaal te doen. laat staan de kennis.

De tijd valt wel mee, eigen registry hosten waarop je de packages proxiet, en daar op laten auditen (kan AI tegenwoordig ook goed). En dat in pipelines douwen, dan hoef je dat niet met de hand te doen.

Wat kennis betreft, beetje devops zou ook verplicht moeten zijn bij het bouwen van een pakket.

En de imports van de imports van de import, en de imports van de imports van de imports van de imports, en ...

Het is een kansloze exercitie. Zoals hierboven al is genoemd: mensen harken miljoenen regels code binnen, al dan niet zonder het te weten, en hebben geen flauw idee wat ze binnen halen. SBOM's zijn bij zeer weinig bedrijven volwassen, programmeurs met beveiligingskennis zijn nauwelijks tot niet aanwezig bij reguliere bedrijven en hebben zeker geen tijd om tienduizenden zo niet honderdduizenden regels door te nemen met fuzzers op zoek naar beveiligingsproblemen, en het patchgedrag is veelal niet om over naar huis te schrijven, zeker niet bij de containers die binnen worden gehaald.

Tuurlijk, er moeten continuiteitsplannen aanwezig zijn voor het geval er een malware-aanval plaatsvindt (of net welke contingency), maar ook die zijn bij zeer veel bedrijven niet aanwezig, dan wel niet getest, dan wel niet up to date.

We zijn op een punt aangekomen dat dit de manier van werken is, en dat we de zaken maar moeten accepteren zoals ze zijn. Het is niet anders. De ellende is groot en wijdverbreid. Dan kun je af en toe een bulletin de deur uit doen, zoals b.v. de CISA of het NCSC doet met "wle patchen hoor!", maar dat is een dfruppel op een gloeiende plaat. Iedereen tevreden met de druppel. Nou ja, dan dansen en feesten we vanuit security vrolijk mee, want ja, anders drukt security zo de uitgelaten sfeer tijdens weer een brakke release die naar prod gaat.

Ik heb a de kennis niet, b de tijd niet om dit soort dingen te doen.

Defineer betrouwbare bronnen, want dit is een hele lastige.

Dit dus. En je gaat bij elke update van een of meerder van je packages dan ook niet nog even recursief alle packages en code changes checken. Je kan een package wel vertrouwen, maar maintainers kunnen ook fouten maken.
Wil niet zeggen dat het geen goed idee is.

Bij het bedrijf waar ik werk hebben we een eigen repository voor "third party code" en een verificatieproces voordat we nieuwe libraries toevoegen. We bouwen alleen tegen de goedgekeurde libraries en gebruiken onze lokale kopie.

De "JOLO" Anoniem

Recente eu wetgeving vereist dat de maker van consumentenproducten (hardware of software of een combinatie van beide) veilige code oplevert. Dit betekend ook dat de maker garant staat en aansprakelijk is voor de gebruikte (openbare) bibliotheken. Er is alleen een uitzondering voor makers van de code bibliotheken die die bibliotheken als opensource en kostenloos aanbieden.
Het implementeren van een onbekende en mogelijk onveilige code bibliotheek in Uw (gratis) software kan het bedrijf eventueel de kop kosten en wanneer de rechtsvorm geen scheiding heeft tussen privé en zakelijk ook Uw woning en pensioenreserve.


Due Named heeft de enige juiste procedure: review alle (obfuscated) bibliotheken.

Vroeger hadden ze een paus die zo heette, en stukjes over gescheven werden, Fransisco. San Fransisco. Iets met Silicon Valleys, en andere verbouwingen daar in CA. (De tijd dat iedereen er aan mee kan doen, en het nog leek te helpen ook! Bij alles wat we deden)

Wormen gerelateerd aan Indonesisch eten, zou de VOC ermee te maken hebben? Of de Conimex-Inproba fabriek in Baarn?

Groet,

Victor.

"waarom" weten alleen de auteurs . "iets" van bestaande woorden is wellicht beter dan random strings, om automated detection wat moeilijker te maken.
Waarom dan indonesische gerechten , tsja. Misschien developers die dat graag eten. Star trek/star wars woorden was nog stereotypischer geweest

Dan ben je geen erantwoordelijke ontwikkelaar maar een copycat.

Dan ben je dus een onverantwoordelijke prutser.

Een serieus te nemen ontwikkelaar / programmeur weet de valkuilen van z'n werk, kan die ontwijken. Als dat kan kun je ook peer review doen...

Ik heb nog een 5e punt voor @Named:
- Zorg dat je op elke gewenst moment een lijst kunt maken van al je gebruikte libraries (met versienummer), ook de libraries die je recursief binnenhaalt.

Dan kun je die als nodig checken tegen de libraries waar een probleem mee is.
En nee, dat is niet hetzelfde als punt 3, want dat zijn alleen je directe dependencies en dat is ook geen lijst die over al je software gaat, maar telkens over een project.

Beetje OT misschien, maar deze Indonesische eten worm, doet mij sterk denken aan de signatuur die Karspersky vond in het stuxnet of flame virus. De makers verwijzingen met data en getallen er in gestopt. Ik kon het niet terugvinden, dus wie weet dat nog. Met een linkje erbij graag, al hoeft niet.