![\"Kis](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>De optimale oplossing zou zijn om alleen de meest kritieke patches en kwetsbaarheden over te dragen, maar de kern van het probleem ligt in het identificeren van dergelijke fouten uit de algemene toestroom. Het grootste aantal opduikende problemen is het gevolg van het gebruik van de programmeertaal C, die grote nauwkeurigheid vereist bij het werken met geheugen en pointers. De situatie wordt verergerd doordat veel potenti\u00eble patches voor kwetsbaarheden geen CVE-identificaties krijgen, of dat een dergelijke identificatie enige tijd na de publicatie van de patch wordt toegekend. In dergelijke omstandigheden is het voor fabrikanten zeer moeilijk om secundaire patches van belangrijke veiligheidstekens te scheiden. Statistisch gezien wordt meer dan 40% van de kwetsbaarheden opgelost voordat ze een CVE-nummer krijgen, en de gemiddelde vertraging tussen de uitgave van een patch en de toewijzing van een CVE bedraagt drie maanden (dit betekent dat de patch aanvankelijk als een gewone bug wordt gezien, maar pas maanden later duidelijk wordt dat het om het oplossen van een kwetsbaarheid ging).<\/p>\nUiteindelijk, zonder een aparte \u0432\u0435\u0442\u043a\u0430 met patches voor kwetsbaarheden en zonder informatie over de relatie met de beveiliging van een bepaald probleem, blijven fabrikanten van producten die zijn gebaseerd op de Linux-kernel voortdurend alle patches vanuit nieuwe stabiele branches overdragen. Maar dit werk vereist veel mankracht en stuit binnen bedrijven op weerstand vanwege de vrees voor regressieve veranderingen die de normale werking van het product kunnen verstoren.<\/p>\n
Laten we niet vergeten dat, volgens Linus Torvalds, alle fouten belangrijk zijn en kwetsbaarheden niet van andere soorten fouten moeten worden gescheiden en in een aparte, hogere prioriteitscategorie moeten worden geplaatst. Deze mening wordt verklaard doordat voor een gewone ontwikkelaar, die niet gespecialiseerd is in beveiligingskwesties, de relatie tussen de patch en een potenti\u00eble kwetsbaarheid niet duidelijk is (voor veel patches maakt alleen een aparte audit duidelijk dat ze betrekking hebben op veiligheid). Volgens Linus moeten beveiligingsexperts van de teams die verantwoordelijk zijn voor de ondersteuning van pakketbeheer met de kernel in Linux-distributies zich bezighouden met het identificeren van kwetsbaarheden binnen de algemene toestroom van patches.<\/p>\n
Kees Cook is van mening dat de enige oplossing voor het waarborgen van de beveiliging van de kernel tegen redelijke lange termijn kosten is dat bedrijven engineers, die verantwoordelijk zijn voor het porteren van patches naar lokale kernel-builds, herori\u00ebnteren naar een gezamenlijke geco\u00f6rdineerde aanpak voor het onderhouden van patches en kwetsbaarheden in de upstream kernel. Momenteel gebruiken veel fabrikanten oudere versies van de kernel in hun producten en backporten ze patchen zelf, wat betekent dat engineers in verschillende bedrijven elkaars werk dupliceren door hetzelfde probleem op te lossen.<\/p>\n
Bijvoorbeeld, als 10 bedrijven, elk met \u00e9\u00e9n engineer die dezelfde patches backport, deze engineers herori\u00ebnteren naar het oplossen van bugs in de upstream, zouden ze in plaats van \u00e9\u00e9n patch te porteren 10 verschillende bugs voor een gemeenschappelijk belang kunnen oplossen of zich kunnen aansluiten bij de review van voorgestelde veranderingen om te voorkomen dat buggy code in de kernel wordt opgenomen. Ook zouden de middelen kunnen worden ingezet voor het ontwikkelen van nieuwe test- en code-analysehulpmiddelen die in een vroeg stadium automatisch typische klassen bugs kunnen identificeren die steeds weer opduiken.<\/p>\n
Kees Cook stelt ook voor om geautomatiseerd en fuzzing-testing actiever in het ontwikkelingsproces van de kernel te gebruiken, systemen voor continue integratie toe te passen en af te stappen van de verouderde e-mailverdeling in de ontwikkeling. Momenteel wordt effectief testen bemoeilijkt doordat de belangrijkste testprocessen gescheiden zijn van de ontwikkeling en plaatsvinden na de release. Kees raadde ook aan om programmeertalen te gebruiken die meer veiligheid bieden tijdens de ontwikkeling, een hoog niveau van beveiliging<\/a>, zoals Rust.<\/p>\n