Veilige afhankelijkheden
Een groot percentage code dat aanwezig is in moderne toepassingen, bestaat uit de bibliotheken en afhankelijkheden die u, de ontwikkelaar, hebt gekozen. Dit is een gangbare procedure die tijd en geld bespaart. Het nadeel is echter dat u nu verantwoordelijk bent voor deze code, zelfs als anderen deze hebben geschreven, omdat u deze in uw project hebt gebruikt. Als een onderzoeker (of erger, een hacker) een beveiligingsprobleem ontdekt in een van deze bibliotheken van derden, is dezelfde fout waarschijnlijk ook aanwezig in uw app.
Het gebruik van onderdelen met bekende beveiligingsproblemen is een groot probleem in onze bedrijfstak. Het is zo problematisch dat het de OWASP top 10-lijst met slechtste beveiligingsproblemen van webtoepassingen heeft gemaakt, die enkele jaren op #9 wordt bewaard.
Bekende beveiligingsproblemen in de gaten houden
Het probleem is dat we moeten weten wanneer een probleem wordt gedetecteerd. Het up-to-date houden van onze bibliotheken en afhankelijkheden (nummer 4 in onze lijst!) helpt natuurlijk, maar het is verstandig om geïdentificeerde problemen in de gaten te houden die mogelijk van invloed zijn op uw toepassing.
Belangrijk
Wanneer een systeem een bekend beveiligingsprobleem heeft, is het veel waarschijnlijker dat er aanvallen beschikbaar zijn, code die mensen kunnen gebruiken om deze systemen aan te vallen. Als een exploit openbaar wordt gemaakt, is het van cruciaal belang dat alle betrokken systemen onmiddellijk worden bijgewerkt.
Mitre is een non-profitorganisatie die de Common Vulnerabilities and Exposures-lijst onderhoudt. Deze lijst is een openbaar te doorzoeken set van bekende cyber-beveiligingsproblemen in apps, bibliotheken en frameworks. Als u een bibliotheek of specifiek onderdeel in de database CVE vindt, heeft dit bekende beveiligingslekken.
De beveiligingscommunity verzendt problemen wanneer er een beveiligingsfout wordt gevonden in een product of onderdeel. Elk gepubliceerd probleem krijgt een ID en bevat de datum wanneer het werd ontdekt, een beschrijving van het probleem en verwijzingen naar gepubliceerde tijdelijke oplossingen of instructies van de leverancier over het probleem.
Hoe controleert u of u bekende beveiligingslekken in uw onderdelen van derden heeft
U kunt een dagelijkse taak in uw telefoon invoeren om deze lijst te controleren, maar gelukkig voor ons bestaan er veel hulpprogramma's waarmee we kunnen controleren of de afhankelijkheden kwetsbaar zijn. U kunt deze hulpprogramma's uitvoeren op de basis van uw code, of nog beter, toevoegen aan uw CI/CD-pijplijn om automatisch op problemen te controleren als onderdeel van het ontwikkelingsproces.
- OWASP Dependency Check, heeft een Jenkins-invoegtoepassing
- Snyk, dit is gratis voor open-source-opslagplaatsen in GitHub
- Black Duck, wordt gebruikt door veel ondernemingen
- Retire.js, een hulpprogramma voor het controleren of uw JavaScript-bibliotheken verouderd zijn; kan worden gebruikt als invoegtoepassing voor verschillende hulpprogramma's, waaronder Burp Suite
U kunt hiervoor ook enkele hulpprogramma's gebruiken die specifiek zijn gemaakt voor statische codeanalyse.
- Scan van beveiligingscode
- Puma Scan
- PT Application Inspector
- Apache Maven Dependency Plugin
- Sonatype
- En nog veel meer...
Zie voor meer informatie over de risico's van het gebruik van kwetsbare onderdelen de OWASP-pagina die is toegewezen aan dit onderwerp.
Samenvatting
Wanneer u bibliotheken of andere onderdelen van derden gebruikt als onderdeel van uw toepassing, neemt u ook eventuele risico's op. De beste manier om dit risico te beperken is ervoor zorgen dat u alleen gebruikmaakt van onderdelen waaraan geen bekende beveiligingsproblemen zijn verbonden.