Onder veel gebruikte programmeertalen blijkt Java het meest vatbaar voor third-party kwetsbaarheden. Onderzoek van Datadog laat zien dat de adoptie van DevSecOps cruciaal is om de vorming van cybergevaren te vermijden.
Deze conclusie trekt Datadog in het jaarlijkse State of DevSecOps-rapport. Third-party libraries zorgen voor grote problemen bij Java. 90 procent van alle Java-services zijn op deze manier kwetsbaar, dat in schril contrast staat met diensten die op een andere taal draaien: 47 procent.
Een ander criterium om de vatbaarheid voor kwetsbaarheden te meten, is de Known Exploited Vulnerabilities (KEV)-catalogus van het Amerikaanse CISA. Datadog merkt op dat Java-diensten ook hier veel vaker ten prooi vallen aan exploitaties. 55 procent van alle Java-diensten bevatten kwetsbaarheden die actief misbruikt worden, terwijl slechts 7 (!) procent van applicaties gebouwd met andere programmeertalen hetzelfde lot treft.
Lees ook: Sonatype’s SBOM Manager maakt van statische ‘inventarislijsten’ uitvoerbare acties
Maar waarom?
Verder blijkt Java ook voor specifieke gevolgen uiterst kwetsbaar, zoals Remote Code Execution (23 procent van alle Java-diensten). 42 procent van alle organisaties riskeren volgens Datadog daarom een aanval. Het onderzoeksteam weet deze onfortuinlijke cijfers echter te verklaren door een aantal factoren.
Enkele bekende kwetsbaarheden komen namelijk nog zo vaak voor in Java-diensten dat ze een grote impact hebben op de genoemde percentages. Spring4Shell (CVE-2022-22965), Log4Shell (CVE-2021-45046 en CVE-2021-44228) en een RCE in Apache ActiveMQ (CVE-2023-46604) zijn de drie meest gebruikelijke gevaren.
Tip: Log4Shell anno 2023: keiharde impact dreunt nog na
Third-party libraries introduceren veelal dergelijke kwetsbaarheden in Java-diensten. Datadog merkt op dat dit via een keten van dependencies verloopt, waardoor het bijzonder lastig kan zijn een gevaar te herkennen. Een dienst kan namelijk via een andere library indirect afhankelijk zijn van een kwetsbare library. 63 procent van third-party kwetsbaarheden in Java-diensten ontstaan op deze wijze. Het belang van een Software Bill of Materials, die goed bijhoudt welke software je gebruikt en waar die van afhankelijk is (en waar díé libraries weer afhankelijk van zijn).
Oplossingen
Oplossingen voor deze soort problemen zijn er genoeg, meldt Datadog. De adoptie van best practices binnen DevSecOps vereisen Infrastructure-as-Code (IaC), geautomatiseerde cloud-deployments, praktijken voor veilige app-ontwikkeling en het gebruik van credentials in CI/CD pipelines die van korte duur zijn.
Dit zijn overwegend helemaal niet nieuwe ontwikkelingen. Sinds de opkomst van de cloud bestaat IaC als middel om te garanderen dat alle wijzingen in een cloudomgeving extra gecontroleerd worden (zowel handmatig als via scans) en minder vatbaar zijn voor misconfiguraties dan handmatige werkwijzen. Automatisering lost simpelweg veel menselijke fouten op. 38 procent van organisaties die actief zijn op AWS bleven echter nog handmatig cloud-workloads op te zetten.
Ook haalt Datadog aan dat credentials dus van korte duur moeten zijn. Als dat niet zo is, kunnen kwaadwillenden oude credentials bemachtigen en een systeem betreden. Indien zij daarmee een productie-omgeving compromitteren, kunnen ze voor enorme schade zorgen. Dat leed is gewoonweg te voorkomen door af te stappen van credentials met een lange levensduur.
Lees ook: Java 22 beschikbaar: features voor verbeterde performance