Softwareontwikkeling is een praktijk waar steeds meer mensen over de hele wereld mee bezig zijn. Er zijn zowel bedrijven als individuen die software bouwen, waarvan een deel propriëtair is, een deel gratis of open source, en sommige een samensmelting van beide zijn. Omdat bedreigingen voor de veiligheid van gebruikers of hun software niet uit de lucht komen vallen zodra iets compleet is verklaard en naar productie is verzonden, lijkt dit het juiste moment om te praten over beveiligingspraktijken die kunnen helpen de beveiligingsrisico's te beheersen die in het systeem zouden kunnen binnensluipen. uw software tijdens het ontwikkelingsproces. Er zijn verschillende SSDLC-frameworks (Secure Software Development Life Cycle), waaronder die van OWASP, CISA en NIST (SSDF). In dit artikel lenen we iets van al deze voorbeelden om enkele praktijken uit te lichten die erop gericht zijn u te helpen de risico's te beheersen die inherent zijn aan softwareontwikkeling. Leef niet met een gevoel van valse veiligheid, denkend dat het jou niet kan overkomen. Het halverwege het jaar uitgevoerde cyberbeveiligingsrapport van Check Point 2023 onthult een piek van 8% in wereldwijde cyberaanvallen in 2022, en de trend lijkt niet te keren.
Wat is de levenscyclus van softwareontwikkeling
Softwareontwikkelaars streven ernaar om software snel, nauwkeurig en veilig te bouwen. Natuurlijk kun je niet altijd alle drie krijgen. In de loop van de tijd werd het ontwikkelingsproces opgedeeld in verschillende fasen die bij elke softwareontwikkeling passen. Deze fasen kunnen worden opgesplitst als:
- Vereiste analyse – wat gaan we bouwen en waarom
- Planning – hoe we het in algemene termen gaan bouwen
- Software-ontwerp – hoe we het gaan bouwen in specifieke termen, zoals architectonisch ontwerp
- Software ontwikkeling – het schrijven en compileren van de software
- Testen – zorg ervoor dat het werkt zoals gepland
- Deployment – het verzenden of publiceren zodat de eindgebruiker het kan gebruiken
Er zijn een paar andere versies van deze cyclus, maar over het algemeen lijken ze erg op elkaar. Het is belangrijk om te onthouden dat de cyclus niet iets eenmaligs is: deze eindigt meestal niet zodra u deze naar de klant heeft verzonden of naar de cloud heeft gepubliceerd. Er zijn bijna altijd problemen waarmee u te maken krijgt en die mogelijk een nieuw ontwerp vereisen (terug naar af), bugs die u moet oplossen, functies die u wilt toevoegen, enzovoort. Je kunt ook merken dat je aan een paar fasen parallel werkt of halverwege stopt om terug te dubbelen. Omdat geen van de stappen inherent op veiligheid gericht is, is het aan de beveiliging om voortdurend een inhaalslag te maken op het ontwikkelingsproces. In de huidige hectische ontwikkelingssnelheden is dit niet genoeg.
Het belang van het beveiligen van uw SDLC
Bij de ontwikkeling van veilige software wordt ernaar gestreefd beveiligingsoverwegingen in alle fasen van het proces op te nemen, en beveiliging niet als een aanvulling op het proces te beschouwen. Op deze manier moet beveiliging altijd een overweging zijn, ongeacht in welke fase van het proces u zich bevindt: nadenken over de projectvereisten, het plannen van de architectuur, het overwegen van de benodigde bouwstenen en infrastructuur, en gaan zitten om de code te ontwikkelen. Deze aanpak wordt ook wel de shift-links beveiliging nadering.
Shift-left verwijst hier naar het verdelen van beveiligingsproblemen gedurende het ontwikkelingsproces en het betrekken van de ontwikkelaars bij het ontwerpen, implementeren en testen van beveiliging.
Het kan intimiderend zijn voor ontwikkelaars die nog nooit echt over beveiligingsproblemen hebben nagedacht als ze er plotseling mee te maken krijgen. Het is aanzienlijk eenvoudiger te hanteren als de vereisten zijn onderverdeeld in meerdere, goed gedefinieerde best practices. Je kunt het zien als het ophalen van een nieuwe IDE.
Hoe beter de vereisten zijn gedefinieerd en hoe meer automatisering en uitgebreide tools u kunt gebruiken, hoe eenvoudiger de taken zullen worden.
Best practices voor SDLC-beveiliging
Hier volgen enkele best practices om u te helpen uw ontwikkelingsproces te beveiligen, in willekeurige volgorde:
Workshops – Veel ontwikkelaars zouden zich niet opgewassen voelen tegen de taak om beveiligingsoverwegingen toe te passen en te testen op de code die ze schrijven. De meerderheid van de ontwikkelaars is zich ervan bewust dat het binnenlaten van besmette invoergegevens in uw backend kan resulteren in activering van code op afstand, net zoals de bekende ‘drop-tabellen’. Minder mensen zouden echter bekend zijn met het testen van bufferoverflows of het scannen van kwetsbaarheden voor tertiaire (of verdere) afhankelijkheden. Ontwikkelaars kunnen deze kennislacunes dichten met behulp van training. Ontwikkelaars zijn beter toegerust om beveiligingsproblemen op te nemen in hun dagelijkse codering en testen als ze een beter inzicht hebben in beveiligingsuitdagingen en potentiële kwetsbaarheden. Het is ook veel logischer voor de ontwikkelaar die de code heeft geschreven en goed bekend is met de functie ervan, om de beveiligingslekken in overweging te nemen en het testen dienovereenkomstig te plannen.
Het scannen – U kunt vele soorten scannen gebruiken om uw code in het algemeen veiliger te maken. Statische, dynamische en interactieve analyse zijn er enkele van. Bij statische analyse wordt gezocht naar duidelijke coderingsfouten of mogelijke beveiligingsproblemen in de broncode. Het kan worden gebruikt om potentiële kwetsbaarheden, onveilige codepraktijken en schendingen van codeerstandaarden op te sporen. Er wordt geen rekening gehouden met runtime-gebeurtenissen, omdat alleen de syntaxis van de code wordt onderzocht. Dynamische analyse zoekt naar eventuele beveiligingsfouten, coderingsfouten en andere problemen in de applicatie terwijl deze actief is. Het kan worden gebruikt om geheugenlekken, ondermaatse bewerkingen en mogelijk onstabiele invoer of processen te identificeren. Houd er rekening mee dat, aangezien dit soort tests op een bepaald tijdstip wordt uitgevoerd met behulp van specifieke input, de kwaliteit van de tests volledig afhangt van de personen die ze hebben bedacht. Het doel is om de problemen op te sporen voordat uw gebruikers dat doen. Interactieve analyse onderzoekt de applicatie om eventuele beveiligingsfouten en andere problemen te vinden. Het kan zoeken naar mogelijke kwetsbaarheden, bruikbaarheidsproblemen en problemen met de gebruikersinterface. Hoe uitgebreider de scantools die u gebruikt, hoe beter u beschermd bent, maar de wisselwerking zit hem uiteraard in de ontwikkelingssnelheid. Omdat elke applicatie uniek is, is het aan jou om de balans te vinden tussen de juiste hoeveelheid scannen en de gewenste ontwikkelingssnelheid. Daarnaast raden we u aan een volledige SBOM van uw applicatie te maken en ook verschillende scans en rapporten op die gegevensbron toe te passen. Het hebben van een SBOM-erfenis van uw app is een goede manier om zeer gedetailleerde component- en pakketinformatie bij te houden die om tal van veiligheidsredenen van onschatbare waarde kan zijn.
Code beoordelingen – Het onderzoeken van de broncode om eventuele beveiligingsfouten, codeerfouten en andere softwarefouten op te sporen voordat deze wordt gecombineerd met de actieve ontwikkelingstak, staat bekend als codebeoordeling. Meestal wordt deze beoordeling uitgevoerd door een ontwikkelaar met meer expertise dan degene die de code heeft geschreven. Dergelijke beoordelingen kunnen helpen garanderen dat de code goed geschreven is en dat de applicatie veilig is. Bovendien ondersteunen ze het onderhoud van één enkele standaard en coderingsconventies (zoals functie- en variabelenamen) in de hele codebasis.
Het toestaan van de integratie van code in de hoofdvertakking nadat ten minste twee paar ogen deze hebben beoordeeld, wordt als een best practice beschouwd. De ontwikkelaar die de code heeft geschreven, is uiteraard het eerste paar ogen. Zelfs voor zeer bekwame ingenieurs, zoals teamleiders, kan het nuttig zijn om iemand anders hun code te laten beoordelen. Dit zorgt er op zijn minst voor dat meer dan één persoon bekend is met elke sectie van de code. Houd er rekening mee dat mensen in tijden van grote stress of in tijden van krapte kunnen overwegen dit element achterwege te laten. Overweeg indien mogelijk om deze regel toe te voegen als een hardgecodeerd element van uw CI/CD, zodat deze niet kan worden omzeild.
Testen – We hoeven u niet te vertellen hoe belangrijk het is om uw code te testen om beveiligingsfouten te ontdekken voordat deze een probleem worden. Het merendeel van de codeprojecten is ingewikkeld en onderling verbonden. Daarom is het onmogelijk te voorzien hoe een enkel klein hiaat uiteindelijk de veiligheid van de gehele codebasis kan beïnvloeden.
Houd bij het schrijven van geautomatiseerde tests rekening met de functionaliteit van de recent geproduceerde code, evenals met eventuele significante back-end- en front-end-interacties met andere delen van de codebasis.
Kwetsbaarheden zoals SQL-injectie, cross-site scripting, onveilige gegevensopslag en onvoldoende geheugentoewijzing (wat kan resulteren in bufferoverflows) zijn voorbeelden van beveiligingsproblemen die doorgaans tijdens het testen worden aangepakt. Testen moeten geheugenlekken, trage of onbetrouwbare prestaties en bruikbaarheid aanpakken. Het testen moet automatisch gebeuren en worden geïntegreerd in de CI/CD-pijplijn, zodat er geen nieuwe versie of update kan worden gepubliceerd zonder zowel unit- als integratietests te ondergaan.
Onafhankelijke pentesten – Niemand kan alles bedenken en als ontwikkelaars ontwikkelen we soms blinde vlekken met betrekking tot de code die we hebben geschreven. Net als bij codebeoordeling zorgen onafhankelijke pentests voor een frisse aanpak en een ander stel ogen om kritisch te onderzoeken wat we hebben gedaan en welke voorzorgsmaatregelen we hebben genomen om onze app en onze gebruikers te beveiligen. Dergelijke tests worden minstens één keer per jaar aanbevolen en moeten zowel infrastructuurevaluatie als app-kwetsbaarheden omvatten.
Maak veilig gebruik van open source – Bijna alle software die momenteel in ontwikkeling is, bevat in meer of mindere mate open source-software. Open-sourcecomponenten zijn enkele van de belangrijkste oorzaken van geïmporteerde kwetsbaarheden in uw applicatie, hetzij rechtstreeks, hetzij via tijdelijke afhankelijkheden. Bovendien zijn het niet alleen de bibliotheken die u gebruikt die u in gevaar kunnen brengen, maar ook het niet bijwerken van oude bibliotheken of het niet op de hoogte blijven van de laatst gepubliceerde CVE's kan gevolgen voor u hebben. We raden u aan een lijst met goedgekeurde open-sourcepakketten op te stellen voor gebruik door de organisatie en deze voortdurend te controleren en bij te werken. Door te voorkomen dat de ontwikkelaars elk gewenst pakket toevoegen, ook al is het maar als test, kan het aantal kwetsbaarheden waarmee u te maken krijgt, worden teruggedrongen.
Zorg ervoor dat kwetsbaarheden niet uitmonden in exploits – Er is bijna geen codebasis zonder kwetsbaarheden. Elke fatsoenlijke scan zou ergens tussen de honderden en duizenden opduiken. Het is onmogelijk om ze allemaal te elimineren. Het is ook belangrijk om te onthouden dat kwetsbaarheden geen exploits zijn. Zorg ervoor dat u over een filterproces beschikt om er zeker van te zijn dat eventuele kwetsbaarheden die u ontdekt geen exploiteerbare bedreiging zijn, en houd deze lijst voortdurend bijgewerkt. Op deze manier kunt u eventuele derde partijen of gebruikers die zich zorgen maken over de nieuwste CVE geruststellen dat deze absoluut geen impact heeft op uw applicatie.
Beveiliging begint bij uw mentaliteit
Er zijn waarschijnlijk net zoveel verschillende manieren om software te ontwikkelen als er ontwikkelaars, raamwerken en codeertalen zijn. Dat wil zeggen dat het niet eenvoudig is om best practices te vinden voor het beveiligen van uw ontwikkelingsproces die relevant zijn, ongeacht de taal, het vakgebied of de IDE die u gebruikt. Naast een overvloed aan tools, sommige eigen en sommige gratis, die allemaal om uw aandacht schreeuwen als 'het volgende onvervangbare beveiligingshulpmiddel', is uw mentaliteit het belangrijkste beveiligingshulpmiddel dat u kunt gebruiken.
Denk na over uw ontwerpkeuzes, architectuur en opslag. Heeft u de optie van exponentiële groei van uw gebruikersbestand overwogen? Heeft u de toegangsrechten voor verschillende delen van uw codebase en infrastructuur correct gesegmenteerd? Heeft u zowel een gerichte aanval op uw gegevens of geheimen als een 'indirecte' aanval op de software supply chain overwogen?
Al deze vragen en meer moeten worden overwogen voordat u zelfs maar gaat zitten om uw toepassing te plannen, en ze moeten routinematig opnieuw worden geïnspecteerd naarmate de codebase en de app groeien en evolueren.
Het wordt als een axioma beschouwd dat het meest kwetsbare deel van elke software de mens is die deze beheert (of schrijft). Laat uw applicatie, software of codebibliotheek geen deel uitmaken van de toenemende statistieken van een nieuwe golf van cyberaanvallen. Met de juiste planning, tools en automatisering kunt u de juiste balans vinden tussen het beheersen van cyberrisico's, het beveiligen van uw ontwikkelingslevenscyclus en het produceren van goed gedocumenteerde, uitgebreide, efficiënte code.