Techbedrijven willen meer samenwerken om opensourcesoftware te beveiligen

Verschillende grote techbedrijven, waaronder Google en IBM, roepen de techindustrie op om opensourcesoftwareprojecten beter te beveiligen. Dat doen ze na een ontmoeting met de Amerikaanse regering rondom de perikelen met log4j.

Google pleit onder andere voor een openbare lijst waarop opensourceprojecten worden opgenomen die als 'kritiek' worden beschouwd, schrijft het bedrijf in een blogpost. Hoe belangrijk die projecten zijn, moet worden gebaseerd op hun 'invloed en belang voor een project'. Ook stelt Google voor dat er nieuwe manieren moeten komen om software te ontdekken die een 'systematisch risico vormen' voor grote projecten.

Het bedrijf pleit daarnaast voor nieuwe standaarden voor opensourceprojecten rondom beveiliging, onderhoud en testen. Die zouden door stichtingen zoals de OpenSSF moeten worden behandeld en ook door andere bedrijven moeten worden ondersteund. Ook wil Google dat er een onafhankelijke organisatie komt die 'als een marktplaats voor opensourceondersteuning moet dienen'. Die organisatie kan dan vrijwillige ontwikkelaars aan projecten koppelen die mogelijk hulp nodig hebben bij de ontwikkeling.

Andere techbedrijven hebben soortgelijke initiatieven voorgesteld, al zijn die niet altijd even concreet. De Apache Foundation zegt bijvoorbeeld dat samenwerking tussen bedrijven die opensourcesoftware gebruiken, altijd nodig zal blijven, maar noemt geen concrete plannen. Akamai sluit zich in een reactie aan bij de voorstellen van Google om belangrijke software te categoriseren en IBM zegt tegen ZDnet dat de overheid en industrie nauwer samen moeten werken om securityontwikkeling van opensourcesoftware te verbeteren.

De bedrijven hielden een gesprek met het Witte Huis, waar onder andere het ministerie van Defensie en de Cybersecurity and Infrastructure Security Agency, of CISA, bij waren aangesloten. De overheidsinstanties wilden een discussie over het beveiligen van opensourceprojecten en wat de bijdrage van het bedrijfsleven daarin kan zijn. Dat gebeurde met name na de log4j-kwetsbaarheid in Java, die in december vorig jaar werd ontdekt.

Het is niet voor het eerst dat techbedrijven hun steun aanbieden voor het verbeteren van maatschappelijke cybersecurityproblemen. Zo stelden Google en Microsoft vorig jaar al 25 miljard euro beschikbaar om projecten te ondersteunen, om overheden en bedrijven te helpen met beter beleid en om software in de supplychain te beveiligen.

Reacties (65)

[mocem]

Laat ze eerst maar stoppen met forken en gewoon netjes helpen met de projecten.

[Some12]

Forken kan best leiden tot gezonde concurrentie en keuze-vrijheid.

[mocem]

Je heb natuurlijk forken en forken. BoringSSL van Google en AWS met elastic vind ik niet chic.

[Goderic]

BoringSSL en AWS met elastic vindt ik net zeer goede redenen voor forks.

Elastic was niet meer open source onder de nieuwe licentie, een fork was niet te vermijden. BoringSSL is specifiek getuned voor Google en de wijzigingen passen niet in OpenSSL.

[datajuggler]

Elastic heeft zijn licentiemodel aangepast op een zelfde manier als MongoDB met SSPL heeft gedaan: AGPL v3 + 1 extra clausule. Die clausule laat niet toe de software aan te bieden as-a-service zonder die code ook openbaar te maken on AGPL voorwaarden. Tuurlijk zien AWS, GCP, Azure en consorten het niet zitten om de code van hun platform vrij te geven. Dus forken of imiteren ze maar op. "Voor de community". Een erg onfatsoenlijke actie aangezien ze simpelweg kunnen samenwerken en een licentie afnemen en op die manier bijdragen tot de verdere ontwikkeling. AWS voor Elastic is een erg verwarrende zaak voor developers, geen portable oplossing en een grote black box zonder roadmap, net zoals de imitatie van MongoDB "DocumentDB" wat simpelweg niet werkt vergeleken met het origineel.

[Reactie gewijzigd door datajuggler op 23 juli 2024 15:30]

[MSalters]

"+ 1 extra clausule" klinkt alsof het maar een klein dingetje is. Maar dat betekent dus wel dat Elastic incompatible is met andere LGPL software. Licenties van software projecten zijn doorgaans vrij binair: als het niet dezelfde licentie is, dan is het een verschillende licentie.

Als je alleen Elastic host, dan maakt die voorwaarde relatief weinig uit. Maar voor developers is Elastic de zoveelste "crayon licentie". Licenses forken is minstens zo erg als software forken.

[latka]

Volgens mij heeft AWS voornamelijk geforked om het te kunnen 'tunen' (lees: net iets anders maken dan het originele product zodat overstappen niet triviaal is). De meeste AWS diensten zijn een geforkte en getweakt OSS component als ik het wel heb. Embrace/extend/extuingish is niet dood in 2022.

[RJG-223]

Forken kan best leiden tot gezonde concurrentie en keuze-vrijheid.

Volgens mij weet jij absoluut niet waarover je het hebt.

Forken is meestal een zeer slecht idee. Soms is het nuttig, met name als de onwikkelaar de toegang tot nieuwe versies beperkt (als de ontwikkelaar een bedrijf is), geen of te weinig bugs oplost, bijdragen frustreert, of niet innoveert. Of gewoon het projekt heeft laten vallen. Het resultaat is dan uiteindelijk dat slechts een van de twee versies succesvol is, en de andere niet. Of ze worden weer samengevoegd als het conflict bijgelegd is. En als beide forks wel succesvol zijn, dan betekent dat voor beiden projekten een verzwakking: minder ontwikkelaars per projekt, minder gebruikers, en dus ook betere kansen voor een concurrerend projekt.

De reden dat veel bedrijven forks maken, is overigens omdat het meer moeite kost om terug te geven, en dat kost geld. Veel managers in bedrijven begrijpen niet hoe het werkt, of het boeit ze niet (niet mijn projekt, niet mijn zorgen...). Dat het op den duur wel eens meer geld kan kosten als je daarna een nieuwe fork moet maken van een nieuwe versie, en al je eigen wijzigingen moet porten, dat is het probleem iemand anders.

[Mellow Jack]

Niet perse de waarheid. Zomaar dingen blijven toevoegen om uiteindelijk een product te krijgen met 100 features waarvan de meeste gebruikers gemiddeld 20 features gebruiken. Is ook niet echt een goed idee

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 15:30]

[Sandor_Clegane]

Dit. En gewoon die mensen betalen als ze er gebruik van maken.

[Krokant]

Is dit dan een pleidooi om geen gratis gebruik met de diverse open source licenties meer toe te laten?

[Sandor_Clegane]

Nee, het is meer een oproep voor een beetje fatsoen. Als je gebruik maakt van een bibliotheek en je hebt er baat bij (commercieel) beloon de maker dan gewoon.

Zal vast naïef zijn, maar het zou een hoop schelen denk ik.

[LurkZ]

Gaat inderdaad een hoop schelen omdat die bedrijven dan OS met de geldbuidel regeren.

[Krokant]

Nee, het is meer een oproep voor een beetje fatsoen. Als je gebruik maakt van een bibliotheek en je hebt er baat bij (commercieel) beloon de maker dan gewoon.

Je kiest als developer zelf welke licentie je aan je code hangt. Als je géén CC/MIT/Apache achtige license er op plakt, geldt het normale auteursrecht en zijn bedrijven die de code gebruiken je een vergoeding verschuldigd. Het is met andere woorden véél gemakkelijker om open-source met commerciele vergoeding eisen te bouwen (just put it on Github) dan dat je een eigen licentie die jij vindt dat bij je code past, er op plakt.

Natuurlijk... er is geen enkel bedrijf dat zulke code gebruikt want er is vaak genoeg een alternatief dat wél "free usage" (al dan niet met attribution/copyright/...) heeft. En dat is dan jammer, want uiteraard is het "free usage, even commercially" vaak ook een driver om een bepaalde library te laten groeien in user base.

Ik vind het dus wat kort door de bocht door te zeggen "de bedrijven moeten maar betalen". Het is een wisselwerkend ecosysteem, met producenten en consumers, waar een soort "vrije markt" dynamiek (vraag/aanbod) op is. Ofwel stap je daar als developer/bedrijf in mee, ofwel niet. Maar de keuze ligt bij elk. Als je bewust kiest, dan weet je waar je voor kiest en moet er achteraf niet gezeurd worden.

Het staat je als developer vrij op eender welk moment je licentiemodel aan te passen (Docker anyone?). Je bent baas over je eigen code, ook als die door miljoenen gebruikers gebruikt wordt!

[Reactie gewijzigd door Krokant op 23 juli 2024 15:30]

[Creesch]

Dat is wel een hele binaire interpretatie, hoewel je ook reageert op een behoorlijk binaire uitspraak. Laten we in plaats van "betalen" het woord "compenseren" gebruiken en dan wordt het al een stuk duidelijker.
Heel veel bedrijven leunen zwaar op open source projecten zonder hier ooit in enige vorm terug aan bij te dragen, maar verwachten dus wel impliciet dat de projecten waar zij van gebruik maken goed up-to-date zijn. Er is dus sprake van heel veel halen en weinig terugbrengen, dit terwijl bedrijven bij uitstek de middelen hebben om ook bij te dragen ter compensatie van al het werk wat zij niet meer hoeven te steken in het ontwikkelen van de functionaliteit uit de open source projecten.

Het zou inderdaad kunnen gaan om compensatie in de vorm van betaling, dat hoeft echter niet voor de software zelf te zijn. Dat een project open source is betekend niet dat mensen die er aan bijdragen niet betaalt hoeven te worden. Daarnaast hebben veel open source projecten hebben wel geld nodig voor een stukje infrastructuur voor documentatie en andere zaken. Dus simpelweg doneren kan al een manier zijn waarmee bedrijven zorgen dat open source projecten kunnen blijven bestaan.

Daarnaast kunnen bedrijven het ook stimuleren dat hun eigen programmeurs bijdragen aan open source projecten. Bijvoorbeeld een klein percentage van hun werk tijd per maand. Idealiter niet alleen de projecten waar het bedrijf gebruik van maakt maar ook simpelweg de keuze laten aan de ontwikkelaars.

Kortom, niet alleen maar halen maar ook brengen en daarmee bijdragen aan een gezond ecosysteem rondom open source.

Zie ook mijn reactie hier: Creesch in 'nieuws: Techbedrijven willen meer samenwerken om opensourcesoftwa...

[Krokant]

Heel veel bedrijven leunen zwaar op open source projecten zonder hier ooit in enige vorm terug aan bij te dragen, maar verwachten dus wel impliciet dat de projecten waar zij van gebruik maken goed up-to-date zijn.

Dat klinkt als een algemene uitspraak en ik ben gevoelsmatig geneigd het er mee eens te zijn. Maar is dat echt zo? Hebben we daar toevallig cijfers over?

Ik werk in een software omgeving waar men héél bewust omgaat met open source. We hebben interne policies over wat wel/niet kan, en onze code wordt geaudit (met eigen tooling) die van elke dependency uitvlooit welke licences er van toepassing zijn. Als je software voor een klant bouwt, wil je immers zeker zijn dat je niet verplicht bent code te open-sourcen als de klant dat niet wenst; als professionele developers vinden wij persoonlijk dat we ook geen license inbreuken willen begaan (dat is een beetje de discussie "it aint a crime if you don't get caught" waar ik het fundamenteel mee oneens ben, je mag een beetje ethiek hebben als professional).

Maar ik denk dat ik je gelijk moet geven - ik weet niet of dat in elk software ontwikkelteam in de Benelux zo strikt opgevolgd wordt.

Dus simpelweg doneren kan al een manier zijn waarmee bedrijven zorgen dat open source projecten kunnen blijven bestaan.

Ik heb het in een andere post ook al gezegd, je kiest als developer van open source software zelf welk soort vergoeding je verwacht voor het gebruik. Je kan heus zeggen dat het free for personal en paid for commercial usage is.

Je kan ten allen tijden die licentie veranderen en iedereen die in professionele context Docker for Desktop gebruikt, weet wat er over 2 weken staat te gebeuren.... exact dat!

Voor non-"free usage" software maken we bij ons vaak kosten-baten analyses: "hoeveel dagen kost het om dit te herimplementeren" vs "hoeveel gaat het kosten een contract op te stellen met de developer". Dat laatste is overigens verbazingwekkend duur (gewoon de legal guys betalen, niet de vergoeding aan de developer!), en veel developers zitten niet daar op te wachten voor hun specifieke projectje dat een MegaCorp Inc opeens met contracten afkomt. Dat kan ik je ook verzekeren .

(Uiteraard snap ik dat wat ooit voor iemand als "hobbyprojectje" begon met 2-3u per week wat maintenance snel kan uitgroeien tot een half bedrijf dat je moet runnen, en dat niet iedereen daar zit op te wachten. Maar op een gegeven moment moet je dan als developer ook zelf kiezen: wat wil je er mee gaan doen? Het is best ok dat je dan zegt "dat is het me niet waard, I stick to the few hours maintenance' -- dat kan je populariteit wel ondermijnen maar ok, that's the choice to make ... Ben het uiteraard niet eens dat een developer van een open source project de facto "verantwoordelijkheid" zou hebben naar gebruikers toe - maar dat is ook niet juridisch of feitelijk. Hopelijk legt men zichzelf die druk niet op... )

Daarnaast kunnen bedrijven het ook stimuleren dat hun eigen programmeurs bijdragen aan open source projecten. Bijvoorbeeld een klein percentage van hun werk tijd per maand. Idealiter niet alleen de projecten waar het bedrijf gebruik van maakt maar ook simpelweg de keuze laten aan de ontwikkelaars.

Volledig mee eens. Specifiek binnen ons team hanteren we de policy dat we minimaal bugs loggen en helpen troubleshooten als we er tegenaan botsen. Als we functionaliteiten toevoegen, bekijken we wat we kunnen bijdragen aan de repositories. Het is een moeilijke oefening vaak tussen "eigen investering", "klanteninvestering", "intellectual property", ... die je daarvoor moet maken. Naar mijn aanvoelen is dat bij ons de meeste developers gewoon goede/toffe code willen maken en niet met dat soort gedoe bezig zijn.

[Reactie gewijzigd door Krokant op 23 juli 2024 15:30]

[die4ever]

Forken wordt net aangemoedigd, als onderhouder van een opensource project wil je niet dat alle custom features voor bedrijf X mee onder uw eigen verantwoordelijkheid vallen.
Vaak voegen ze code toe om er daarna nooit meer naar te kijken en dan is het aan de community om ervoor te zorgen dat het allemaal blijft werken. Wat ze wel moeten doen is als ze fixes of verbeteringen vinden in de gemeenschappelijke code dat ze deze zouden kunnen terug overbrengen naar het project.

[gimbal]

Ik volg de gedachtegang wel, ik had zelf ook wel het gevoel dat er net iets teveel afsplitsingen of alternatieven gebouwd worden. Het werkt de vooruitgang wel een beetje tegen als diverse groepen individueel en onafhankelijk van elkaar eigenlijk dezelfde problemen oplossen. Samen sta je toch sterker.

Maar helemaal stoppen met forken, nee. Soms gebeurd het simpelweg om goede redenen. Zoals LibreOffice of MariaDB.

[Jerryy]

Of gewoon KISS: Keep it simple, stupid

Sorry hoor maar hoeveel procent van de gebruikers van log4j had nou zo een uitgebreide logging library nodig met LDAP support? Ik kan me niet voorstellen dat dit meer dan 5% was. Ik snap dat er veel legacy software is in bedrijven die moeilijk te vervangen is, maar dan kan je zo een vulnerability ook wel verwachten.

Daarbij vraag ik me echt af hoeveel deze lijst nou gaat doen. Er zijn er zo veel kleine libraries die door heel veel software wordt gebruikt, denk maar aan het left-pad debacle. Hoe lang gaat die lijst worden?

[die4ever]

Log4j2 (wat zeker geen legacy software is) zit nu eenmaal in heel veel software om makkelijker gecentraliseerde logging te doen. Is het een uitgebreid project? jazeker. Is het een slecht project? zeker niet. We liggen nu toch ook niet te roepen dat iedereen windows moet vervangen elke keer een RCE gevonden wordt? Want wie weet wat voor bugs er nog in die closed source troep zit?

Dat er heel veel commerciële bedrijven zijn die blind vertrouwen hebben op public libraries en geen code audits doen, daar zit het probleem in mijn ogen. Maar de mentaliteit daar is vooral "een andere partij zal het wel doen dus we geven er geen geld aan uit"

[Krokant]

Ik denk dat je overschat hoe "actief" management in een commercieel bedrijf daar mee bezig is. Ik denk dat er in veel board rooms (waar cyber security sinds een maand of 12 pas écht een topic op dat niveau is), er veel monden zijn opengevallen met log4j en de press coverage errond.

De realiteit is dat zulke dependencies vaak de keuzes zijn die individuele developpers, met wat geluk een development team, mogen maken. Gelukkig maar, want stel je voor dat je voor elke package een directeur moet laten aftekenen . Bij ons bestaan er duidelijke richtlijnen over welk soort licenties, welk soort maintenance er verwacht wordt voor je een pakket mag integreren in onze code, maar is dat overal zo?

"Blind vertrouwen" lijkt me dan ook geen oorzaak te zijn. Wel dat iedereen geen zin heeft om elke keer opnieuw het warm water uit te vinden en zijn eigen (waarschijnlijk nog crappier) code te schrijven -- lang leve libraries! ... en twee, omdat je onderschat wat het kost om zo een "audit" te doen om er dan wél vertrouwen in te hebben. Dat is vaak toch een individuele inschatting, ik weet niet of er metrics zijn over hoe betrouwbaar een third party library kan zijn?

[die4ever]

Ergens vind ik dat er iets te veel drama rond gemaakt is, en dat het development team van log4j2 best wel snel met een oplossing gekomen is. Het was een serieuze bug, elke RCE bug is serieus.
Het voordeel van Java libraries is dat je ze 9/10 kan patchen met een drop in replacement. Wel moet je weten welke applicaties het allemaal gebruikt en volgens mij is er geen 1 bedrijf die van elke aangekochte java applicaties gaat bijhouden welke libraries deze allemaal gebruikt. Een vendor zou wel makkelijk moeten kunnen zeggen welke libraries er allemaal in hun software zit.

It's the name of the game, als de commerciële gebruikers samen leggen voor een potje bounty money wordt er mss iets meer actief naar dit soort problemen gezocht.

[Jerryy]

Dat er heel veel commerciële bedrijven zijn die blind vertrouwen hebben op public libraries en geen code audits doen, daar zit het probleem in mijn ogen.

Dat is eigenlijk exact mijn punt. Vandaar de "KISS": je kan beter zelf simpele en begrijpelijke logging code schrijven met alleen ingebouwde java libraries dan blind een groot software project te vertrouwen.

Libraries zijn goed maar niet voor simpele code.

[die4ever]

Logging in een enterprise omgeving is/was geen simpel gebeuren. Het is niet gewoon ergens lokaal een file wegschrijven en klaar. Je wil algemene logging, maar je wil je logging ook in stukken kunnen splitsen voor bepaalde modules binnen uw software, of bepaalde soorten events naar ergens anders wegschrijven, of....

Daarom dat Log4j heel populair is je kan achteraf alsnog een hoop configureren zonder dat je de applicatie moet aanpassen.

[Jerryy]

Er is zeker een plaats voor zulke ingewikkelde logging! Ik vraag me toch nog steeds af in hoeveel procent van de gevallen zulke logging ook daadwerkelijk gebruikt werd. Ik zie steeds vaker dat een grote library gebruikt wordt voor maar in 1 specifiek doeleind. Kan je niet beter een simpele library gebruiken die past bij je doel en die makkelijk te begrijpen is?

Het is natuurlijk een lastig probleem en ik praat er wel makkelijk over. Software vulnerabilities gebeuren nou eenmaal. Toch ben ik van mening dat we bij veel dingen al vroeg hadden kunnen zien dat het misschien niet de meest verstandige keus was om library x te gebruiken of om ingewikkelde feature y te implementeren.

[Reactie gewijzigd door Jerryy op 23 juli 2024 15:30]

[die4ever]

In het geval van Log4j2 weet ik dat het vaak als een verplichting bij uw software zit om deals bij grote enterprise klanten te kunnen sluiten. Ik ga zeker niet ontkennen dat je soms beter af bent met een kleine library of gewoon zelf de feature te schrijven ipv een library te gebruiken. Kleinere libraries hebben als nadeel dat ze vaak niet lang leven en geen community kunnen bouwen/bijhouden. Een project moet uiteraard een bepaalde interesse wekken en werk hebben om in leven te blijven.

[Sandor_Clegane]

Log4J is een standaard, zo simpel is het. Net als met crypto bibliotheken krijg je dan de opmerking: "waarom het wiel opnieuw uitvinden?" of "denk jij dat je het beter kan dan de ontwikkelaars die al honderden uren in die bibliotheek hebben gestoken?"

Het is damned if you do, damned if you don't.

[Guus...]

Dit gaat over een open source project. De maker mag dat zo ingewikkeld maken als ze willen en ook LDAP support toevoegen en dit default aanzetten. Niemand heeft iets te eisen van de ontwikkelaar van log4j, als je het anders wil maak je een fork of een eigen tool.

Dat log4j geen KISS aanhield hadden bedrijven moeten onderzoeken en herkennen voordat ze de library importeerden. Het artikel gaat erover dat bedrijven verantwoordelijkheid moeten gaan nemen voor de veiligheid van de open source software die ze gebruiken.

[Jerryy]

Dat log4j geen KISS aanhield hadden bedrijven moeten onderzoeken en herkennen voordat ze de library importeerden. Het artikel gaat erover dat bedrijven verantwoordelijkheid moeten gaan nemen voor de veiligheid van de open source software die ze gebruiken.

Dit is exact mijn punt! Ik doel er meer op dat bedrijven zelf moeten opletten. De bedrijven hadden moeten zien dat log4j te ingewikkeld is voor hun doeleind, dus hadden ze wat anders moeten gebruiken (KISS). Ik zeg niet dat log4j KISS had moeten gebruiken, er is zeker een plaats voor ingewikkelde logging.

[latka]

Dan blijven er weinig Spring en JSF projecten meer over als je dan toch bekende grote libraries wilt noemen waarvan je meer dan 80% niet gebruikt (in het geval van JSF volledig terecht overigens).

[gimbal]

Dat is moeilijk te zien echter, ik had zelf ook niet door dat er allemaal extra lagen bijgetimmerd waren. Als je de "normale" documentatie induikt dan is log4j2 niet meer dan de zoveelste logging implementatie waar je log.info(), log.debug(), etc. etc. aanroept waar logs naar de console en/of files gaan, heel onschuldig allemaal. Je moet echt bewust gaan zoeken wil je leren dat er extra enterprisy zaken bijgebouwd zijn omdat het allemaal zo handig is.

En als je log4j 1.x hebt meegemaakt dan was het ook niet veel meer dan dat, destijds. Naar mijn idee was log4j2 niet veel meer dan log4j 1.x met performance verbeteringen. Ik was redelijk met stomheid geslagen toen dit hele circus begon, en ik was niet de enige. Vooral de JNDI functie had een redelijk hoog wtf gehalte.

Maar het is niet log4j2 eigenlijk waar ik direct het pijnpunt wil leggen. Het feit dat JNDI een flink lek kan vormen in je beveiliging was jaren eerder al bewezen bleek al snel als reactie op dit verhaal. Maar ik was me nergens van bewust, er is ook zo weinig aandacht aan geschonken al die jaren. Dat doet me nog wel het meeste pijn eigenlijk.

[RJG-223]

Sorry hoor maar hoeveel procent van de gebruikers van log4j had nou zo een uitgebreide logging library nodig met LDAP support

Sorry hoor, maar hoeveel procent van de gebruikers heeft alle features van de Linux kernel nodig ? Of van Windows ? Of van MS-Word ? etc. Niemand. Toch is er voor alle features wel een groep mensen / bedrijven die ze wél nodig heeft. En 5% van de gebruikers is wel héél veel gebruikers...

Als iedereen voor alles z'n eigen software gaat schrijven, omdat ze bepaalde features niet nodig hebben, dan is dat veel meer werk, en veel kostbaarder.

Het voordeel van een krachtige library (of OS, of wordprocessor), is dat je die eenmaal moet leren gebruiken, en dat als je eisen dan veranderen, je waarschijnlijk niet iets nieuws hoeft te leren, maar gewoon een extra feature die er al is kunt gebruiken.

[cariolive23]

Of gewoon KISS: Keep it simple, stupid

Kan ik me helemaal in vinden! Maar dan wel beginnen met de applicatie die je aan het ontwikkelen bent. Logging (want dat is wat log4j doet) is dan een secundair probleem, die uiteraard ook zo simpel mogelijk moet worden gehouden.

Wat ik vrijwel dagelijks tegenkom in audits, is code die wel lijkt te zijn bedacht om zo complex mogelijk te zijn. Eenvoud moet imho een doel op zich zijn. En ook eentje waar je op afgerekend mag/moet worden.

Methods van een paar duizend regels code, is er nou echt iemand die denkt dat 'ie dit begrijpt? En dat hier geen bugs in zitten? Met ontslag op staande voet kom je nog goed weg...

[Jerryy]

Kan ik me helemaal in vinden! Maar dan wel beginnen met de applicatie die je aan het ontwikkelen bent. Logging (want dat is wat log4j doet) is dan een secundair probleem, die uiteraard ook zo simpel mogelijk moet worden gehouden.

Precies!

Wat ik vrijwel dagelijks tegenkom in audits, is code die wel lijkt te zijn bedacht om zo complex mogelijk te zijn. Eenvoud moet imho een doel op zich zijn. En ook eentje waar je op afgerekend mag/moet worden.

Methods van een paar duizend regels code, is er nou echt iemand die denkt dat 'ie dit begrijpt? En dat hier geen bugs in zitten? Met ontslag op staande voet kom je nog goed weg...

Tenzij die werknemer zijn doel is dat die enige is die het kan begrijpen . Nee maar je hebt volkomen gelijk. Het is natuurlijk niet makkelijk om simpele en goede code te schrijven, vooral als het om beveiligingskritieke code gaat zoals crypto (hiervoor moet je wel libraries gebruiken).

[TlighT]

Ik dit dan eerder bij de makers van log4j leggen dan bij de developers. Log4j had van de LDAP support een optionele dependency moeten maken zodat developers die expliciet moeten aanzetten/toevoegen als ze van de functionaliteit gebruik willen maken.

[Jerryy]

Zeker mee eens! Toch kan je je wel even 2 keer afvragen of je überhaupt wel een library nodig hebt voor loggen. Java.util.logging heeft al genoeg features voor 95% van de gebruikers lijkt me.

[cariolive23]

Java.util.logging heeft al genoeg features voor 95% van de gebruikers lijkt me.

En dat is precies het probleem. In ieder team van 20 programmeurs heb je dan iemand die iets nodig heeft/denkt te hebben, wat er niet in zit. En dan komt met de oplossing log4j. De anderen vinden het ook mooi, zien dan ook mogelijkheden om extra logging details te krijgen etc. en je hebt weer een extra library aan je broek hangen. Met de bekende gevolgen van dien.

[Jerryy]

Vandaar de "5%" in mijn statement. Als je 1 software project hebt in je organisatie met log4j waardoor je hele bedrijf vulnerable is, dan heb je een ander onderliggend probleem.

[latka]

Waarom? Omdat jij dat vind? Dan had je mee moeten helpen met de ontwikkeling. Alle andere zaken zijn kapiteins op de kade.

[Creesch]

Aan de ene kant is dit natuurlijk een goede ontwikkeling, aan de andere kant is dit weer erg typisch een voorbeeld van de problematische verhoudingen tussen open-source projecten en commerciële partijen die er gebruik van maken. Waar ik op doel is het feit dat vaak men het liefst er gebruik van maakt zonder al te veel bij te dragen maar dus wel impliciet verwacht dat de open source projecten worden bijgehouden. Als bedrijven er dan voor kiezen om bij te dragen aan open source projecten dan is het vaak in een zeer beperkte scope en eigenlijk alleen dat stuk waar zij belang bij hebben. Waar vervolgens wel van de open source projecten wordt verlangt dat ze de code reviewen en zo snel mogelijk integreren.

Dit zie je dan ook terug op de volgende manier

Google pleit onder andere voor een openbare lijst waarop opensourceprojecten worden opgenomen die als 'kritiek' worden beschouwd, schrijft het bedrijf in een blogpost. Hoe belangrijk die projecten zijn moet worden gebaseerd op hun 'invloed en belang voor een project'.

Overigens is het niet allemaal negatief wat mij betreft. De algemene ondersteuning voor open source projecten en de marktplaats die in de alinea daarna wordt aangekaart is een zeer goed idee. Hopelijk wordt daar dan ook een invulling aan gegeven en dan ook op een manier die productief werkt voor open source in het algemeen. Want ook daar schuilt weer het risico dat een dergelijke marktplaats eigenlijk alleen gebruikt zal worden door bedrijven voor zeer specifiek die software die zij gebruiken en nu iets nodig hebben.

Voor de mensen die nu willen reageren met "het is toch logisch dat bedrijven ondersteunen wat ze gebruiken?". Dat klopt inderdaad in de basis of wat cynische als je oogkleppen op hebt. Open source projecten die door jou bedrijf gebruikt worden zijn ergens ontstaan en hebben kunnen groeien tot het punt dat je als bedrijf het wil gaan inzetten. Technologie is constant in beweging op diverse fronten en dat betekend ook dat je in de toekomst weer andere projecten zal gaan gebruiken en daarop vertrouwen. Het is daarom voor bijna alle bedrijven in de softwareontwikkeling van belang dat er een gezond open source ecosysteem is met solide projecten en goede keuzemogelijkheden. Op de lange termijn is het daarom in mijn optiek dan ook niet meer dan logisch dat je op een breder vlak bijdraagt aan open source en niet alleen met oogkleppen aan features en producten die je op dat moment nodig hebt.

[Reactie gewijzigd door Creesch op 23 juli 2024 15:30]

[beerse]

Misschien moeten de grote organisaties zoals google en microsoft eens stoppen met het smijten met geld voor dit soort zaken maar zelf een eigen open organisatie/afdeling opzetten. Laat google maar eens aangeven wat zij belangrijk vinden en waar zij op letten en hoe ze dat doen. Laat microsoft en ibm het zelfde doen vanuit hun organisatie en vanuit hun perspectief. En dan bedoel ik vanuit de holding gezien en binnen de organisaties onafhankelijk van de opensource-poten die ze zelf hebben (zoals ibm en redhat)

Daarnaast ken ik ook organisaties zoals CIS (https://www.cisecurity.org/). Een organisatie die in mijn ogen redelijk onafhankelijk en open (open source?) werkt. Zij geven voorstellen voor veilige instellingen in de diverse producten die ze bekijken. Een dergelijke organisatie kan de inspanningen van de grote commerciële gebruikers zoals google/microsoft/ibm bij elkaar vegen, met elkaar vergelijken en daar het grote gemene veelvoud en de gemene deler van bepaalen waar dan de rest van de wereld gebruik van kan maken.

Laat de google/microsoft/ibm liever niet met geld strooien. Dat geeft scheve ogen.

[Reactie gewijzigd door beerse op 23 juli 2024 15:30]

[Rob Coops]

Sorry maar ik kan het er niet helemaal mee eens zijn.

Bijvoorbeeld Google heeft weinig interesse in het ontwikkelen en onderhouden van de meerderheid van open source projecten omdat ze helemaal niets nuttigs bieden voor het bedrijf. En wat ze doen veel al door een flink aantal andere projecten ook gedaan wordt. Het is erg normaal in de open source wereld waar zeker voor nieuwe projecten het niet zelden start met iemand die vind dat een ander iets fout doet dan wel niet de "juiste" interface/features bied dan andere al bestaande projecten.

Het idee dat Google bijvoorbeeld niet bij zou dragen aan zeer veel open source projecten is onzin, de hoeveelheid mensen die Google in dienst heeft alleen al zorgt er voor dat er zeer veel projecten gestart of onderhouden worden door mensen die voor het bedrijf werken. Zelf heeft Google ook een flink aantal open source projecten gestart of bestaande code open source gemaakt, net als Amazon, IBM en ja zelfs Microsoft. Sterker nog de overgrote meerderheid van de bijdragen aan bijvoorbeeld de Linux kernel komt bij deze grote bedrijven vandaan door mensen die onder werktijd hier aan werken. En een flink deel van de rest wordt door voor een deel de zelfde mensen bijgedragen buiten hun werktijd om.

Als bedrijf dat bijvoorbeeld log4j gebruikt is het van levensbelang dat het geen remote code execution toestaat. En als blijkt dat dit soort dingen wel mogelijk zijn dan zul je of passief moeten wachten op een oplossing of zelf code moeten bijdragen om het probleem op te lossen.
Het probleem even oplossen doe je niet zonder gedegen kennis van de code en een omgeving waar je de code kunt bouwen en testen. Dat alles is niet iets wat je even in een verloren uurtje doet naast je andere taken. Wat Google en de andere dus voorstellen is dat zij een lijst met voor hen kritieke projecten uitzoeken en daar mensen en dus geld tegen aan gooien om dit te onderhouden.
Een commercieel bedrijf als Google zal echt niet een vaste lijst aanhouden waar met nooit van af zal wijken, als ze een mogelijkheid zien om bijvoorbeeld geld te verdienen door ffmpeg te gebruiken in een project dan zullen ze dat zeker doen en als het een kritiek component wordt voor het bedrijf dan wordt het gewoon aan de lijst toegevoegd en zullen ze ook hier mensen en geld tegenaan gooien om het project te onderhouden en te beveiligen.

Als ze willekeurige projecten zouden gaan ondersteunen hoe kunnen ze dan ooit waarde er uit halen? Als zij een open source retro emulator voor Gameboy games of PS3 games gaan ondersteunen welk nut heeft dat voor het bedrijf. Het idee dat omdat het een groot bedrijf is dat ze dus ook maar geld moeten weg gooien om de hobby van een klein aantal mensen te ondersteunen is onzin.
Als ze gebruik maken van de resultaten van de hobby en het als een belangrijk iets zien voor het bedrijf is het niet meer dan logisch dat zij hier geld en tijd in steken om het project naar een hoger niveau te helpen.

[Creesch]

Het idee dat Google bijvoorbeeld niet bij zou dragen aan zeer veel open source projecten is onzin,

Dat is dan ook niet wat ik zeg, al zeker niet in dit soort binaire termen.

[TheAncientDovah]

Dit is een positieve ontwikkeling. Ik hoop echter dat overheden ook het belang van open source software inzien en zich hier ook voor willen inspannen op de een of andere manier.

[Some12]

Dat hoop ik ook, dat er gekeken wordt naar het belang van free software.

Van mij part mag de hele versioning control tevens gekoppelt worden aan herleidbare identiteiten van echte mensen.

Technologie is geen speelgoed meer voor consumenten. Er hangen (in het geval van ziekenhuizen bijvoorbeeld) belangen aan vast die impact hebben op mensenlevens.

[Brilsmurfffje]

Is dit plaatje weer eens woest actueel:
https://imgs.xkcd.com/comics/dependency.png

Opensource laat mooi zien dat als je iets vanuit een oprechte passie doet je soms met dingen kunt komen waar grote bedrijven alleen maar van kunnen dromen en het dan gelukkig nog kunnen forken..

[86ul]

Waarom moet de big tech/Digital Regime dingen bepalen voor opensource, terwijl OS - of beter FOSS- zelfregulerend wil zijn?

[TheAncientDovah]

Veel open source software projecten begonnen ooit als commercieel project of worden veel gebruikt door commerciële bedrijven. Daarom willen deze bedrijven ook invloed kunnen uitoefenen op de richting van deze projecten. Zolang dit op een transparante manier gebeurt is daar niks mee mis.

[86ul]

Veel open source software projecten begonnen ooit als commercieel project of worden veel gebruikt door commerciële bedrijven. Daarom willen deze bedrijven ook invloed kunnen uitoefenen op de richting van deze projecten. Zolang dit op een transparante manier gebeurt is daar niks mee mis.

Interressant. Van Red Hat, Canonical, en System76 wist ik al van zoiets. Kennelijk is het een meer wijdbreed iets. Merci, helpvol

[RJG-223]

Waarom moet de big tech/Digital Regime dingen bepalen voor opensource, terwijl OS - of beter FOSS- zelfregulerend wil zijn?

Het is een beetje kort door de bocht om te zeggen dat OS/FOSS iets wil. Het is geen bedrijf. Iedereen wil andere dingen, en er is geen centrale leiding die iets te zeggen heeft.

En als je het over zelfregulering wilt hebben (of FOSS dat nu 'wil' of niet), dan is dat nu precies wat er op dit moment ook aan het gebeuren is. Er is niet één bedrijf die zegt: ik ga dit doen (centrale aansturing), er zijn een aantal belanghebbenden, in dit specifieke geval bedrijven, die de software de moeite waard vinden, en iets willen doen om te zorgen dan die software, en de gemeenschap, ook gezond blijft (dat is dus zelfregulering - er is niemand die ze bevolen heeft om dat te doen). En dat is slim, want de kosten zouden voor elk van hen véél hoger zijn als dat niet lukte. Bedrijven zijn ook onderdeel van de FOSS gemeenschap...

[Reactie gewijzigd door RJG-223 op 23 juli 2024 15:30]

[86ul]

[...]
Het is een beetje kort door de bocht om te zeggen dat OS/FOSS iets wil. Het is geen bedrijf. Iedereen wil andere dingen, en er is geen centrale leiding die iets te zeggen heeft.

Het klopt dat een community soms/vaak niet eensgezind zijn, maar het als of één en dezelfde community verder gaan, of opsplitsen als één maar ander community verder gaan. Vandaar ook community, als in one common unity.

En als je het over zelfregulering wilt hebben (of FOSS dat nu 'wil' of niet), dan is dat nu precies wat er op dit moment ook aan het gebeuren is. Er is niet één bedrijf die zegt: ik ga dit doen (centrale aansturing), er zijn een aantal belanghebbenden, in dit specifieke geval bedrijven, die de software de moeite waard vinden, en iets willen doen om te zorgen dan die software, en de gemeenschap, ook gezond blijft (dat is dus zelfregulering - er is niemand die ze bevolen heeft om dat te doen). En dat is slim, want de kosten zouden voor elk van hen véél hoger zijn als dat niet lukte. Bedrijven zijn ook onderdeel van de FOSS gemeenschap...

Merci, erg helpvol.

[RJG-223]

Het klopt dat een community soms/vaak niet eensgezind zijn, maar het als of één en dezelfde community verder gaan, of opsplitsen als één maar ander community verder gaan. Vandaar ook community, als in one common unity.

Ik bedoelde eigenlijk dat iedereen die bijdraagt aan FOSS, of wat voor manier ook, zijn eigen motieven heeft. Sommigen willen zelfregulerend zijn, of sommigen vinden zelfs dat alle FOSS uit idealisme zelfregulerend moet zijn. Anderen vinden juist van niet, of geloven daar niet in, bijvoorbeeld mensen of bedrijven die een basisprodukt open source maken, maar extra (enterprise) features en/of support voor geld verkopen.

En er zijn heel veel andere motieven en meningen, zelfs binnen één community. Het enige 'common' gedeelte is meestal dat ze een projekt de moeite waard vinden om aan bij te dragen (of te gebruiken). Vandaar mijn punt dat de stelling dat FOSS iets specifieks 'wil', een beetje kort door de bocht is. Je kunt niet een hele groep mensen en bedrijven de mening toedichten van een paar meer uitgesproken en vocale leden in die groep.

[86ul]

Begrijpelijk, merci

[Some12]

Omdat de wil van hobbyisten minder zwaar weegt dan het maatschappelijk belang van infrastructuur. Denk aan bijvoorbeeld ziekenhuizen.

Dat wilt niet zeggen dat je daar niet vrij rondom mag hobbyen.

[86ul]

Niet elk FOSS is een hobby, sommige zijn juist betaald door donaties. Dus ik had het eerder op de proactieve FOSCommunity. Punt begrepen, maar dat kan ook in samenspraak met een proactieve FOSC.

[RJG-223]

Omdat de wil van hobbyisten minder zwaar weegt dan het maatschappelijk belang van infrastructuur. Denk aan bijvoorbeeld ziekenhuizen.

Het is eerder zo dat de belangen van een hobbyist (want daar gaat het in dit specifieke geval om - veel open source is echter beslist géén hobby, maar wordt ontwikkeld dóór of met significante steun van commerciële bedrijven), veel minder zwaar gewogen worden dan de belangen van bedrijven en overheden (zeg maar: de actoren met het geld), of van de maatschappij. Zelfs als die bedrijven of overheden, of de maatschappij/infrastructuur, afhankelijk zijn van de software die ontwikkeld wordt door die hobbyist. Maar omdat die afhankelijkheid niet duidelijk genoeg is voor alle betrokkenen, hebben die belanghebbenden met geld niet in de gaten hoezeer hun belang feitelijk gediend is bij het goed functioneren van die hobbyist.

Dus het gaat niet om de wil van de hobbyist, maar om het feit dat het verband tussen wat die hobbyist doet, en de belangen van actoren met voldoende geld om die hobbyist te betalen niet duidelijk genoeg zijn. Zodat de hobbyist onterecht niet betaald wordt voor zijn vitale bijdrage.

[LurkZ]

De dood van open source.
Als de tech bedrijven voor (extra) beveiliging gaan zorgen hebben ze invloed.

"om software te ontdekken die een 'systematisch risico vormen' voor grote projecten."
Lees alle open source die concurreert met closed source.

En ja het bovenstaande is een negatieve outlook, maar wel precies wat het artikel beschrijft. Iets sturen kan alleen met invloed. Big Tech is dan een soort kwaliteits keurmerk. "Pas op, dat os project is gevaarlijk, kies on Google/Apple/MS/IBM/... product."

Voeg nog wat regelgeving toe die te kostbaar is voor kleine bedrijfjes maar wisselgeld voor Big Tech en de greep is weer wat steviger.

[syl765]

De grote techbedrijven bepalen welke kant opensource op gaat in grote lijnen. De tijd dat de community bepaalt is wel een beetje achter ons. Neem systemd (even in het midden laten of dit nu wel of geen goed iets is en dit in een welles nietes systemd thread verandert) als groot voorbeeld. RedHat wilde systemd waar er vanuit de community best wel wat weerstand was, maar tegen een RedHat is niet makkelijk op te boxen. Eerste klas Debian ontwikkelaars lopen zelfs weg als ook Debian systemd gaat implementeren. RedHat maakt Gnome afhankelijk van systemd en als je dan als Linux distro Gnome wil meeleveren dan ontkom je er niet aan om ook systemd te gaan implementeren. Ondanks dat de BSD's bijvoorbeeld nooit systemd zullen gaan gebruiken heeft de Linux beweging systemd al dan niet vrijwillig als init system in gebruik.
En dat is diezelfde linux community die in de jaren 90 moord en brand schreeuwde als er weer een software pakket op de markt kwam die alleen voor windows was. Alles moest cross platform ontwikkeld worden, geen uitzonderingen van een OS. En nu zie je dus best wel wat linuxism onder opensource software ontstaan en tellen opeens andere OS'en niet meer mee zoals de BSD's. Als je geen systemd gebruikt, dan is het gewoon jammer voor je, wij bepalen!
Een mooi voorbeeld is haproxy waarbij de vraag wel eens is gekomen of men KTLS gaat ondersteunen voor FreeBSD waarbij TLS in de kernel afgehandeld word. Het antwoord laat zich raden alleen als linux dit ook gaat ondersteunen! Erg jammer om te zien.

Of het de goede kant op gaat met linux, ik waag het te betwijfelen. Een mooie video serie is die van Bryan Lunduke genaamd Linux Sucks. Een Pro linux man waarin hij elke video begint met het afkraken van Linux maar het later allemaal zo weet om te draaien dat het eigenlijk allemaal heel positief is en Linux dus een fantastisch OS is (wat het in grote lijnen ook is). Maar de laatste video's is hij toch echt niet meer zo positief, en dan vooral door het missen van de mensen met lange baarden maar wel zalen vol met mensen met stropdassen! Linux is niet meer van de community, Linux is van RedHat, AWS, Google en een hoop opensource software gaat ook die kant op.
https://lunduke.substack....x-sucks-videos-collection

[Trinitronic]

Linux is niet meer van de community, Linux is van RedHat, AWS, Google

Verwar distro's niet met toevoegingen aan de linux kernel, die je trouwens zelf kan aan of uitzetten

[martburg]

99% van de reacties geeft blijk van het feit dat de inzender niets begrepen heeft van het artikel, wellicht niet eens het hele artikel heeft gelezen. Zag Log4j en riep ook wat.

Het artikel zoekt een oplossing om veilige open-source producten te hebben. Anders gezegd: het moet zeker zijn dat de software doet wat beloofd is en doet niets wat schadelijk of onnuttig is.

De oplossing is eigenlijk simpel.
Toen wij (de oudjes in het vak) nog in een bedrijf software schreven, waren er 3 teams: ontwerpers, bouwers en testers.. Ik ken geen groot bedrijf dat geloofde dat programmeurs onfeilbaar zijn.
Als een bedrijf heden ten dage (geloof ik) open-source software in eigen projecten opneemt, wordt hoogstens geverifieerd en getest wat in huis is gebouwd. FOUT. Alle bouwstenen, gekocht of gemaakt moeten getest worden.
Bij veel-gebruikte open-source libraries zou dat veel dubbel werk opleveren als iedereen steeds weer alles moet testen. Dus moeten er verificatie bedrijven komen die certificeren (opgezet door die bedrijven die zo hard roepen dat er wat aan gedaan moet worden?).
Zo'n bedrijf kloont een open source project, verifieert het project grondig (ook zero days) en biedt dan het gekloonde pakket (gratis) en een certificaat (tegen betaling) aan aan bedrijven, die daardoor de libraries van dat project niet meer hoeven te testen. Vertrouw je amerikaanse bedrijven niet, kies dan een chinees certificaat. of omgekeerd, Misschien moeten we wel als EU zo'n systeem opzetten.
Er moet echter wel iets aan de EULA van open source projecten worden veranderd: deze moet toestaan dat een bedrijf, dat een kloon certificeert, mag bepalen waar de koper van het certificaat de kloon mag installeren en moet doorontwikkelen van deze kloon binnen het bedrijf kunnen verbieden om afsplitsingen te voorkomen en aan te moedigen om het originele project te verbeteren. Vrijwel identiek met de huidige praktijk bij commerciële producten met een licentie overeenkomst.

[Trinitronic]

Lees: commerciële mega bedrijven willen nu ook macht over opensource.

[martburg]

Nee, commerciële mega bedrijven willen enkel VEILIGE opensource.

[Trinitronic]

Dan moeten ze zelf eraan (mee)werken.
Zo simpel is het