← Nieuwste papers
💻 computer science

Unsafe and Unused? A History of Utility Code in Mature Open Source Projects

Door middel van een longitudinale miningstudie van zeven volwassen open-source-projecten onthult dit artikel dat bestanden met "util" in de naam aanzienlijk vaker betrokken zijn bij kwetsbaarheden en vaak ongebruikt blijven, waarmee de noodzaak wordt onderstreept dat ontwikkelaars de veiligheid en het onderhoud van dergelijke hulpcodes op de lange termijn opnieuw moeten overwegen.

Oorspronkelijke auteurs: Brandon Keller, Kaitlin Yandik, Angela Ngo, Andy Meneely

Gepubliceerd 2026-05-01
📖 5 min leestijd🧠 Diepgaand

Oorspronkelijke auteurs: Brandon Keller, Kaitlin Yandik, Angela Ngo, Andy Meneely

Oorspronkelijk artikel vrijgegeven aan het publieke domein onder CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een enorme, bruisende stad voor waar duizenden architecten en bouwers voortdurend aan een gigantische, gedeelde wolkenkrabber bouwen en renoveren. Deze wolkenkrabber is een open-source softwareproject. In deze stad geldt een speciale regel: wanneer een bouwer een hulpmiddel of een functie creëert die voor iedereen nuttig zou kunnen zijn – zoals een universele moersleutel of een hoofdsleutel – wordt hij aangemoedigd dit in een specifieke, duidelijk gelabelde ruimte te plaatsen die "Util" heet (afkorting van "Utility").

Het idee is geweldig: in plaats dat elke bouwer zijn eigen moersleutel maakt, grijpen ze allemaal één uit de "Util"-ruimte. Dit bespaart tijd en houdt de zaken georganiseerd.

Maar een team onderzoekers van het Rochester Institute of Technology stelde een simpele vraag: Wat gebeurt er eigenlijk met deze "Util"-ruimtes na verloop van tijd? Blijven ze veilig en bruikbaar, of worden ze gevaarlijk, rommelig en genegeerd?

Om dit uit te zoeken, bestudeerden ze zeven beroemde "wolkenkrabbers" (softwareprojecten zoals de Linux Kernel, Django en Apache Tomcat) over een periode van in totaal 147 jaar aan ontwikkeling. Ze keken naar de geschiedenis van elk bestand, elke hernoeming en elke beveiligingsfix. Hier is wat ze ontdekten, eenvoudig uitgelegd:

1. De "Util"-ruimtes zijn overal (maar niet altijd gebruikt)

De onderzoekers ontdekten dat "Util"-ruimtes zeer algemeen zijn. In sommige projecten is bijna 20% van alle ruimtes in het gebouw gelabeld als "Util".

  • Het goede nieuws: Deze ruimtes worden intensief gebruikt. In sommige projecten worden de hulpmiddelen in de "Util"-ruimte 7 keer vaker opgepakt en gebruikt dan hulpmiddelen in gewone ruimtes.
  • De adder onder het gras: Alleen omdat een ruimte "Util" heet, betekent niet dat deze efficiënt wordt gebruikt. Soms creëren bouwers een nieuwe "Util"-ruimte, om deze later weer om te dopen omdat hij eigenlijk niet nuttig was, of ze verlaten hem volledig.

2. De "Util"-ruimtes zijn rommeliger (complexer)

Als een gewone ruimte een eenvoudige kast is, is een "Util"-ruimte vaak een chaotische werkplaats vol met verwarde draden en complexe machines.

  • De studie vond dat in 6 van de 7 projecten, de "Util"-bestanden aanzienlijk complexer waren dan gewone bestanden.
  • Waarom? Omdat iedereen zijn "gemeenschappelijke" hulpmiddelen daar in gooit. Na verloop van tijd worden deze bestanden opgeblazen met te veel functies, waardoor ze moeilijker te begrijpen en moeilijker veilig te houden zijn.

3. De "Util"-ruimtes zijn een teaminspanning (maar een chaotische)

Je zou denken dat als een bestand "Util" is, iedereen weet hoe het te gebruiken. De studie keek naar wie aan deze bestanden werkte.

  • Ze ontdekten dat de persoon die een hulpmiddel in de "Util"-ruimte bouwde, vaak niet dezelfde persoon is die het gebruikt.
  • In feite, in de meest recente data, waren meer dan 57% van de mensen die met deze bestanden werkten, ofwel alleen bezig met het bouwen ervan of alleen met het gebruiken ervan, maar zelden met beide. Het is als een fabriek waar de mensen die de machines bouwen ze nooit echt bedienen, en de mensen die ze bedienen ze nooit repareren. Deze disconnectie kan leiden tot verwarring.

4. De "Util"-ruimtes zijn gevaarzones (beveiligingsrisico's)

Dit is de belangrijkste bevinding. De onderzoekers behandelden "kwetsbaarheden" (beveiligingsgaten) als scheuren in de fundering van het gebouw.

  • De grote piek: In de vroege dagen van een project, wanneer er zeer weinig bestanden zijn, is een "Util"-bestand tot 10 keer waarschijnlijker om een beveiligingsscheur te hebben dan een gewoon bestand.
  • Op lange termijn: Zelfs naarmate projecten rijpen, blijven "Util"-bestanden riskanter. De studie vond dat "Util"-bestanden 2,75 keer waarschijnlijker betrokken zijn bij een beveiligingsfix dan niet-"Util"-bestanden.
  • Het probleem van de "terugkerende overtreders": Wanneer een beveiligingsgat in een "Util"-bestand wordt gerepareerd, is het zeer waarschijnlijk dat het opnieuw gebeurt. Het is als een lek in een pijp dichten, alleen om dezelfde pijp een paar maanden later weer te zien barsten. Dit suggereert dat het team niet leert van de fout, misschien omdat het bestand te complex is om het goed te repareren.

5. De Linux Kernel is de buitenbeentje

De onderzoekers merkten op dat de Linux Kernel (een zeer stabiel, massaal project) zich anders gedroeg dan de anderen.

  • Het volgde niet de gebruikelijke trends. Zijn "Util"-bestanden waren niet per se gevaarlijker en ze werden niet zo vaak hernoemd.
  • De onderzoekers vermoeden dat dit komt omdat de Linux Kernel zo oud en stabiel is dat hij zijn "Util"-gewoonten al had vastgelegd voordat de data die ze bestudeerden zelfs maar begon. Het is als een oud gebouw dat zo vaak is gerenoveerd dat de originele blauwdrukken allang weg zijn, maar de structuur stevig is.

De conclusie

Het artikel concludeert dat hoewel het idee van een "Util"-ruimte goed is (om mensen te voorkomen dat ze het wiel opnieuw uitvinden), deze ruimtes in de praktijk vaak onveilig en onderhouden worden.

  • Ze worden te complex.
  • Ze krijgen te veel beveiligingsgaten.
  • De mensen die ze bouwen en de mensen die ze gebruiken praten vaak niet met elkaar.

Het advies voor bouwers:
Plak niet zomaar een "Util"-label op een bestand en hopen op het beste. Als je een projectmanager bent, moet je:

  1. Documenteren wat "Util" voor jouw team eigenlijk betekent.
  2. Op je hoede zijn voor deze bestanden die te complex worden.
  3. Extra voorzichtig zijn met beveiligingscontroles op deze bestanden, omdat de geschiedenis laat zien dat ze het meest waarschijnlijk breken.

Kortom: Het noemen van een bestand "Util" maakt het geen magische oplossing; soms maakt het er juist een hoog-risicodoel van.

Verdrinkt u in papers in uw vakgebied?

Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.

Probeer Digest →