CVE (Algemene kwetsbaarheden en blootstellingen)-scans zijn essentieel voor het beveiligen van uw softwareapplicaties. Met de toenemende complexiteit van softwarestacks kan het echter een uitdaging zijn om alle CVE’s te identificeren en aan te pakken. Een van de grootste problemen met CVE-scans vandaag de dag is het voorkomen van valse positieven, waarbij een kwetsbaarheid wordt geïdentificeerd in een pakket dat niet in gebruik is in de productieapplicatie.
Het is belangrijk om te onthouden dat zelfs als u eenmaal een volledige lijst van al uw softwarepakketten en een volledige lijst van alle CVE's in die pakketten heeft, het vrij zeker is dat ze niet allemaal relevant zijn voor uw toepassing. De CVE bevindt zich mogelijk in een functie die niet in uw code wordt gebruikt, of in een deel van de bibliotheek dat u niet eens aanroept. Het kan een tijdelijke afhankelijkheid zijn die alleen wordt aangeroepen vanwege een niet-gepatchte afhankelijkheidslijst en die helemaal niet in uw code wordt gebruikt. Zelfs als u weet dat een CVE zich in een deel van een bibliotheek bevindt die u gebruikt, is dit nog geen garantie dat de CVE ook daadwerkelijk in uw toepassing kan worden geëxploiteerd. Sommige exploits vereisen extreme omstandigheden voordat ze door hackers kunnen worden gebruikt, waaronder de combinatie van drie of meer CVE's achter elkaar, de juiste stapel en de juiste infrastructuur. Omdat u elke CVE die u uit uw scan krijgt nog steeds nader moet bekijken, kunt u zien hoe belangrijk het is om het aantal CVE's dat u krijgt te beperken, zodat u geen alerte vermoeidheid of CVE-burn-out krijgt voordat u weer terug kunt komen. om daadwerkelijk de volgende functies van uw applicatie te bouwen.
In dit artikel bied ik enkele mogelijke oplossingen aan om valse positieven in CVE-scans te verminderen, met als doel het totale aantal CVE's waarmee u te maken krijgt, te verminderen. Ik zal beginnen met het bespreken van de uitdagingen bij het identificeren van pakketten, en ga dan verder met het introduceren van een database die pakketbestanden aan pakketnamen koppelt. Ik bespreek ook problemen met scoping en codepaden die valse positieven kunnen veroorzaken.
Laten we beginnen met te kijken hoe CVE’s überhaupt worden geïdentificeerd.
Het mysteriepakket en de ontbrekende CVE
De Mitre Corporation is een Amerikaanse non-profitorganisatie die verantwoordelijk is voor de CVE®-programma. Het programma missie is het identificeren, definiëren en catalogiseren van openbaar gemaakte kwetsbaarheden op het gebied van cyberbeveiliging. De manier waarop dit werkt is dat zodra u een kwetsbaarheid vindt, u een formulier invult en, als de vondst kan worden bevestigd, een nieuwe CVE-identificatie aan de kwetsbaarheid wordt gegeven en wordt toegevoegd aan de openbare CVE-database.
Gezien de manier waarop CVE's worden vermeld, is een van de belangrijkste uitdagingen bij CVE-scans het correct identificeren van pakketten en bibliotheken. Wanneer iemand een kwetsbaarheid in een pakket of bibliotheek identificeert, vermeldt hij deze met de pakketnaam en de versie waarmee hij vertrouwd is. Natuurlijk gebruiken niet alle tools dezelfde naamgevingsconventies, en pakketnamen kennen geen bestaande mondiale standaard. Het 'Naming Problem', zoals het bekend is geworden, is zo ernstig dat meerdere fora en denkgroepen al lange tijd proberen een gemeenschappelijke oplossing te vinden. Als voorbeeld: hier De door OWASP voorgestelde oplossing voor het probleem in relatie tot het ontstaan van SBOM's. Vaak vertrouwen scanhulpmiddelen op de bronnen die ze ontvangen, zoals gebouwde of gecompileerde artefacten, voor de pakketnamen die ze in het scanresultaat leveren, en deze bronnen zijn niet altijd betrouwbaar. Verpakkingen en aanpassingen kunnen het bijvoorbeeld moeilijk maken om het daadwerkelijke pakket te identificeren. Bovendien laten sommige pakketbestanden mogelijk geen spoor achter van hun installatiepakket, zoals Docker COPY-opdrachten.
Om deze problemen aan te pakken, hebben wij, bij Scribe Beveiliging, raadt u aan een database voor uw toepassing te maken die pakketbestanden aan pakketnamen toewijst. Zelfs als de pakketnaam anders is, als het hetzelfde pakket is, zouden de bestanden en de bestandshashes identiek zijn. Door dit te doen, kunt u problemen met wrappers en aanpassingen overslaan en het feitelijke pakket identificeren dat moet worden aangepakt. Deze aanpak kan tijd en moeite besparen in het CVE-saneringsproces. Sinds de Schrijversplatform al de bestanden identificeert die zijn gekoppeld aan elk pakket in uw uiteindelijke image, is het creëren van een dergelijke database de volgende logische stap. Het is onze bedoeling dat onze CVE-scan niet hoeft te vertrouwen op de naam en versie die door de CVE wordt vermeld, maar op de daadwerkelijke bestanden die het pakket bevat.
Ben jij mijn moeder?
Als je te maken hebt met een definitieve build die een Docker-image is, is het tegenwoordig gebruikelijk om niet helemaal opnieuw te beginnen. Door een solide startpunt te hebben, zoals een gevestigde basisimage, kunnen ontwikkelaars zich concentreren op het deel van de build dat hun applicatie is, in plaats van te beginnen met het plannen van de omgeving waarop deze moet draaien. Een van de uitdagingen bij het gebruik van Docker-images is het begrijpen van hun herkomst en afhankelijkheden, vooral als het gaat om de bovenliggende image (afgezien van de basisimage) waar de uiteindelijke image bovenop is gebouwd.
De bovenliggende afbeelding is een concept dat we hebben bedacht om het dichtstbijzijnde 'levende familielid' van een Docker-afbeelding te verklaren. Afbeeldingen zijn in verschillende lagen opgebouwd, dus laten we zeggen dat ik een bekende basisafbeelding gebruik, zoals Alpine, Debian of Ubuntu, en mijn applicatielaag daar bovenop bouw. In dit geval zou mijn dichtstbijzijnde 'ouder' dat basisbeeld zijn. Maar wat als het bedrijf waarvoor ik werk een ander uitgangspunt heeft, één met een basisimage en nog een paar lagen bovenop die van beveiligingstools die verplicht zijn voor alle bedrijfsimages? In dit geval zou mijn bovenliggende afbeelding deze bedrijfssjabloon zijn en zou ik ook de basisafbeelding kunnen identificeren waarop deze sjabloon is gebouwd.
De Parent Image is een cruciaal onderdeel van uw softwaretoeleveringsketen, omdat het de basis vormt voor de applicatie en de afhankelijkheden ervan. Van nature bevatten Docker-images niet veel informatie over de oorsprong van de bovenliggende of basisimages, waardoor het moeilijk wordt om de integriteit ervan te verifiëren, de kwetsbaarheden ervan te begrijpen en de licentie ervan te verifiëren.
Om dit probleem aan te pakken, heeft Scribe een open-source tool en service ontwikkeld genaamd OuderAfbeelding om de dichtstbijzijnde gescande ouder van een Docker-afbeelding te detecteren. Deze tool kan worden gebruikt om de bovenliggende afbeelding van een Docker-afbeelding te identificeren, wat een belangrijke factor is bij het verminderen van risico's:
Ten eerste kan men, door het basisimage te identificeren, de integriteit ervan verifiëren en ervoor zorgen dat er niet mee is geknoeid of gecompromitteerd. Dit is belangrijk voor het behoud van de veiligheid en stabiliteit van de applicatie.
Ten tweede kan men, door te begrijpen welke kwetsbaarheden afkomstig zijn van de bovenliggende afbeelding en welke afkomstig zijn van de applicatielaag zelf, kwetsbaarheden effectiever prioriteren en beheren. Dit betekent dat CVE's die zijn gekoppeld aan uw basisimage of uw bovenliggende image minder urgent zijn (en niet altijd uw verantwoordelijkheid om te herstellen) in vergelijking met CVE's in de applicatielaag.
Bovendien kan men, door de bovenliggende afbeelding te identificeren, de licentie ervan verifiëren en ervoor zorgen dat de wettelijke en interne beleidsvereisten worden nageleefd.
De open-sourcetool ParentImage bevat een database met Docker-afbeeldingscans die kan worden bijgewerkt. Je kunt het splitsen en volledig intern gebruiken, maar we hopen dat mensen hun Docker-afbeeldingen scannen en ons die informatie sturen om in de database te worden opgenomen. Hoe meer beeldscans de database bevat, hoe meer 'Ouders' de tool zou kunnen identificeren. Momenteel bevat de meegeleverde database een volledige lijst van alle gevestigde basisafbeeldingen als proof of concept. Omdat het een open-source tool is, kost het niets om het eens te proberen, dus als je Docker-images gebruikt, moedig ik je aan om deze tool te beschouwen als een mogelijke oplossing voor één van de redenen voor niet-gerelateerde CVE's.
Moet ik scannen of moet ik overslaan?
Een andere uitdaging bij CVE-scans is het in kaart brengen van problemen. Scoping verwijst naar de locatie van gescande bestanden en pakketten – wat in de scan moet worden opgenomen en wat veilig kan worden genegeerd. Soms wordt een CVE aangetroffen in een pakket dat niet daadwerkelijk in gebruik is in de productieversie van de applicatie. Een pakket kan bijvoorbeeld worden geïnstalleerd als gevolg van een indirecte afhankelijkheid van een testframework. Om dit aan te pakken moeten scanners de reikwijdte van de applicatiebestanden beoordelen en de indirecte afhankelijkheden in gebruik identificeren.
OWASP-plug-ins (The Open Worldwide Application Security Project) bevatten enkele goede voorbeelden van tools die kunnen helpen bij het oplossen van problemen. OWASP-afhankelijkheidscontrolekan bijvoorbeeld de afhankelijkheden van een applicatie analyseren en CVE's identificeren in de context van de afhankelijkheidsgrafiek van de applicatie. Door dit te doen, kan het identificeren welke CVE's in gebruik zijn in de productietoepassing en welke niet.
Wat het aantal ook is, u moet nog steeds uw CVE’s aanpakken
Bij gebrek aan een ander hulpmiddel dat u kan vertellen waar uw applicatie kwetsbaar is voor mogelijke hacks, backdoors en andere soortgelijke problemen, is een CVE-scan nog steeds een vrij eenvoudige optie om potentiële problemen aan te pakken. Het probleem is dat totdat u verifieert of een CVE die u in de scan wordt gepresenteerd een reëel probleem is, deze een bedreiging vormt die tegen u kan worden gebruikt door toezichthouders, derden en gebruikers.
In naam van de veiligheid en transparantie moet u elk potentieel probleem doornemen en bewijzen dat het óf geen probleem is, niet relevant voor uw toepassing, óf dat het een potentieel probleem is en dat u eraan werkt om het op te lossen. Het feit dat veel van deze CVE's uw applicatie binnenkomen vanuit externe, meestal open-sourcepakketten, betekent dat zelfs als u het identificeert als een potentiële exploit, u waarschijnlijk nog steeds de hulp van de pakketbeheerders nodig heeft om het te patchen.
Met al het werk dat met elke CVE gepaard gaat, is het geen wonder dat u bij uw volgende CVE-scan de voorkeur geeft aan een zo klein mogelijk aantal. Als u enkele van de suggesties in dit artikel gebruikt, kunt u de monumentale taak van het aanpakken van uw kwetsbaarheden iets beter beheersbaar maken.
Als u andere open-source of gratis tools heeft om het probleem op te lossen, horen we dat graag. Vertel ons erover in de reacties en deel met de community hoe jij omgaat met jouw berg aan kwetsbaarheden.
Deze inhoud wordt u aangeboden door Scribe Security, een toonaangevende aanbieder van end-to-end software supply chain-beveiligingsoplossingen die state-of-the-art beveiliging levert voor codeartefacten en codeontwikkelings- en leveringsprocessen in de software supply chain. Meer informatie.
Gerelateerde berichten
