Risicobeheer in de softwareketen

Risicobeheer vs beveiliging

Ketenbeveiliging van software is het geheel van technische maatregelen: SBOM's, vastgepinde afhankelijkheden, beperkte builds. Risicobeheer staat daarboven. Het vraagt van welke leveranciers en componenten uw bedrijf afhankelijk is, wat er gebeurt als er een uitvalt, en of u uw inspanningen op de juiste plek hebt ingezet.

Wat zijn de risico's?

Risico	Voorbeeld	Belangrijkste maatregel
Kwetsbare componenten	Een fout in een veelgebruikte bibliotheek	SBOM's en doorlopende monitoring
Kwaadaardige componenten	Een gekaapt pakket, of typosquatting	Beoordeling, uitgestelde adoptie, limieten op uitgaand verkeer
Verlaten projecten	Een afhankelijkheid met één maintainer die ermee is gestopt	Gezondheidscontroles en een vervangingsplan
Licentierisico	Een copyleftcomponent in een propriëtair product	Licentiebeleid
Gecompromitteerde build	Een gekaapte GitHub Action bereikt uw secrets	Vastpinnen, isolatie, minimale rechten
Leveranciersrisico	Het product of een update van een leverancier is gecompromitteerd	Beoordeling, contracten, SBOM's van leveranciers
Regelgevingsrisico	Een klant of wet eist bewijs dat u niet kunt leveren	Per release bewaarde records

Een proces in zes stappen

1. Stel de inventaris op. Noteer de producten die u maakt en de software die u koopt. Bewaar voor wat u bouwt een SBOM per release. U kunt niet beoordelen wat u niet ziet.
2. Rangschik op wat ertoe doet. Een bibliotheek in uw betaalservice is iets anders dan een bibliotheek in een interne tool. Beoordeel producten op blootstelling, gegevens en bedrijfsimpact.
3. Beoordeel de risico's. Kijk naar kwetsbaarheden, de gezondheid van projecten, licenties en hoe elke leverancier met beveiliging omgaat. Doe dat grondig voor de hoogste categorie en beperkt voor al het andere.
4. Behandel ze. Beslis per risico of u het oplost, vervangt, er een maatregel aan toevoegt of het accepteert. Een geaccepteerd risico heeft een eigenaar en een evaluatiedatum nodig.
5. Monitor doorlopend. Risico verandert zonder enige wijziging aan uw kant, bijvoorbeeld als er een advisory verschijnt of een maintainer vertrekt. Jaarlijkse evaluaties missen dat.
6. Rapporteer. Geef de leiding een kort overzicht: de grootste risico's, de blootstelling in de loop van de tijd en wat is geaccepteerd. Klanten en auditors zullen naar de details vragen.

Leveranciers beoordelen

Vragenlijsten alleen vertellen u wat een leverancier zegt. Vraag om zaken die laten zien wat ze doen:

• Een SBOM van het product, met een vermeld formaat en een manier om updates te krijgen
• Hoe ze met kwetsbaarheden omgaan, en hoe snel ze klanten informeren
• Een beveiligingscontactpersoon en een disclosure policy
• Hoe ze releases bouwen, en of ze kunnen aantonen waar een release vandaan komt
• Hoe lang een versie beveiligingsfixes krijgt
• Certificeringen en auditrapporten die het product dekken dat u koopt

Leg de verwachtingen vast in contracten. Een SBOM of een meldingstermijn eisen is bij ondertekening veel makkelijker dan na een incident.

Kaders die u kunt volgen

• NIST SP 800-161 is de belangrijkste referentie voor cybersecurity supply chain risk management, of C-SCRM. Het werkt op elk niveau van een organisatie en neemt ketenrisico op in het bredere risicobeheer.
• Het NIST SSDF behandelt werkwijzen voor veilige ontwikkeling, en is daarmee een goede basis voor wat u van leveranciers vraagt, en van uzelf.
• SLSA geeft u een gedeelde taal om te bespreken hoe betrouwbaar een build is.
• ISO/IEC 27001:2022 bevat maatregelen voor ICT-ketenbeveiliging (Annex A 5.21) en technische kwetsbaarheden (8.8). De norm eist geen SBOM, maar SBOM's zijn goed bewijs voor die maatregelen.
• NIS2 noemt ketenbeveiliging in artikel 21(2)(d) als verplichte maatregel voor entiteiten die eronder vallen.

Hoe u het meet

Kies een paar maatstaven die tot beslissingen leiden:

• Aandeel producten met een SBOM voor de huidige release
• Tijd om "zijn wij getroffen?" te beantwoorden bij een nieuwe kritieke kwetsbaarheid
• Blootstellingsvenster: hoe lang een kwetsbare versie in productie stond
• Aandeel leveranciers uit de hoogste categorie dat het afgelopen jaar is beoordeeld
• Aantal geaccepteerde risico's waarvan de evaluatiedatum is verstreken

Waar CRACI helpt

CRACI geeft een risicoprogramma de gegevens die meestal ontbreken voor software die u bouwt. Het legt vast wat elke GitHub Actions-build heeft binnengehaald, inclusief gedeclareerde licenties, in SBOM's die u per release kunt bewaren en in CycloneDX of SPDX kunt delen. Het monitort wat is geleverd, laat zien welke builds een kwetsbaar pakket bevatten, zodat u de periode ziet waarin u getroffen was, en kan licentiebeleid handhaven en builds blokkeren met policy gates. Zie ketenbeveiliging van software met CRACI en hoe de tools zich verhouden.

Leveranciersbeoordeling en uw risicoregister blijven bij uw governancetools en uw team.

Risicobeheer in de softwareketen: veelgestelde vragen

Wat is risicobeheer in de softwareketen?

Het is de manier waarop een organisatie het risico identificeert, beoordeelt en verkleint van software die ze niet zelf heeft geschreven, waaronder open-sourcepakketten, commerciële producten, SaaS-leveranciers en buildtools.

Wat is C-SCRM?

C-SCRM staat voor cybersecurity supply chain risk management, de term die NIST gebruikt. NIST SP 800-161 is de belangrijkste richtlijn en beschrijft hoe u cyberrisico's in de hele keten vindt, evalueert en verkleint, op elk niveau van een organisatie.

Wat zijn de grootste risico's in de softwareketen?

Kwetsbare en kwaadaardige open-sourcecomponenten, gecompromitteerde buildsystemen en CI-tools, verlaten projecten, licentieproblemen en leveranciers die worden gehackt.

Wat is het verschil met third-party risk management?

Third-party risk management kijkt meestal naar leveranciers als bedrijven. Risicobeheer in de softwareketen gaat door tot op het niveau van componenten en buildprocessen, inclusief open-sourceprojecten waar geen leverancier achter staat.

Wie is hiervoor verantwoordelijk?

Doorgaans stelt de leiding van security of risk het programma op, is productbeveiliging eigenaar van wat het bedrijf bouwt en is inkoop of leveranciersbeheer eigenaar van wat het koopt. Engineeringteams lossen op wat wordt gevonden.