Op 22 maart heeft NIST de definitieve versie van SSDF 1.1 (Secure Software Development Framework) uitgebracht.
Het raamwerk werd in september 2021 in eerste instantie gepubliceerd als conceptversie. Alle praktijken en taken op hoog niveau blijven hetzelfde, waarbij veel verschillen gecentreerd zijn rond de verschillende gegeven voorbeelden.
Wat is het NIST SP 800-218-framework? De SSDF consolideert al lang bestaande best-practice-aanbevelingen voor veilige softwareontwikkeling. De aanpasbare, sectoronafhankelijke aanpak is ontwikkeld om de communicatie tussen afdelingen (en producenten/acquirers) te vergemakkelijken om strategische doelen te helpen definiëren en de huidige hiaten in kaart te brengen.
NIST beveelt aan om risico af te wegen tegen kosten, haalbaarheid en toepasbaarheid bij het beslissen welke praktijken moeten worden geïmplementeerd. Automatisering is een belangrijk kenmerk waarmee rekening moet worden gehouden met het gewenste doel om zoveel mogelijk controles en processen ter bevordering van de softwarebeveiliging te automatiseren.
Verschillen tussen de definitieve en conceptversie:
Integriteitsverificatie – Bij het bespreken van kwetsbaarheden wordt meer aandacht besteed aan integriteitsverificatie wanneer u zowel naar uw code kijkt als naar bibliotheken/producten die u van externe bronnen hebt verkregen.
Onveranderlijke attesten - De verantwoordelijkheid voor het implementeren van de praktijken kan over verschillende organisaties worden verdeeld, vooral als we rekening houden met de complexiteit van softwaretoeleveringsketens. Het zicht neemt aanzienlijk af naarmate u verder stroomopwaarts of stroomafwaarts in de keten gaat. Daarom beveelt NIST aan om de gedeelde verantwoordelijkheid, waarbij zowel de aanbieders als de consumenten van een platform/dienst betrokken zijn, in een contract of overeenkomst vast te leggen. Het moet duidelijk zijn welke partij verantwoordelijk is voor elke praktijk en taak en hoe elke aanbieder zal getuigen dat hij zich aan de overeenkomst houdt. Het ‘vertrouwen maar verifiëren’-axioma geldt hier – onveranderlijke attestaties die gemakkelijk kunnen worden gedeeld tussen softwareproducenten en softwareverwervers, zijn van cruciaal belang om het vertrouwen van alle belanghebbenden in de softwaretoeleveringsketen te vergroten.
Open-source betrokkenheid van de gemeenschap – NIST stelt dat toekomstig werk waarschijnlijk de vorm zal aannemen van specifieke gebruiksscenario's en dat het van plan is hiermee samen te werken de open-sourcegemeenschap. Gezien het feit dat de meeste commerciële codeproducten die tegenwoordig worden gebruikt aanzienlijke open-sourcecode-elementen bevatten, is het normaal om de open-sourcegemeenschap te betrekken bij het plannen en implementeren van de beveiliging van de softwarelevenscyclus.
Ernstscores van kwetsbaarheden als KRI (Key Risk Indicator) – Een andere verandering die van kracht wordt, zijn de ernstscores als sleutelindicator. Wetende dat veel cyberbeveiligingspersoneel last heeft van alertheidsmoeheid, is het voor elke organisatie zinvol om de kwetsbaarheidsscoreschaal te definiëren die daarvoor geschikt is, en de specifieke behandeling die elke dergelijke score verdient.
Minder menselijke toegang, meer automatisering – NIST moedigt het minimaliseren van directe menselijke toegang tot toolchain-systemen, zoals bouwdiensten, aan. Hoe meer mensen toegang hebben, hoe meer fouten er kunnen gebeuren. Dit valt wederom in dezelfde lijn als de aanbeveling voor meer automatisering.
SBOM’s met integriteit – Bij het bespreken van de SBOM (Software Bill of Materials) beveelt NIST aan om sterke bescherming te bieden aan de integriteit van het artefact, en om ontvangers een manier te bieden om die integriteit te verifiëren. De ontvangers kunnen mensen van zowel binnen als buiten de organisatie zijn, dus het is zinvol om een systeem van derden te gebruiken voor het delen van veilige SBOM's.
Binaire versus broncode-integriteit – Als de integriteit of herkomst van verworven binaire bestanden niet kan worden bevestigd, wordt voorgesteld om die binaire bestanden opnieuw te bouwen op basis van de broncode. Dat veronderstelt dat je de integriteit en herkomst van de broncode kunt verifiëren. Het is de verantwoordelijkheid van alle schakels in de softwaretoeleveringsketen om verifieerbaar bewijs van integriteit te leveren, via digitale handtekeningen of andere mechanismen zoals een SBOM.
Samenvatting
Over het algemeen is NIST van mening dat “de praktijken, taken en implementatievoorbeelden van de SSDF een startpunt vormen om over na te denken. Het is de bedoeling dat ze worden veranderd en aangepast, en in de loop van de tijd evolueren.”
De SSDF is geen checklist die u moet volgen, maar biedt in plaats daarvan richtlijnen voor het plannen en implementeren van een op risico gebaseerde aanpak voor veilige softwareontwikkeling.
In tegenstelling tot op de Amerikaanse wet gebaseerde regelgeving zal de SSDF gebaseerd zijn op het bedrijfsleven. De overheid zal haar koopkracht inzetten om de markt ertoe te brengen zich aan dit nieuwe raamwerk van beste praktijken te houden. Als u niet kunt aantonen dat u zich aan het raamwerk houdt, komt u niet in aanmerking voor overheidscontracten. We zullen waarschijnlijk een doorsijpeleffect zien waarbij organisaties die overwegen overheidscontracten aan te vragen, van al hun leveranciers zullen eisen dat ze zich ook aan de regels houden, enzovoort in de softwaretoeleveringsketen.
Bekijk ons webinar op voor meer informatie over de nieuwe regelgeving en SSDF “Demystificatie van nieuwe cyberbeveiligingsregelgeving in 2022”.
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
