| Veld |
Waarde |
| Datum |
2026-10-05 |
| Presentator |
Rens Wijnmalen |
| Onderwerp |
Wat als Google onze app(s) laat crashen? — Firebase-storing 29-09-2026 |
| Format |
Presentatie + discussie |
| Duur |
~10 minuten |
| Moment |
Weekopening |
Het hele team was aanwezig bij de presentatie tijdens de weekopening.
Op 29 september 2026 crashten bijna al onze iOS-apps direct bij het opstarten door een storing bij Google Firebase. Google verstuurde (experimentele) configuratie die de SDK zonder datacontrole wegschreef, waardoor de app crashte. De onderliggende bug zat al jaren in de SDK. In de presentatie is besproken waarom dit voor ons een risico is: een externe partij bepaalt de beschikbaarheid van onze apps, wij konden zelf niets doen en alle apps werden tegelijk geraakt.
| Control |
Onderwerp |
| A.5.24 — Incident management planning en voorbereiding |
De huidige classificatie (audit resultaat, zwakke plek, IB-incident, datalek) past niet op deze storing: er was wel schade, maar er zijn geen gegevens verloren. Verlies van beschikbaarheid ontbreekt als categorie. |
| A.5.25 — Beoordeling van beveiligingsgebeurtenissen |
Crashende apps zijn verlies van beschikbaarheid (de B van BIV) en hadden beoordeeld moeten worden als melding. |
| A.6.08 — Melden beveiligingsgebeurtenissen |
De storing is niet gemeld, mede omdat niet duidelijk was in welke categorie hij valt. |
| A.5.21 — ICT-toeleveringsketen |
Afhankelijkheid van third-party SDK’s (Firebase) in al onze apps. Een fout bij de leverancier raakt alle apps tegelijk. |
| A.8.08 — Beheer technische kwetsbaarheden |
Dependabot signaleert kwetsbare dependencies, maar een procedure voor het oppakken van meldingen (controleren, valideren, oplossen, documenteren) staat niet in het ISMS. |
- Beschikbaarheid hoort ook bij informatiebeveiliging. Een app die niet opstart is verlies van beschikbaarheid en had als incident gemeld moeten worden. Ook als er geen gegevens verloren zijn gegaan.
- Een externe dependency kan al onze apps tegelijk platleggen. We hebben geen invloed op wat een leverancier als Google uitrolt. De impact wordt groter naarmate de storing op een ongunstiger moment valt (bijv. 08:00 ’s ochtends in plaats van ’s nachts).
- Weet welke dependencies je gebruikt. Zowel direct in de app als indirect (dependencies van dependencies), en of er bekende meldingen voor zijn.
- Dependabot is een goede basis, maar niet volledig. Een OSV-scanner in de PR-CI kan hier aanvulling op zijn en controleert ook op kwaadaardige packages.
- Een melding is pas waardevol als hij wordt opgepakt. Dependency-meldingen moeten gecontroleerd, gevalideerd, opgelost en gedocumenteerd worden. Dit proces is nog niet vastgelegd in een workflow.
- Had dit een incidentmelding moeten zijn? Volgens de presentator wel, maar geen van de bestaande categorieën uit 5.24 paste.
| Actie |
Eigenaar |
Deadline |
| Alsnog een incidentmelding aanmaken voor de Firebase-storing van 29-09-2026 |
IB-coördinator |
Zo snel mogelijk |
| Classificatie voor beschikbaarheidsincidenten toevoegen aan 5.24 |
IB-coördinator |
Zo snelmogelijk |
| App-dependencies updaten waar nodig |
Dev Lead |
Wordt bij het onderhoud opgepakt |
| OSV-scanner toevoegen aan de PR-CI workflow |
Dev Lead |
Voor begin 2026 |
| Procedure voor afhandeling van dependency-meldingen vastleggen in een workflow |
Dev Lead |
Voor begin 2026 |
| Volgende presentatie |
Dennis Klein |
2026-10-19 |
