image

Apache Software Foundation waarschuwt voor gebruik end-of-life software

maandag 17 januari 2022, 12:46 door Redactie, 5 reacties

Gebruikers van Apache-software worden nog altijd aangevallen omdat ze van niet meer ondersteunde software gebruikmaken. Dit is een industriebreed probleem en ondermijnt de inzet van de Apache Software Foundation om kwetsbaarheden snel te verhelpen, zo stelt Mark Cox, vice-president security van de stichting.

De Apache Software Foundation beheert meerdere softwareprojecten, waaronder de Apache-webserver, OpenOffice, SpamAssassin en het inmiddels wereldwijd bekende Log4j. Vorig jaar ontving de stichting 441 meldingen van nieuwe kwetsbaarheden. Een stijging ten opzichte van 2020 en 2019, toen het nog om respectievelijk 376 en 320 meldingen ging. Het gaat hierbij om zowel externe als interne meldingen.

Per 1 januari van dit jaar zijn vijftig van de 441 meldingen nog steeds in onderzoek. Dit wil zeggen dat het betreffende softwareproject de melding nog niet heeft afgewezen of er een CVE-nummer aan heeft toegekend. Dit aantal is hoger dan normaal, aldus Cox en komt door het grote aantal meldingen van eind december. Aan de hand van de resterende 391 meldingen zijn er 183 CVE-nummers voor kwetsbaarheden toegekend. Dat waren erin 2020 nog 151, tegenover 122 in 2019.

Hoewel de Apache Software Foundation de gevonden en gerapporteerde kwetsbaarheden snel verhelpt, blijkt dat gebruikers nog steeds via oude beveiligingslekken in verouderde Apache-software worden aangevallen. "Leveranciers, en dus hun gebruikers, maken nog steeds gebruik van end-of-life versies die bekende niet verholpen kwetsbaarheden bevatten", merkt Cox op. "Dit blijft een groot probleem en we zijn bezig om dit industriebreed probleem aan te pakken."

Reacties (5)
17-01-2022, 14:04 door Anoniem
Ze moeten ook andere licenties maken waarbij open source projecten niet van de een op de andere dag gecancelled kunnen worden en vervangen door een gelicentieerd alternatief
17-01-2022, 17:13 door Anoniem
Door Anoniem: Ze moeten ook andere licenties maken waarbij open source projecten niet van de een op de andere dag gecancelled kunnen worden en vervangen door een gelicentieerd alternatief
Als een Open Source project gecancelled wordt, dan start je toch gewoon je eigen open source fork? Het zou goed zijn als alle grote bedrijven ook wat meer zouden doneren aan die projecten waar ze veel baat bij hebben, dan is de kans dat het gecancelled wordt ook weer wat kleiner. Bijdragen aan de kosten kan ook zijn een code audit uitvoeren en die resultaten te delen.
17-01-2022, 17:22 door Anoniem
Door Anoniem: Ze moeten ook andere licenties maken waarbij open source projecten niet van de een op de andere dag gecancelled kunnen worden en vervangen door een gelicentieerd alternatief
Ik heb geen flauw idee wat je bedoelt. Kan je het uitleggen?
19-01-2022, 07:59 door Anoniem
Kleinere projecten die modulair in elkaar passen had hier wellicht nog wel eens een uitkomst kunnen zijn.

Als log4j had bestaan uit vele losse modules, waar die ldap connecties een plugin waren had die veel minder breed geïnstalleerd gestaan. En die ldap module had dan zelfs op basis van betalingen of push-requests verbeterd kunnen worden.

Terug naar de basis: op je server/desktop alleen dat wat je nodig hebt en weinig meer dan dat.

Kijk je naar bijvoorbeeld Wordpress dan zie je dat, ondanks dat wordpress nogsteeds masaal is, dit model best goed werkt.
19-01-2022, 08:49 door Anoniem
Door Anoniem:
Door Anoniem: Ze moeten ook andere licenties maken waarbij open source projecten niet van de een op de andere dag gecancelled kunnen worden en vervangen door een gelicentieerd alternatief
Ik heb geen flauw idee wat je bedoelt. Kan je het uitleggen?

Apache heeft soms wel eens de neiging om open source producten naar het kerkhof te sturen zonder al te veel aankondiging vooraf. Dit heb ik zelf meegemaakt met hun recommendation engine, die toen ik klaar was met het implementeren opeens niet meer ondersteund / onderhouden werd.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.