GitHub overspoeld met malafide repository's

GitHub wordt al maanden overspoeld met malafide repository's als onderdeel van een zogeheten dependencyconfusionaanval, stellen securityonderzoekers van beveiligingsbedrijf Apiiro. Legitieme repository's worden nagemaakt en gevuld met malafide code.

Cybercriminelen klonen bestaande repository's, voegen malware loaders toe en zetten deze op GitHub onder een naam die identiek is aan de legitieme versie. Via een geautomatiseerd proces wordt de repository duizenden keren geforkt, waardoor er talloze forks verschijnen met namen die identiek zijn aan het originele project, ontdekte beveiligingsbedrijf Apiiro. Cybercriminelen hopen dat ontwikkelaars per ongeluk zo'n malafide versie downloaden in plaats van de echte. Via deze repository's wordt malware verspreid die bijvoorbeeld wachtwoorden of cryptocurrency steelt.

Volgens Apiiro speelt de aanval al sinds mei vorig jaar, al is de aanvalstactiek in de tussentijd iets gewijzigd. In mei vorig jaar werden packages naar PyPI geüpload en vanaf daar via calls in forks van populaire GitHub-repository's geplaatst. PyPI verwijderde deze packages, waarop criminelen malafide repository's direct naar GitHub begonnen te uploaden. Sinds november zijn zeker 100.000 repository's nagemaakt, maar mogelijk gaat het zelfs om miljoenen, schatten de onderzoekers.

Een deel van de aangemaakte forks wordt snel weer verwijderd. GitHub herkent namelijk wanneer er geautomatiseerd forks worden aangemaakt, waarna deze offline gehaald worden. Toch worden veel repository's overgeslagen, ziet Apiiro. Bovendien wordt een deel handmatig aangemaakt, waardoor deze niet worden opgemerkt. Door de grote schaal van de aanval en doordat de aanvalsketen geautomatiseerd is, 'komt de 1 procent die de detectie wel overleeft nog steeds neer op duizenden malafide repository's', zeggen de onderzoekers.

GitHub spreekt de inschatting van Apiiro tegenover Ars Technica niet tegen, maar wil geen verdere vragen van het Amerikaanse medium beantwoorden. In een verklaring zegt het platform hard te werken om een veilig platform voor ontwikkelaars te bieden, met speciale teams die content die de voorwaarden schendt detecteren, analyseren en verwijderen. Dat gebeurt zowel met handmatige controles als met machinelearning. "We moedigen leden van de gemeenschap en klanten ook aan om misbruik en spam te rapporteren."

Reacties (87)

[boxlessness]

Ik zie dit nieuwbericht weer als een bevestiging dat we kritischer moeten zijn op wanneer we externe dependencies/packages naar binnen trekken. Ik ben van mening dat we te snel naar een externe dependency/package grijpen, in plaats van zelf even een implementatie in elkaar te draaien... bijvoorbeeld een callback object, of een fancy dropdown, of wat parsing op de backend.
Ja, dat kost wat meer tijd, maar:
1) je leert er veel van omdat je leert van wat er onder de motorkap nodig is om zoiets te maken,
2) je hebt de code onder eigen controle, wat je meer wendbaarheid geeft in het geval van specifieke wensen,
3) de kwaliteit van een dependency hoeft niet on-par te zijn met je verwachtingen en om dat af te dekken moet je sowieso door die code heen
4) een dependency vraagt regulier onderhoud bij versie-updates en vaker actie in het geval van een CVE in een dependency
5) je trekt misschien meer naar binnen met een dependency dat wat je daadwerkelijk nodig hebt of zicht op hebt (e.g. dependency-op-dependency) en vergroot daarmee je load op onderhoud en attack surface voor aanvallen.
6) je creëert mogelijk een (te) tight-coupling met je dependencies en zit met e.g. een licence change met een probleem omdat je het door je hele codebase heen hebt gesprinkled

[YopY]

Ik hoor wat je zegt, maar wil toch een tegengeluid doen.

1) je leert er veel van omdat je leert van wat er onder de motorkap nodig is om zoiets te maken,

Prima, maar is dat waar je voor betaald wordt? Een bestaande dependency opnieuw implementeren "om iets te leren" klinkt als zelf-gratificatie in plaats van een daadwerkelijk probleem oplossen. Daarnaast, als je iets zelf implementeert ben je - en je werkgever, en je collega's - ook verantwoordelijk voor het onderhoud en doorontwikkeling ervan.

4) een dependency vraagt regulier onderhoud bij versie-updates en vaker actie in het geval van een CVE in een dependency

Dat is bij eigen code niet anders; daarnaast, voor dependencies krijg je tenminste een CVE, en met de verschillende security scanner tooling krijg je netjes een waarschuwing als er een probleem in je dependency gevonden is; als je zelf iets gebouwd hebt, heb je dat netwerk-effect niet.

[quote[5) je trekt misschien meer naar binnen met een dependency dat wat je daadwerkelijk nodig hebt of zicht op hebt (e.g. dependency-op-dependency) en vergroot daarmee je load op onderhoud en attack surface voor aanvallen.[/quote]

Dat kan idd een probleem zijn, maar ligt ook aan wat je binnenhaalt en het ecosysteem eromheen; load op onderhoud zal niet anders zijn als je zelf iets bouwt, en het bijwerken van een dependency zou geen grote overhead moeten zijn. Dat zal hem ook aan het ecosysteem en de zelfdiscipline van degenen die de dependency onderhouden liggen, natuurlijk, maar in de praktijk in de afgelopen jaren heb ik nooit problemen gehad met het updaten van dependencies.

6) je creëert mogelijk een (te) tight-coupling met je dependencies en zit met e.g. een licence change met een probleem omdat je het door je hele codebase heen hebt gesprinkled

Ook dit zal er maar net aan liggen wat voor dependency je het over hebt. In de praktijk komt een license change niet zo vaak voor, en zal alle code van voor die change nog onder de oude license vallen; ik kan me maar weinig voorbeelden bedenken van een license change zoals dit.

Lang verhaal kort, ik val vooral over je eerste punt; zelf iets bouwen waar gewoon een goede library voor is, is NIH (Not Invented Here) syndroom. Het is arrogantie om te denken dat je iets beter kunt implementeren dan een library. Soms heb je gelijk, maar vaak niet. En je ziet over het hoofd hoeveel tijd het kost om iets nieuws te bouwen en - belangrijker nog - te onderhouden op de lange termijn.

[boxlessness]

Wat betreft not invented here: helemaal met je eens hoor, maar men trekt voor simpele dingen al packages naar binnen. Een mooi voorbeeld daarvan (en hoe dat ook mis kan gaan) is left-pad, en hoe een enkele change een groot deel van allerlei frontend libs stuk maakte.

Maar de lijn tussen not-invented-here en zelf iets in elkaar draaien is naar mijn mening helemaal niet zo eenduidig. Natuurlijk ga je geen JSON parser zelf bouwen... maar een simpele template parser maken met wat regexes in plaats van een templating engine naar binnen trekken, ja, dat zou ik wel doen (afhankelijk van de complexiteit en requirements).
Ik vind dat je WEL betaald wordt om af en toe een wiel opnieuw uit te vinden. De verwachting is dat je zowel in de breedte (veel libraries kennen, tools gebruiken, dingen snel aan elkaar knopen) als in de diepte (low-level logica kunnen schrijven en lezen) je vak beheerst en daar in groeit.
En dat betekent naar mijn mening dat je meer kan dan alleen maar zo snel mogelijk constant glue-code tussen libraries te zetten, maar dat je ook je skillset van low-level coding blijft gebruiken.
Als er wat mis gaat in de software is de verwachting dat je ook de diepte in kan en snel het probleem kan vinden en oplossen.

Wanneer je je software projecten/teams dusdanig managed dat ze hun skillset in de diepte niet meer gebruiken en daardoor verliezen, dan is dat een bedrijfsrisico, en daarmee ook een probleem dat door management opgelost gaat moeten worden. De verwachting dat een dev in de vrije tijd maar zijn coding skills up-to-date gaat houden is totaal onrealistisch. De metselaar is ook niet in het weekend aan het siermetselen om die skills vers te houden.

[JohnHeroHD]

Ik vraag me af of je dan als bedrijf wel goed bezig bent. Als je applicaties verkoopt / bouwt die je enkel en alleen met libraries in elkaar kunt knutselen.

Zelf vind ik de meerwaarde van developers juist liggen (ik ben er trouwens zelf een - een developer) in de logica die om de packages heen ligt of er gebruik van maakt. Als die ruimte heel klein is, of niet aanwezig, is het bedrijf sowieso niet interessant om werkzaam voor te zijn.

[Reactie gewijzigd door JohnHeroHD op 22 juli 2024 21:25]

[Dennis van der Stelt]

> Maar de lijn tussen not-invented-here en zelf iets in elkaar draaien is naar mijn mening helemaal niet zo eenduidig.

Dat valt reuze mee. Als developer moet je focus leggen op core business van een bedrijf. Een bedrijf als CoolBlue of Bol (om publieke voorbeelden te noemen) bieden bepaalde zaken die heb uniek maken. Als developer bedenk je oplossingen n.a.v. hun business model. Dan ga je niet bezig met een O/RM of JSON parser of DI container of messaging framework of user interface controls. Die bouw je gewoon niet zelf.

Ik ben zelf onderdeel van een club die een product bouwen en kom zo extreem veel bedrijven tegen die met de handen in het haar zitten omdat de developer die iets gebouwd heeft weg is gegaan. En nu hebben ze geen kennis, geen documentatie, geen resources, geen maintenance, etc, etc. om het bij te houden. Toen hun ster developer voorstelde dit te bouwen, leek het een goed idee. Achteraf zijn er maar weinig waarbij het ook echt een goed idee bleek.

Je core business automatiseren is al lastig genoeg voor veel bedrijven. Kijk maar naar de vele sessies op conferenties en cursussen die er bestaan m.b.t. DDD, Microservices, etc, etc. Leg dan niet (ook nog) de focus om allerlei randzaken waar al oplossingen voor bestaan.

[DdeM]

"Prima, maar is dat waar je voor betaald wordt? Een bestaande dependency opnieuw implementeren "om iets te leren" klinkt als zelf-gratificatie in plaats van een daadwerkelijk probleem oplossen. Daarnaast, als je iets zelf implementeert ben je - en je werkgever, en je collega's - ook verantwoordelijk voor het onderhoud en doorontwikkeling ervan."

De enige manier om een probleem op te lossen, is om het probleem goed te begrijpen en de beste manier om dat goed te doorgronden, is te weten wat de juiste oplossing is. Pas als je dat weet kan je bepalen of je beter iets zelf kan maken, of beter een package kan gebruiken. Dus ja, je wordt betaald om problemen op te lossen, maar ook om te leren. Ik zie het zelf al te vaak dat mensen maar gewoon voor alles packages binnenharken, of hele frameworks gaab gebruiken, voor de simpelste dingen, wat jammer genoeg vaak voor precies diezelfde problemen zorgt als die je er mee probeerd op te lossen, alleen maar een grotere load op onderhoud.

[Piemol]

Iets 'nabouwen' wat al bestaat doe ik liever als ik niet alle functionaliteit nodig heb en daarmee allerlei (of gewoon alle) dependencies kan laten vallen. Soms trek je een wir war aan dependencies binnen waar je zelf in de praktijk niks van gebruikt maar ze wel verplicht 'meesleept'. En soms snap je gewoon niet wat een package precies doet terwijl het wel werkt, dat wil ik liever ook niet integreren.

[Snow_King]

Daarom is een BOM (Bill of Materials) voor software ook niet vreemd en best wel wenselijk.

Ik zie dit exten binnentrekken van files van Github heel veel gebeuren in Docker(file).

wget, curl hier en daar, van Github, nog een Shell script van die externe locatie. Allemaal zonder SHA256 checksum controle en soms zelfs nog over http!

Ontwikkelaars vinden het geweldig dat ze zo snel containers kunnen bouwen, maar slaan dit gehele security aspect over en dat is al jaren een grote zorg en ergenis van mij.

DEB en RPM packages lopen vaak achter, maar die gaan wel door een hele lange teststraat heen, dat is heel wat waard.

Ik draai liever de software die uit dergelijke packages komt van de bekende grote repos dan dat er direct code van Github wordt gehaald.

[boxlessness]

De probleem ligt naar mijn mening lang niet altijd bij de ontwikkelaar die "het geweldig" vindt, maar de ontwikkelaar die op de huid gezeten wordt om "snel features te knallen".
Ik zie het bij ons op het werk dat management allerlei deadlines bij elkaar hallucineert, vervolgens die deadlines bij developers over de schutting smijt, en verwacht dat er kwalitatief hoogwaardige systemen uit komen rollen. De enige manier voor een dev om dan nog aan die verwachting te kunnen voldoen is om zwaar te leunen op packages en dependencies die snel aan elkaar geknoopt kunnen worden. Die dev gaat echt geen BOM maken en zorgvuldig door de externe packages heen.

En ja, er zijn ook nog genoeg devs die zonder nadenken vanalles naar binnen trekken, maar een deel van de problemen ligt ook aan de dynamiek tussen development en de rest van de organisatie.

[Grimm]

Klopt. Uiteindelijk is het de verantwoordelijkheid van het management.
Maar persoonlijk zou ik niet voor een bedrijf willen werken die mij harde deadlines oplegt.
Ik zeg altijd, het is af wanneer het af is en dat bepaal ik en niemand anders.
En als het je niet bevalt dan zoek je maar iemand anders.
Uiteraard heeft dat wel tot gevolg dat veel bedrijven/managers mij niet willen hebben en/of
mij minder salaris bieden. Het zij zo. Maar ik voel me beter wanneer ik plezier heb in m'n werk en er ook trots op kan zijn.

[Metian]

Uiteraard is iets af wanneer het af is, alleen deadlines zorgen er voor dat er naartoe gewerkt kan worden dat iets af is. Anders is het te vrijblijvend wanneer iets af zou zijn. Ik ben toch van mening dat deadlines gewoon realistisch moeten zijn en niet te overhaast moeten zijn.

Juist wanneer een deadline realistisch is dan is de noodzaak om "quick wins" te gebruiken ook minder en kan er gewoon tijd gestoken worden in security, optimaliseren etc.

[nandervv]

Nee, het is de verantwoordelijkheid van de ingenieur. Dit geldt met bruggen bouwen en dit geldt met software.

"ja, maar je hebt niet gezegd dat de brug ook over zes maanden nog moet werken" werkt niet voor bruggen, en zou niet moeten werken voor software.

[Reactie gewijzigd door nandervv op 22 juli 2024 21:25]

[DdeM]

Als ik als developer tegen een manager zeg dat iets niet realistisch is, maar hij toch met die onrealistische deadline naar de klant gaat, wiens verantwoorlijkheid is dat dan? Kan je wel zeggen dat het mijn verantwoordelijkheid is, maar die vlieger gaat natuurlijk niet op. Als ik vervolgens gewoon zeg dat ik het dan helemaal niet doe, dan sta ik op straat, dus dat is ook geen optie.

[bzuidgeest]

Tuurlijk moet je trots kunnen zijn op je werk (betaald of niet). Maar een bedrijf heeft afspraken die ze moeten nakomen. Terwijl jij wellicht overbodige tierlantijnen in jou definition of done aan het maken ben hadden ze al kunnen leveren. Een bedrijf dat niet kan leveren kan jou niet betalen, want geen inkomsten. Deadlines zijn er altijd.

Ik doe een hoop maatwerk met vage definities, dan zijn deadlines ook vaag, maar er zijn nog steeds streefdatums en dat is een soort deadline er is ook nog steeds voortgang bewaking en evaluatie wat wel of niet prio heeft of wel of niet gebouwd moet worden.

Er is kwaliteit en er is kwaliteit. Ik kan prima trots zijn op kwalitatief goed werk waar de klant blij mee is, maar waarvan ik weet dat het in mijn mening beter had gekund. Maar de klant zijn mening is dan anders en als ze niet betalen voor dat extra werk dan doe je dat als bedrijf niet.

[Puddi Puddin]

Maar opzich is het toch niet heel raar dat dit pad gekozen word? Een klant wil een beheer schermpje. In dat scherm zit een formulier met een dropdown aan keuze's. Nu zijn er zoveel keuzes bij gekomen dat er eigenlijk een dropdown met zoek functionaliteit moet komen. Dan ga als ontwikkelaar die met 100 euro in het uur weg gezet word hier toch geen 8 uur voor aan het werk als het ook in 45 minuten kan? Don't get me wrong maar elke keer het wiel opnieuw uitvinden gaat ontzettend veel geld kosten in ontwikkel tijd zeker bij kleine team's waar er niet altijd genoeg werk is voor een frontend developer.

[Tubby]

Jeej (Ja en Nee),

De eindverantwoordelijkheid ligt bij Management/het bedrijf, en natuurlijk ligt er altijd druk om features te leveren. Maar uiteindelijk draag jij als ontwikkelaar ook de verantwoordelijkheid om jouw werk veilig af te leveren, als je willens en wetens (al dan niet onder druk van x) software gaat afleveren waarvan jij de veiligheid niet kan garanderen dan hoef ik niet met jou samen te werken.

Feature 0 is altijd security.

Mijn werk (als ontwikkelaar) wordt ook lastiger als ik naast mij een pipo heb werken die overal maar Ja-en-amen op zegt omdat hij de druk niet kan weerstaan en/of de risico's fundamenteel verkeerd inschat. En dat gaat echt iets zijn waarover wij met elkaar een gesprek hebben als jij mijn directe collega bent.

Als de bedrijfscultuur veilige software tegenwerkt lijkt het mij niet zinnig om daar te blijven, genoeg andere plaatsen waar je kan werken waar ze dat wel waarderen.

[divvid]

Ik draai liever de software die uit dergelijke packages komt van de bekende grote repos dan dat er direct code van Github wordt gehaald.

totdat die code niet (snel genoeg) geupdate wordt en jouw andere implementatie afhankelijk is van die ene update of bugfix. Intussen staat een manager, cq klant in je nek te hijgen 'dat het moet werken'

Dan kan je gaan jamaaren, maar aan het eind van de maand moet wel de hypotheek betaald worden.

[Tubby]

Op korte termijn kun je zelf de repo forken; fixen en evt tijdelijk een private package publishen voor eigen gebruik totdat het gefixed is. Extra punten als je voor de fix ook een upstream pull request maakt.

Op lange termijn moet je onderzoeken of dat wat je gedaan hebt wel handig was
- Waarom is dit voor ons een probleem? werken we ver buiten het standaard gebruik van deze package?
- Waarom gebruiken we hiervoor een package?

Alle dependencies moet je uiteindelijk op die manier beoordelen, het blijven make-or-buy keuzes.

en je mag voor jezelf een lijn trekken in wat jij minimale kwaliteit vind wat je in jouw vak wilt leveren.

[Reactie gewijzigd door Tubby op 22 juli 2024 21:25]

[divvid]

Precies onze ‘oplossing’. Alleen ons pull request is nog nooit naar gekeken(repo eigenaar is ws iets anders gaan doen). Inmiddels gebruiken anderen onze fork.
Zo ontstaan dus de problemen uit dit artikel.

Maar geef toe, ff de dependencies van een vue of react framework of een willekeurig python package doornemen is voor een klein team niet te doen, geen budget voor en ook geen wens van de klant

Voor een veelgebruikt framework zal je nog wel wat aan de community hebben maar zodra het exotischer wordt kan je het vergeten

[Reactie gewijzigd door divvid op 22 juli 2024 21:25]

[Tubby]

Klopt, de oplossing is bij lange na ook geen zwart-wit en moet per scenario bekeken worden.

Aan de ene kant van het spectrum heb je een library voor leftpad en aan de andere kant het react framework.

In de java wereld heb je het Spring framework wat behoorlijk volwassen is, maar daar dien je ook wel mee te gaan in de update's.

Binnen het Spring eco systeem zit bijvoorbeeld ook Spring-Boot waarin ze o.a. ook versies van dependencies managen zodat een groot deel van jouw dependencies ook weer worden bijgewerkt bij het bijwerken van je Spring-Boot versie.

[Admiral Freebee]

Dat is een vraag die ik me soms ook stel bij handige docker-compose scriptjes die je overal kan vinden om iets te installeren. Die halen vanalles binnen van een repository en het is niet altijd direct duidelijk wat en waar en of het allemaal up to date is.

[LOTG]

Het hangt er natuurlijk maar vanaf over wat voor dependency je het hebt.
Je kunt natuurlijk altijd het wiel opnieuw uitvinden, en voor kleine zaken is dat best te doen, maar in sommige gevallen is het de vraag of je maanden wil steken in iets wat een package waar jaren development in zit en wat breed gebruikt word uiteindelijk beter doet.

Als je het zelf maakt betekend dat ook dat je het zelf moet onderhouden en testen.
Het updaten van een dependecy vanwege een CVE kan vervelden zijn, maar wie controleert jou code of je niet zelf een vergelijkbare CVE hebt geïntroduceerd? Dan update ik liever een dependecy.

Bij een grote applicatie telt dat uiteindelijk wel op.

Uiteraard moet je wel altijd kritisch zijn over wat je als dependency binnen trekt. en of het nodig is maar het is zeker niet altijd beter om het maar zelf te maken.

Uiteindelijk komt het aan op keuzes en dan is het soms realistisch zijn en accepteren dat je niet in een paar weken een open source project waar jaren werk in zit gaat bouwen. Maar dan praten we ook niet over een library die een simpel dingetje doet.

Ik heb het idee dat er veel meer packages gebruikt worden bij frontend projecten. In ons backend systeem gebruiken we een paar grote maar niet echt iets dat triviale functionaliteit is, dat is vaak gewoon standaard functionaliteit wat bij frontend code vaak in een extern package zit als je het ook wil gebruiken.

[RetepV]

Ik ben van mening dat we te snel naar een externe dependency/package grijpen, in plaats van zelf even een implementatie in elkaar te draaien...

Ik ben niet van die mening gedaan. Veel van die externe dependencies en packages zijn echt groot en ze zelf ontwikkelen kan vele honderdduizenden euro's kosten. Ga dat maar eens uitleggen aan degenen die het software ontwikkel budget moeten gaan verdedigen voor sales en marketing.

Wat er wel moet gebeuren is het volgende:

* Een veel strenger beleid met betrekking tot het naar binnen halen van zulke externe dependencies. Analyse van wat het allemaal doet, een risicoafweging maken en een rapport opstellen.
* Wanneer besloten wordt zulke dependencies te maken, de versie die geanalyseerd is downloaden, lokaal opslaan (in je eigen beschermde git repository) en vervolgens tot in lengte van dagen alleen die versie te gebruiken.
* Als er bugs of nieuwe features zijn in de package, moet er een afweging gemaakt worden of die bugs of features het waard zijn om de lokale repository voor te updaten. En dan moet de nieuwe versie geanalyseerd worden en start alles weer van voren af aan.

Het heeft een aantal voordelen:

1. De kosten die de analyse met zich meebrengt zijn meteen te bepalen, beslissingen kunnen dus snel genomen worden.
2. Door de periodieke rapportage is het snel te bepalen welke zaken er bij zijn komen kijken sinds de laatste versie.
3. De software is stabiel. Bugs kunnen ook in de lokale repository opgelost worden, waardoor de fix meteen ter beschikking is. De fixes kunnen vervolgens ook makkelijk terug naar de originele repository.

Het nadeel is dat je niet meer even snel een package bij je software naar binnen kunt trekken wanneer je denkt dat het nodig is.

Maar dat nadeel is juist datgene dat het probleem van het ongewis malicious code naar binnen halen oplost.

Eigen controle is het enige dat jezelf kan beschermen.

Je kan nooit volledig op de open source ontwikkelaars vertrouwen. Ze zullen echt wel te goeder trouw zijn, maar ze hebben geen trouw aan jouw bedrijf en als het fout gaat hebben ze geen verantwoording aan jou, alleen een verantwoording aan hun eigen goede naam.

En zo zal Github ook echt wel te goeder trouw zijn. Maar ook Github kan nooit van zijn leven alles onder controle houden. En ook Github is alleen verantwoordelijk voor zijn eigen goede naam en niet voor jouw mogelijke schade.

Één en ander werkt natuurlijk ook vertragend op de ontwikkeling van open source software. Maar dat is de prijs die je voor open source moet betalen.

Als je dependencies en packages in je software binnen haalt, dan ontslaat je dat nog niet van de verantwoordelijkheid om die code te kennen en wat het allemaal in je software doet. En dan bedoel ik met 'verantwoordelijkheid' de verantwoordelijkheid aan je bedrijf en de gebruikers van je software.

[Reactie gewijzigd door RetepV op 22 juli 2024 21:25]

[WaarAnders]

Het leer aspect komt bij AI zoals ChatGPT ook vaak naar voren, maar is lang niet altijd van toepassing. Als je niet van plan bent de opgedane kennis later nogmaals te gebruiken, dan is de investering het mogelijk niet waard.

Ik heb zelf voldoende use cases waarin ik gewoon iets aanneem ipv me erin te verdiepen. Naïef? Waarschijnlijk wel. Ik moet waarschijnlijk beter opletten met dit soort criminaliteit. Met behulp van tijdelijke containers probeer ik het risico te verminderen.

[rboerdijk]

Je geeft nu hele simpele voorbeelden, knutsel je zelf ook even een Physics SDK in elkaar, of een character animation system met IK support?
In dat geval, wordt de planning daar dan ook op aangepast (een paar jaar extra)?

[beerse]

Zo heel zwart-wit zou ik het niet stellen. Wel laat het mooi zien dat je niet zomaar van alles kan en mag binnen halen. Of je het nu 1 keer binnen haalt of de repository koppelt. Je moet goed nazien en bijhouden of het allemaal blijft werken. Dat is zo ongeveer net zo belangrijk als het zelf schrijven van software.

Het voornaamste verschil tussen zelf schrijven of 'uit een repository trekken' is de expertiese van de specialist die het doet. Het is beide even belangrijk en even gevoellig voor van alles en nog wat.

Het van internet plukken, van een repository trekken of extern inkopen van dergelijke zaken vereist allemaal serieze kennis van zaken.

[kftnl]

De meeste organisaties hebben totaal geen idee wat voor dependencies ze allemaal meenemen. Ik vind het maar een enge gedachte dat je met een 'npm install' zomaar uit honderden pakketten code draait op je computer waarvan je eigenlijk geen manier hebt om het te auditen.

Ik heb het idee dat dat bewustzijn over hoe kwetsbaar je bent voor dergelijke aanvallen er bij veel devs wel is, maar bij veel devs ook totaal niet.

Veel organisaties hebben wel een soort eigen 'artifact store' zoals Sonatype Nexus of Artifactory, wat wel meer zicht op de organisatie van dependencies geeft, maar tenzij dat goed wordt gemanaged - wat voor bedrijven niet altijd haalbaar is - ben je er dan nog niet.

[Reactie gewijzigd door kftnl op 22 juli 2024 21:25]

[RobertMe]

npm is hier ook meteen het beste voorbeeld in. Zeker in het begin werden er allemaal packages gemaakt die maar 1 functie bevatte. Vervolgens werd dat package gebruikt door honderden andere packages die weer maar 1 of enkele functies bevatte, dat weer gebruikt door een ander package, etc etc. En uiteindelijk zijn ineens ook de packages van "grote namen" (bv Angular / React / Vue) gebruikers van zo'n vage packages die 10 jaar geleden gemaakt zijn en maar een of enkele regels code beslaan.

Als zo'n package compromised is (of zoals ook al gebeurt is, de ontwikkelaar het package verwijderd) valt het hele ecosysteem in elkaar doordat bij wijze van 90% van alle packages indirect hier gebruik van maakt.

Bij "alternatieven" in andere talen (composer / packagist bij PHP, NuGet bij .NET, Maven bij Java) speelt dat AFAIK vele malen minder. O.a. dus ook doordat packages daarbij groter zijn en niet maar 1 functie bevatten. Waardoor er ook niet zo'n packages bestaan die door 90% van de rest van de packages gebruikt wordt. En daardoor ook de situatie ontstaat dat library / franework developers meer eigen code hebben en minder gebruik maken van dependency op dependency op dependency op.... En dus ook niet een package dat een of andere "noob" vol fouten 10 jaar geleden gemaakt heeft ineens wordt binnen gehaald.

[zenlord]

Bij "alternatieven" in andere talen (composer / packagist bij PHP, NuGet bij .NET, Maven bij Java) speelt dat AFAIK vele malen minder.

Dat durf ik betwisten - het is niet de omvang van de packages dat doorslaggevend is, maar de nuttige functionaliteit ervan.

ImageMagick is een goed voorbeeld - https://xkcd.com/2347/

[RobertMe]

Ik zeg dan ook niet dat het bij die alternatieven niet speelt. Alleen dat het naar mijn idee daar minder speelt. Omdat bij npm in ieder geval initieel alles maar een eigen package was waardoor, in het geval van die XKCD, de hele onderkant in de categorie valt "door 1 man onderhouden sinds 2003". Waardoor veel grote JS / npm projecten een fundament hebben dat alleen maar bestaat uit dit soort projecten. Terwijl bij andere talen de grote projecten bij wijze van maar 1/10e van het aantal dependencies heeft en misschien een of twee daarvan een "iffy" herkomst hebben.

Kijk ik bv naar Symfony: https://packagist.org/packages/symfony/symfony dan zijn de requires naar Doctrine (andere "giant"), PSR standaarden (dus bevat in principe alleen interfaces, en daarnaast ontwikkeld / opgesteld door de nog grotere PHP community), hun eigen gemaakte polyfills, en Twig dat van dezelfde developer(s) is (en als ik het goed begrepen heb i.p.v. Twig 4.0 in de toekomst geïntegreerd wordt in het Symfony project). En als ik deze dependencies even allemaal aanklik komt er ook niks nieuws bij aan dependencies.
Dat zit naar mijn idee dus heel anders in elkaar dan een npm ecosysteem waarbij er alleen al het heel bekende voorbeeld is van het left pad package: https://www.theregister.com/2016/03/23/npm_left_pad_chaos/ . En dan doel ik niet op het pullen van het package, maar zo'n simpele functie die in een zelfstandig package wordt gestopt dat door honderden als niet duizenden packages direct of indirect ala dependency wordt gebruikt. En zo zijn er vele packages (geweest?). Waar dus ook de grote/bekende frameworks van "nu" bouwen op deze semi shady packages.

[Dorank]

Doe 1 ding en doe het goed. Dat is een geweldige programmeer mentaliteit.

Het voordeel van zo'n kleine module is dat het dus modulair is, fouten in de module zijn simpel op te sporen en te fixen (in theorie). Mocht deze module compromised worden is het ook meteen zichtbaar aangezien er opeens een heel groot gedeelte van de code wordt aangepast.

Jou voorbeeld dat de grotere packages juist leiden tot meer eigen implementaties met de kans op meer eigen fouten. Die moeilijker te onderhouden zijn aangezien er wellicht allerlei bijeffecten zijn.

[_Thanatos_]

Het gaat in dit verhaal niet om repo's die compromised zijn, hoewel dat zeker een valide zorg is om te hebben. Het gaat om het aanmaken van nieuwe repo's met een gelijke naam als een bestaande package. Maar npm "weet" waar een package vandaan moet komen, omdat de maintainer van zo'n package verantwoordelijk is voor iedere publish naar npm.

Dus npm kan alleen vergiftigd raken, vanuit github gezien dan, als de *oorspronkelijke* repo/account van een betreffende package compromised is. Niet door 298231978 packages met dezelfde naam op github te dumpen.

[TD-er]

Het gaat in dit verhaal niet om repo's die compromised zijn, hoewel dat zeker een valide zorg is om te hebben. Het gaat om het aanmaken van nieuwe repo's met een gelijke naam als een bestaande package. [...]

Tot een uur geleden was ik het met je eens dat het waarschijnlijk alleen zou gaan om nieuwe repo's met een gelijkende naam.
Maar nu heb ik zojuist meerdere mails in mijn spambox gevonden waarin men mij vrij specifiek vraagt (en ook "generieke" mails zonder referentie naar mijn repos) om tegen betaling even mijn GitHub account te kunnen lenen.

Nu zullen er vast ook wel mensen zo dom zijn om hier op in te gaan. (en dan waarschijnlijk ook niet eens betaald worden)
Dit is de "anonieme" variant (de andere mails had ik al weggegooid)

Subject: Borrow a Github account and get 1,200 yuan in cash for 10 minutes/Github 账户借用10分钟得1200元现金

Dear friend，

I am a Chinese developer live in Chengdu, your github account has received the Starknet airdrop. If you are familiar with the operation, you can collect it yourself and exchange it for cash. If you are not familiar with the relevant operation, I can directly give you 1,200 yuan in cash or 180 US dollars via paypal/alipay and use your account for 10 minutes.
I run a mining pool and am familiar with the gameplay of the crypto circle. Welcome to contact [...]

[vgroenewold]

Ja inderdaad, na jaren talen als C++, Java e.d. te hebben gebruikt dacht ik eens... laat ik toch eens wat web development proberen. Ik schrok me wezenloos! Ik begreep toen pas waar alle issues steeds vandaan kwamen, nu maar bezig met Rust en ik blijf lekker ver van standaard web development.

[armageddon_2k1]

Log4j anyone

[Cilph]

Log4j is geen dependency confusion verhaal in een zee van kleine unmaintained dependencies. Log4j is een robuuste logging library die bijna overal gebruikt werd. Echter werd een stuk legacy functionaliteit grandioos misbruikt en dan heb je idd Log4Shell. Dat zulke dependencies af en toe een exploit hebben neemt niet weg dat de verhoudingen compleet scheef zijn.

[Reactie gewijzigd door Cilph op 22 juli 2024 21:25]

[ronaldmathies]

Het Log4Shell debacle kan je op twee manieren opvatten:

1) Er is een CVE, iedereen heeft er last van het wordt door het vele gebruik snel gefixed in de library, het nieuws verspreid snel ontwikkel teams pakken het op en het is klaar.

2) Iedereen heeft een andere logging library in gebruik, elke logging library heeft weer zijn eigen CVE's, vaak worden libraries niet ge-upgrade, zeker niet bij software wat weinig ontwikkeld wordt. Issues blijven hierdoor onder de radar, nieuws verspreid niet snel want het is niet allemaal veel in gebruik. Of de libraries zijn dusdanig klein dat de CVE mogelijk niet ontdekt / gepubliceerd wordt (maar het issue er mogelijk wel is, maar iemand moet het eerst wel ontdekken en publiseren).

Scenario 1 kan je heel goed vergelijken met een CVE in Windows, Linux Kernel of OSX, wordt opgepakt, veel nieuws, issue is opgelost. In scenario 2 blijven CVE's vaak onder de radar en niet opgemerkt. Ik heb veel liever scenario 1.

Hoe kleiner een library hoe groter de kans is dat er issues mee zijn of gaan zijn omdat ze niet goed onderhouden worden.

[thePiett]

Ahja, want alle Rust crates zijn helemaal veilig. Rust is veilig. Niks om je druk over te maken!

[kftnl]

Het gaat denk ik niet om of node of rust veilig is, maar om een bepaalde cultuur die bij sommige talen en frameworks ontstaan is om relatief veel externe dependencies mee te trekken. Node is daar een voorbeeld van, maar er zijn er wel meer.

[vgroenewold]

Precies dat ja, ik heb het niet over het veilig zijn ergens van per-se, dat hangt altijd af van whatever code er geproduceert wordt, maar als ik zie dat ik, bij wijze van spreken, een hello-world web app maak waar dan eerst (again bij wijze van spreken) 300 packages gedownload worden...

[aikebah]

300... dan ben je zuinig geweest. Web projects zie ik vaak al snel op minstens het dubbele komen als ze al niet over de 1000 heen gaan (inclusief all dev dependencies). Effect van al die micro-packages idd. Ik blijf er dus ook graag uit weg.

[Waswat]

Wat is dit voor onzin? Dit is toch niet alleen een web dev issue? Het kan gebeuren met elke externe package, dependency of framework dat je gebruikt.

Als ik een c# console applicatie maak en ik verwar een legit nuget package met eentje die een vergelijkbare naam heeft maar kwaadwillend is (en nog niet verwijderd) dan is het ook zo voorbij.

[Reactie gewijzigd door Waswat op 22 juli 2024 21:25]

[vgroenewold]

Ik heb het niet over de veiligheid, maar over de hoeveelheid aan dependencies. Dat maakt dat zoeken naar bugs lekken, sowieso veel te veel tijd gaat kosten en men het dus maar gewoon voor lief neemt.

[Waswat]

Ah, ok, mijn excuses, dan heb ik je verkeerd begrepen. Dan ben ik het er gedeeltelijk wel mee eens, maar niet alle webtalen zijn zoals javascript/typescript...
Met C# .NET development bijvoorbeeld vind ik het qua dependencies echt wel reuze meevallen.
Maar als men dan weer een keuze maakt om in de frontend angular of react te gebruiken tsjah...

(Ik heb overigens een vergelijkbare mening als jij maar dan over python met z'n doolhof aan dependencies, hoewel ik het gevoel krijg dat dit meer komt van mijn gebrek aan ervaring met python)

[vgroenewold]

Datzelfde zal ik ook vast hebben met web development, het blijft deels een gevoel op basis van weinig ervaring ermee. Maar in het algemeen heb ik altijd geleerd niet teveel afhankelijk te willen zijn van andermans code, dat is erg ouderwets overigens, want om mee te kunnen komen kan je bijna niet anders, dat snap ik zeker ook. Dank voor je antwoord btw.

[OMX2000]

Dat kan ik niet ontkennen. Maar met closed source software is dat even erg, misschien wel erger. Kwaadwillenden kunnen ook infiltreren in bedrijven die closed source software bouwen, dan heb je als bedrijf helemaal geen enkele manier om erachter te komen dat er iets mis is. Althans, meestal is dat te laat. Bij open source software in publieke software, gebeurd het "in the open". Ik zeg niet dat dat helemaal veilig is, want het is gebleken dat dat niet zo is, maar publieke repositories worden ook actief gescand.

Enige wat veiliger zou kunnen zijn, is als je ALLES in je software stack zelf bouwt. En ik denk dat dat tegenwoordig niet realistisch is.

[watercoolertje]

Enige wat veiliger zou kunnen zijn, is als je ALLES in je software stack zelf bouwt. En ik denk dat dat tegenwoordig niet realistisch is.

Ik denk juist onveiliger, in mijn geval zou ik misschien wel 1000x meer code moeten schrijven, en dus ook 1000x meer fouten in mijn project. Terwijl veel (al vrijwel uitontwikkelde) packages juist relatief weinig fouten bevatten.

Maarja ik gebruik wel vrijwel uitsluitend bekende packages en geen git-repo's met weinig sterren of hele nieuwe (tenzij snippets waar je zelf prima handmatige controle op kan uitvoeren).

Ik snap het probleem uit het artikel wel maar zolang je die forks (en clones, dank je @Triblade_8472) niet (indirect) gebruikt loop je ook helemaal vrijwel geen gevaar. In ontwikkelaars als Spatie/BarryvdH heb ik meer vertrouwen dan in mijzelf

[Reactie gewijzigd door watercoolertje op 22 juli 2024 21:25]

[OMX2000]

Ik zeg ook, "veiliger zou kunnen zijn". Omdat je dan totale controle hebt. Maar of je als 1 pitter veiligere code gaat schrijven, betwijfel ik zeker.

Dus ja het is wat gecompliceerder. Maar wat wel positief is is de bewustwording, en de meer actieve houding van bedrijven mbt tot security.

Ander voorbeeld is dat het Witte Huis aanstuurt op het dumpen van C en C++ vanwege het grotere gevaar op "memory leaks" (o.a. buffer overflows) : https://www.infoworld.com...pers-to-dump-c-and-c.html

[gday]

Volgens mij is het probleem niet dat devs malafide forks zouden gebruiken, maar dat er repo's worden gekloond (no pun intended) en dus niet geforkt waarna van die malafide repo dan juist heel veel forks worden gedaan om te veinzen dat de upstream repo legitiem is en dus degene is die je nodig hebt.

[Reactie gewijzigd door gday op 22 juli 2024 21:25]

[Triblade_8472]

Nee, jij moet niet 1000x meer code schrijven, het bedrijf moet meer mensen aannemen om te coderen.

Nu plukt het bedrijf de vruchten van gratis werk van andere overnemen. En als daarin een fout zit wijzen ze lekker makkelijk naar Github. Afschuifmentaliteit.

Een andere optie is om meer mensen aan te nemen die wél de code schrijven en de verantwoordelijkheid ervoor kunnen nemen. Dat houd dus ook bug fixes in ipv verborgen problemen die nooit iemand meer controleert. Ja, het product wordt duurder. Maar daar staat kennis en kunde tegenover.

De vraag is, willen we meerdere competente mensen en deugelijke software die duurder is, of bij elkaar geharkte gratis software en de bijkomende problemen?

[Heloise]

Precies dit.

Bovendien moeten we af van de constante druk om nieuwe “features” of enkel UI wijzigingen toe te voegen die niet of nauwelijks iets toevoegen aan de basis functionaliteit.

[divvid]

het bedrijf moet meer mensen aannemen om te coderen.

wie dan? Er is al een schreeuwend tekort aan dev personeel, laat staan deskundig dev personeel.

[Triblade_8472]

Het probleem van derde partij packages is al jaren en jaren een probleem dus ga niet nu opeens komen met personeelstekorten.

Daarnaast is het hoog tijd dat er een berg bedrijven samengaan (of omvallen zodat er personeel vrij komt voor andere bedrijven). Dit geld overigens wat mij betreft voor alle bedrijven. Met samenwerking krijg je sneller klussen voor elkaar ipv ieder voor zich het wiel opnieuw uitvinden of (ondoordacht en/of onveilige) gratis onderdeeltjes bij elkaar sprokkelen.

We proberen met allemaal eenpitters of hele kleine bedrijfjes een berg klussen op te lossen en maken veel fouten, of zoals in optopic gebruiken een hoop gratis onderdelen van derden zonder het na te kijken, ipv met enkele grotere bedrijven zaken professioneel op te pakken. Er wordt nu ook zoveel energie verspild. Denk alleen al aan administratie die ieder voor zich moet uitzoeken ipv een professionele financiële afdeling.

[divvid]

Ik zou graag meer mensen will aannemen, third package gebruik of niet, maar ze zijn simpelweg niet te vinden, al jaren niet

[Triblade_8472]

Github bestaat al 17 jaar en daarvoor bestonden al gratis packages en software stukjes.

Als je al die tijd niemand hebt kunnen vinden moet je gaan nadenken over hoe je zoekt. Of een partnership aangaan. Of elder in dienst gaan.

Hoe dan ook, een groot deel van de bedrijven moet gewoon kappen en samengaan met een ander. Of twee hebben het slecht, of een goed.

[divvid]

Als non profit kunnen we niet de hemel betalen, dat weten we, maar wat er binnen komt op een vacature is echt bedroevend. Jammer, want we hebben een prima HR en kantine)

[J_van_Ekris]

De meeste organisaties hebben totaal geen idee wat voor dependencies ze allemaal meenemen. Ik vind het maar een enge gedachte dat je met een 'npm install' zomaar uit honderden pakketten code draait op je computer waarvan je eigenlijk geen manier hebt om het te auditen.

alhoewel ik jouw praktische gevoel van een lawine van onbekende packages onderschrijf, kun je als gebruiker wel degelijk auditten wat er meekomt.

Als je kijkt naar de package-lock.json (zie hier voor een voorbeeld van een project waar ik zelf aan werk) dan zie je precies wat er geinstalleerd wordt/is. Je kunt met tools dit ook controleren op vulnerabilities, en in GitHub kun je voor jouw fork ook gewoon dit aanvinken waardoor dit automatisch gecontroleerd wordt (zie hier een voorbeeld van de output). Dus als je een package hebt, kun je het redelijk eenvoudig auditten. Zoals ook uit mijn eigen voorbeeld blijkt, als ontwikkelar ga je kapot aan de dingen die ik niet gebruik (we hebben blijkbaar dependencies op tar en vm2, beide die ergens door een package om een of andere reden geinclude worden....)

Dat gezegd hebbende, een vulnerability ontdekken en hem oplossen zijn echt twee totaal verschillende dingen. Als Package Maintainer spendeer ik regelmatig een dag om de dependency hell van al die packages te ontwarren, packages op de aanbevolen wijze te upgraden en te kijken of onze applicatie de upgrade van die packages overleeft.

Ik heb het idee dat dat bewustzijn over hoe kwetsbaar je bent voor dergelijke aanvallen er bij veel devs wel is, maar bij veel devs ook totaal niet.

Dat beeld deel ik volledig met je. Als voorbeeldje: mijn voorganger bij het open source project was erg snel enthousiast over een package en include dat probleemloos. En hij was niet bepaald kritisch wat hij uitkoos, als het maar werkte. Of er een actieve community omheen was en of er geen betere packages waren lijken echt niet op het prio-lijstje te hebben gestaan. Hij heeft het project intussen al een twee jaar niet meer aangeraakt en ik snap waarom: al die geinclude meuk is intussen en paar major versions verder of totaal obselete, en dat upgraden of refactoren is geen leuk ontwikkelwerk.

Maar het is wel essentieel. Ontwikkelaars moeten veel bewuster kiezen wat ze wel en niet als dependency willen. Op lange termijn ook voor hun eigen sanity wel een ding overigens....

[YopY]

waarvan je eigenlijk geen manier hebt om het te auditen.

Hier komt het vooral op vertrouwen aan; nagenoeg alle NPM dependencies zijn (by design) open source en veelal op github, en er zijn individuen en bedrijven bezig om die allemaal na te kijken en te scannen. Als er eens eentje een CVE heeft, krijg je daar met `npm audit` een waarschuwing over.

Maar dat gezegd hebbende, het Node dependency ecosysteem is belachelijk. Ik vind die van Go gezonder; de standard library is veel uitgebreider, het toevoegen van frameworks en libraries wordt vaak ontmoedigd, en de frameworks/libraries zelf hebben vaak zelf niet al te veel dependencies. Ook zijn nagenoeg alle dependencies per definitie open source, as in, je download de code ervan ipv iets dat al gecompiled of obfuscated is.

Ik wil ook iets over bijv. Rust zeggen maar daar heb ik verder geen kaas van gegeten.

[_Thanatos_]

npm staat in principe los van shit die op github gebeurt. Het is nml aan de package maintainer om iedere nieuwe versie te publishen naar npm. Dus als jij `npm install axios` ofzo doet, dan weet je 100% zeker (uitgaande van betrouwbaarheid van npm) dat de echte axios wordt binnengehengeld. Het maakt niet uit hoeveel repo's er op github bestaat die ook zo heten - daar wordt jouw package toch niet vandaan gehaald.

[Elminster]

Stel u voor dat ChatGTPWhatever dan getrained wordt op malafide code.

[Wraldpyk]

ChatGPT en alle andere LLM AI's worden getraind op alle code die ze vinden. Van de meest grote troep van mensen die niet kunnen programmeren tot de beste repositories met 100k stars of meer.

Als je een AI gebruikt voor het genereren van code moet je gewoon zelf scannen of het de code is die je wil. Gelukkig komen ze nooit met hele packages in een keer en is alles behapbaar om in je op te nemen.

[CodeCaster]

Van de meest grote troep van mensen die niet kunnen programmeren tot de beste repositories met 100k stars of meer.

Die twee zaken sluiten elkaar helaas niet uit.

[Stoney3K]

De source code van Windows 95 staat nog niet op Github.

[YopY]

Die van DOS wel, misschien dat Windows later volgt: https://github.com/Microsoft/MS-DOS

[_Thanatos_]

Fair is fair, ik denk dat er best ingenieuze stukken in de win9x sourcecode zullen zitten. De interop met native 16-bits DOS is vgs mij best briljant in een omgeving waar (voor die tijd) zoveel mogelijk was.

Dat het een belabberd OS was, staat los van hoe mooi de sourcecode is, wil ik er maar mee zeggen.

[Rouwette]

Dat moet toch wel te scannen zijn.

[Kriekel]

Als ze het kunnen detecteren kunnen ze het ook van GitHub verwijderen.

[ToolBee]

Als het handmatig gedaan is niet, staat in de tekst.

Er worden tussen de "confusion" van alle geautomatiseerde uploads handmatig andere spiked clones neergezet. Die zijn interessanter om te tracken door de securitymensen....

[Alfa1970]

Dat is twijfelachtig.

Het is al erg moeilijk om malafide programma's te detecteren, laat staan broncode in de vorm van platte tekst.

Je moet al een grote set aan interpreters gaan bouwen voor elke denkbare programmeer taal die gebruikt wordt op GitHub.
Heb je dat dan moet je gaan bedenken of er dingen in die code gebeuren die malafide zouden kunnen zijn voor een onnoemelijk grote set aan mogelijke aanvalsdoelen.

Je moet je indenken dat malafide code, en malafide programma's voor de computer en het os gewoon programma's zijn, alleen een mens kan het feitelijke onderscheid maken of iets gewenst is of niet.

En dan moet je je indenken dat alles "nieuw malafide" wat op GitHub verschijnt, waarschijnlijk "zero day" achtig is.
Er moet iemand tegenaan lopen die de pisang is, en waarschijnlijk zullen dat vele "iemanden" zijn,
voordat "men" op het idee komt dat het misschien gaat om malafide source code afkomstig van GitHub is.

En dan is dat nog alleen als het gaat voor criminele toepassingen, maar hoe maak je nu het onderscheid tussen dat en een proof-of-concept voor onderzoek doeleinden? De payload?

[DeTeraarist]

Als de code verder goed in elkaar zit is daar niks mis mee toch.

[OMX2000]

Ik vraag me af hoe ze dit gaan tegenhouden. Ja je kunt de malafide code en binaries scannen, en dan zal het voorkomen dat er false posities zijn. En daar moet je weer een handmatig proces achter hangen om die na input van de gebruiker de blokkade terug te draaien. Maar dat scannen gaat niet waterdicht zijn. En je kun het systeem ook overbelasten, waar de kwaadwillenden momenteel al mee bezig zijn.

[biteMark]

Iets dergelijks gebeurde ooit ook op Planet Source Code. Visual Basic 5 of 6 had de onhebbelijke eigenschap dat timers in User Controls (als ik me die conditie goed herinner) al af konden gaan in de IDE en code konden uitvoeren, nog voordat het project gerund werd. Op die manier zijn eens alle bestanden in mijn persoonlijke mappen (Mijn Documenten etc.) gewisd terwijl ik dacht dat ik een project met goede reputatie had gedownload

[bzzzt]

Zodra je een 'build' recept opstart geef je feitelijk al controle weg over je account. Moderne IDE's zoals bijvoorbeeld die van Jetbrains geven dat ook duidelijk weer als je een nieuw project importeert, maar ik ben bang dat de meeste programmeurs zich daar niet door laten tegenhouden.

[jos707]

Zou het niet al een goed begin zijn als GitHub de forks duidelijker zou onderscheiden van de originele repositories? Nu is de naam hetzelfde en aan de lay-out zie je niet direct of je het origineel of een fork aan het binnenhalen bent.

[J_van_Ekris]

Probleem is dat regelmatig de originele repro al jaren abandoned is (originele dev heeft soms andere prioriteiten), er een stel PR's uitstaat van jaren oud en dat iemand dan het onderhoud maar naar zich toe trekt in een geforkte repro. De wereld is niet zo clean dat de originele repro de beste of meest actuele is. Maar aangeven of er nog actief op ontwikkeld wordt zou al helpen.

[Reactie gewijzigd door J_van_Ekris op 22 juli 2024 21:25]

[bzuidgeest]

Ik word er moe van als ik dit soort dingen weer lees. Blijkbaar is er een groep mensen die voor gewin alles van hardwerkende mensen moet verzieken.
Al die mensen die hun gemaakte werk aanbieden worden zo beschadigd in reputatie alsmede de reputatie van open-source in het algemeen.

Als ze figuren pakken die dit doen, dan mogen die wat mij betreft de rest van hun leven maatschappelijke diensten leveren zoals toiletten schrobben en vuil rapen.

[moonlander]

Ben dan ook wel benieuwd naar een voorbeeld.

[controvi]

Hoe reageert een AI als copilot hier eigenlijk op?
Want als een copilot zou leren dat die malafide code correct zou zijn zou een ai bij het opzetten van een project of voorbeeld code ook zomaar die foute packages mee kunnen geven.

Of zie ik dat verkeert ?

[Triblade_8472]

Dat zie jij goed. Daarom zegt iedereen ook dat je nooit blindelings code moet accepteren, maar altijd zelf de kennis en kunde moet hebben om het te lezen, controleren en accepteren.

AI moeten mensen leren zien als een hulpmiddel, niet vervanging. Iig de komende tig jaar.

[controvi]

Hoewel ik het met je eens ben denk ik wel dat het vooral met die packages lastig kan zijn.
Voor bijvoorbeeld NPM gaan mijn nekharen steeds meer overeind staan.
Iemand kan een package maken voor een malifide repo en deze verbergen onder een laag andere packages waardoor je niet eens echt meer kunt zien wat er allemaal gebeurd.

Als co-pilot dan zegt dat een package nodig is voor functionaliteit X dan kan ik als dev daar best snel intrappen. Helemaal gezien sommige package names niet bepaald altijd direct zeggen wat ze doen maar wel legitiem zijn en veel gebruikt.

Nou snap ik dat het wellicht wat ver doordenk maar als je echt slechte intensies hebt kun je natuurlijk zelf zoveel en zover gaan als je wilt.

Maar kwa losse code is het zeker noodzaak om precies te weten wat je code doet. In ieder geval in basis. Copy past werk gaat je nu helpen maar later naait het je hard als je geen idee hebt wat je gebouwd hebt

[bzuidgeest]

En daarom blijven ontwikkelaars die weten wat ze doen voorlopig een baan houden.

[DdeM]

Tijd om mijn "Not invented here" syndroom maar af te stoffen en weer te omarmen