Kritieke kwetsbaarheid in ASP.NET Core en hoe u uw applicaties kunt beschermen

In de afgelopen tijden, ASP.NET Core is getroffen door diverse ernstige beveiligingslekken. die direct van invloed zijn op authenticatie, gegevensbescherming en de Kestrel-webserver zelf. Als u applicaties ontwikkelt of onderhoudt met .NET, is dit niet zomaar een technisch detail: we hebben het hier over kwetsbaarheden met zeer hoge CVSS-scores (9,1 en zelfs 9,9), wat de deur kan openen naar privilege-escalatie, gebruikersimitatie en het openbaar maken van zeer gevoelige informatie.

Naast de overvloed aan beveiligingsberichten is het essentieel om te begrijpen Wat gaat er precies mis in ASP.NET Core, en welke pakketten en versies worden hierdoor beïnvloed?en hoe een modern ontwikkelteam dat werkt met CI/CD en DevSecOps-best practices zou moeten reageren, bijvoorbeeld: IDE's en belangrijke tools voor het testen van applicatiesWe gaan de ernstigste gevallen (waaronder CVE-2026-40372 en CVE-2025-55315) nader bekijken en bespreken. Microsoft heeft de volgende maatregelen aanbevolen om de risico's te beperken. En nu we het er toch over hebben, laten we het model voor fout- en uitzonderingsafhandeling in ASP.NET Core eens bekijken, want een beveiligingslek zonder goede observeerbaarheid is als zoeken naar een speld in een hooiberg.

Kritieke kwetsbaarheid in DataProtection: CVE-2026-40372

Een van de ernstigste incidenten die het ecosysteem heeft getroffen is CVE-2026-40372, een kritieke kwetsbaarheid in Microsoft.AspNetCore.DataProtection, verholpen door Microsoft met een tussentijdse update in versie .NET 10.0.7. De ernst is niet gering: CVSS 3.1 van 9,1 (Recensie) en exploitatie op afstand zonder authenticatie.

Deze kwetsbaarheid heeft gevolgen voor Versies 10.0.0 tot en met 10.0.6 van het Microsoft.AspNetCore.DataProtection NuGet-pakket en gerelateerde afhankelijkheden, zoals Microsoft.AspNetCore.DataProtection.StackExchangeRedis. Het probleem zit hem in een zeer subtiele maar verwoestende fout in de cryptografische logica van de door ASP.NET Core beheerde geauthenticeerde cipher.

Het kwetsbare onderdeel berekent de HMAC-validatietag op basis van de onjuiste bytes in de payload. En in sommige gevallen wordt de gegenereerde hash zelfs weggegooid. Deze gebrekkige validatie ondermijnt het verwachte vertrouwensmodel volledig: een aanvaller kan payloads construeren die legitiem lijken en zo de authenticiteitscontroles van het gegevensbeschermingssysteem omzeilen.

De praktische gevolgen zijn bijzonder ernstig.Dit komt doordat DataProtection niet alleen wordt gebruikt om willekeurige gegevens te versleutelen; het vormt de kern van veel beveiligingsmechanismen van ASP.NET Core: authenticatiecookies, anti-vervalsingstokens, TempData, OIDC-status en andere elementen die afhankelijk zijn van deze sleutelring. Als deze objecten kunnen worden vervalst of ontsleuteld, heeft een aanvaller een zeer directe weg naar privilege-escalatie.

Werkelijke impact: cookies, tokens en gecompromitteerde identiteit

De kwetsbaarheid in DataProtection stelt een aanvaller in staat om het vervalsen van payloads die cryptografische controles doorstaan en in sommige scenario's zelfs eerder beveiligde gegevens decoderenIn omgevingen waar ASP.NET Core Protection API's worden gebruikt, vertaalt dit zich in een zeer zorgwekkend scala aan aanvallen.

De mogelijk blootgestelde gegevens omvatten: authenticatiecookies, anti-vervalsingstokens, TempData, OIDC-status en andere interne tokensIn het ergste geval zou een niet-geauthenticeerde aanvaller een cookie of token kunnen vervalsen waarmee hij zich identificeert als een gebruiker met verhoogde privileges, zoals een applicatiebeheerder of een beheerder van een interne service.

Het scenario wordt verergerd doordat, als de aanvaller erin slaagt om tijdens het kwetsbare moment... een hoog toegangsniveau verkrijgenDit kan ertoe leiden dat de aanvrager legitieme, maar op oneerlijke wijze verkregen activa uitgeeft: API-sleutels, sessievernieuwingstokens, wachtwoordherstelkoppelingen of permanente toegangssleutelsAl deze artefacten blijven geldig, zelfs na een upgrade naar .NET 10.0.7, tenzij er aanvullende maatregelen worden genomen.

Met andere woorden: zelfs als je de patch toepast, maar niet correct reageert, Uw systeem kan nog steeds blootgesteld zijn aan tokens die al onder gecompromitteerde omstandigheden zijn uitgegeven.Daarom vergelijkt Microsoft dit probleem met historische kwetsbaarheden zoals MS10-070, die te maken hebben met padding-oracle-problemen in de verouderde ASP.NET-encryptie.

Microsoft ontdekte deze regressie als gevolg van... Meldingen van klanten die problemen ondervinden met decryptie na de installatie van .NET 10.0.6 Tijdens de Patch Tuesday van april. Na onderzoek van het incident (aanvankelijk gedocumenteerd in aspnetcore issue #66335) ontdekte het team dat het niet alleen een functionele bug was, maar een aanzienlijk beveiligingslek dat een urgente patch buiten de reguliere cyclus vereiste.

Bedrijfsomstandigheden en getroffen omgevingen

Hoewel het falen kritiek is, Niet alle omgevingen worden standaard weergegeven.Volgens officiële informatie moet er aan een aantal specifieke voorwaarden met betrekking tot pakketten en de uitvoeringsomgeving worden voldaan om CVE-2026-40372 te kunnen misbruiken.

Enerzijds moet de applicatie gebruikmaken van de kwetsbare versies van het Microsoft.AspNetCore.DataProtection-pakket (10.0.0 tot en met 10.0.6) of bibliotheken die het tijdens de uitvoering laden. Bovendien heeft de kwetsbaarheid een grotere impact op niet-Windows-besturingssystemen, zoals Linux en macOSDit sluit perfect aan bij de gebruikelijke implementatie van ASP.NET Core in containers, orchestrators en cloudplatformen.

De aanvalsvector wordt normaal gesproken uitgevoerd via het netwerk, zonder dat voorafgaande authenticatie nodig is.Dit verhoogt het gevaar in applicaties die toegankelijk zijn via internet. De aanvaller kan speciaal ontworpen payloads versturen alsof hij een gewone gebruiker van het systeem is, zonder dat daarvoor geldige inloggegevens nodig zijn.

In de praktijk betekent dit dat infrastructuren gebaseerd op microservices, Docker-containers en PaaS-platformen Systemen die afhankelijk zijn van DataProtection om sleutels of authenticatiegegevens tussen instanties te delen, zijn doelwitten met hoge prioriteit. Als de sleutelring niet is gepatcht en geroteerd, bestaat er een reëel risico dat een enkele inbreuk kan escaleren tot permanente, moeilijk te detecteren toegang.

Om al deze redenen moeten applicatiebeveiligingsteams het volgende doen: Analyseer in detail welke services het kwetsbare pakket laden. en op welke besturingssystemen ze draaien, in plaats van aan te nemen dat het probleem alleen zeer specifieke scenario's treft.

Dringende acties: upgrade naar .NET 10.0.7 en sleutelrotatie

De belangrijkste aanbeveling van Microsoft is duidelijk: Werk het Microsoft.AspNetCore.DataProtection-pakket onmiddellijk bij naar versie 10.0.7. en de applicaties opnieuw compileren met de gecorrigeerde runtimes en SDK's (bijvoorbeeld .NET SDK 10.0.203 en de bijbehorende runtimes).

Om te controleren of de omgeving correct is bijgewerkt, moet u het volgende uitvoeren: Gebruik `dotnet –info` en controleer of de runtimeversie 10.0.7 is. overeenkomstig. Het is niet voldoende om de runtime op de server te installeren; het is essentieel. applicaties opnieuw opbouwen en implementeren Door gebruik te maken van bijgewerkte containerimages of -pakketten, wordt ervoor gezorgd dat de productiecode linkt met de gecorrigeerde binaire bestanden.

Zoals eerder vermeld, zal het toepassen van de patch op zichzelf echter geen reeds opgetreden schade herstellen. Microsoft raadt dit ten zeerste af. Draai de sleutelring van de gegevensbescherming. in blootgestelde omgevingen, om elk token, cookie of inloggegeven dat tijdens de kwetsbaarheidsperiode opzettelijk is gegenereerd, ongeldig te maken.

Naast het bijwerken en roteren van sleutels is het verstandig om Het sluiten van actieve sessies afdwingen (intrekking van inlogcookies, toegangstokens, enz.), herauthenticatie vereisen en een activeren gedetailleerde logboekcontrole om verdachte activiteiten te beoordelen, met name atypische beheerdersrechten, het aanmaken van API-sleutels, het resetten van wachtwoorden en bevoorrechte bewerkingen.

Vanuit een DevSecOps-perspectief onderstreept dit incident het belang van het integreren van afhankelijkheidsscanners in de CI/CD-keten en om automatische waarschuwingen mogelijk te maken wanneer kritieke kwetsbaarheden opduiken in pakketten van derden. Net als bij elke cryptografische bibliotheek kan een kleine gedragsverandering bij DataProtection het hele beveiligingsmodel ondermijnen als deze niet grondig wordt gevalideerd.

Nog een kritieke kwetsbaarheid: HTTP-verzoekvervalsing in Kestrel (CVE-2025-55315)

Naast de kwetsbaarheid in DataProtection is er nog een andere kwetsbaarheid gemeld. Een extreem ernstig beveiligingslek in ASP.NET CoreDeze keer lag de focus op de Kestrel-webserver. Deze werd geïdentificeerd als CVE-2025-55315Het is gecategoriseerd als een HTTP-verzoekspoofingfout met een ernstscore van 9,9 uit 10.

De kern van het probleem is dat Een aanvaller kan een tweede kwaadwillige HTTP-aanvraag injecteren in een ogenschijnlijk legitieme aanvraag.Dit is kenmerkend voor zogenaamde request smuggling- of HTTP framing-manipulatie-aanvallen. Deze techniek kan worden gebruikt om beveiligingsmaatregelen op proxies, load balancers of de server zelf te omzeilen, waardoor de backend gegevens verwerkt die deze nooit had mogen accepteren.

Volgens de waarschuwing van Microsoft kan de mogelijke impact het volgende inhouden: toegang tot gevoelige informatie, diefstal van inloggegevens, ongeoorloofde wijziging van bestanden En er bestaat zelfs de mogelijkheid dat er serverstoringen optreden die de beschikbaarheid beïnvloeden. Doordat de HTTP-transportlaag direct wordt beïnvloed, is het scala aan aanvallen zeer breed, van het omzeilen van authenticatie tot het omleiden van verkeer naar interne routes.

De kwetsbaarheid treft specifiek Microsoft.AspNetCore.Server.Kestrel.Core Deze kwetsbaarheid bestaat in bepaalde versies van ASP.NET Core en wordt beschouwd als een van de ernstigste beveiligingsproblemen waarmee het platform de afgelopen jaren te maken heeft gehad. Het is wederom een ​​kwetsbaarheid die door niet-geauthenticeerde aanvallers kan worden misbruikt, waardoor het aanvalsoppervlak aanzienlijk wordt vergroot.

Barry Dorrans, technisch leider voor beveiliging bij .NET, legde uit dat de Zo'n hoge score weerspiegelt het slechtst mogelijke scenario.Aangezien de daadwerkelijke impact grotendeels afhangt van de manier waarop elke applicatie is gebouwd, is de beoordeling gebaseerd op de veronderstelling van een omzeiling van beveiligingsmechanismen met wijzigingen in de reikwijdte, een type storing dat in bedrijfsomgevingen als onaanvaardbaar wordt beschouwd.

Betreffende versies en patches voor Kestrel en ASP.NET Core

Om CVE-2025-55315 aan te pakken, heeft Microsoft het volgende uitgebracht: Beveiligingsupdates specifiek voor verschillende takken van .NET en ASP.NET CoreDit omvat zowel oudere als nieuwere versies, waaronder ASP.NET Core 2.3, 8.0 en 9.0.

In omgevingen waar het wordt gebruikt .NET 8 of hogerDe aanbevolen oplossing bestaat uit het toepassen van alle beschikbare patches. Microsoft update Vervolgens moet worden gecontroleerd of de runtime-omgevingen en pakketten de gecorrigeerde versie bevatten. Het is met name belangrijk om te verifiëren dat de applicaties opnieuw zijn gecompileerd met deze versies en dat de productie-images geen kwetsbare binaire bestanden meer bevatten.

In het geval van projecten die nog steeds worden uitgevoerd op .NET 2.3Microsoft geeft aan dat het essentieel is. Werk de pakketverwijzing Microsoft.AspNet.Server.Kestrel.Core bij naar versie 2.3.6.Compileer de oplossing opnieuw en implementeer de deployments opnieuw. Anders blijft Kestrel verzoeken verwerken met de foutieve logica die HTTP-request spoofing mogelijk maakt.

De implementaties die gebruikmaken van zelfstandige applicaties of applicaties verpakt als één enkel bestand. Ze zijn ook verplicht om vanaf nul te compileren met de gepatchte runtimes, anders bevat het uitvoerbare bestand nog steeds de kwetsbare code. Dit detail wordt gemakkelijk over het hoofd gezien als je te veel vertrouwt op het simpelweg bijwerken van de host.

Naast updates voor het framework zelf heeft Microsoft ook het volgende uitgebracht: Patches voor Microsoft.AspNetCore.Server.Kestrel.Core en andere gerelateerde componentenDit heeft als doel de robuustheid van het parsen en verwerken van HTTP-verzoeken te versterken. Kortom, het is geen op zichzelf staande oplossing, maar een gecoördineerde verbetering op verschillende punten in de ASP.NET Core-stack.

Aanvullende kritieke updates in ASP.NET Core en wereldwijd risico.

Naast deze specifieke gevallen heeft Microsoft ook andere publicaties uitgebracht. kritieke patches voor andere kwetsbaarheden in ASP.NET Core Deze kwetsbaarheden kunnen leiden tot het uitvoeren van code op afstand (RCE), privilege-escalatie en denial-of-service (DoS)-aanvallen. De combinatie van deze gebreken maakt duidelijk dat het framework, hoe volwassen ook, niet immuun is voor gevaarlijke terugvallen.

Deze storingen hebben invloed op belangrijke componenten van de ASP.NET Core runtimeDit omvat de verwerking van HTTP-verzoeken, authenticatie- en autorisatiemiddleware en API's met betrekking tot dataserialisatie en -deserialisatie. In veel gevallen kunnen aanvallers misbruik maken van deze kwetsbaarheden. onjuist opgemaakte invoer of gemanipuleerde gegevens om onverwacht gedrag uit te lokken.

De getroffen versies komen meestal overeen met releases van vóór de beveiligingspatches die in april 2026 zijn gepubliceerd.Daarom is een versiecontrole verplicht in alle productieomgevingen die nog steeds oudere builds gebruiken. Servers verouderd laten is tegenwoordig vragen om problemen.

Vanuit zakelijk oogpunt kan het niet implementeren van deze patches zeer ernstige gevolgen hebben: verlies van gegevensvertrouwelijkheid, aangetaste integriteit, onbeschikbaarheid van essentiële diensten en een reputatieschade waarvan het jaren duurt om te herstellen. Organisaties die voor bedrijfskritische applicaties afhankelijk zijn van ASP.NET Core, zouden patchbeheer moeten beschouwen als een continu proces, niet als een eenmalige taak.

De algemene aanbeveling van Microsoft is om Installeer patches zodra ze beschikbaar zijn en controleer de beveiligingsinstellingen van de omgevingen.Versterk de monitoring van verdachte activiteiten en herzie de veilige ontwikkelprocessen om de kans op het introduceren van kwetsbaarheden in de applicatiecode zelf te minimaliseren.

Fout- en uitzonderingsafhandeling in ASP.NET Core: een essentieel onderdeel van de puzzel.

Als we het over beveiliging hebben, denken we vaak alleen aan patches en cryptografie, maar Een goed foutafhandelingssysteem is essentieel in ASP.NET Core. Het framework is bedoeld om incidenten te detecteren, te onderzoeken en te beperken. Het biedt meerdere mechanismen voor het afhandelen van uitzonderingen, het retourneren van de juiste statuscodes en het beschikbaar stellen van standaardreacties, zoals ProblemDetails, via API's.

In ontwikkelomgevingen schakelt ASP.NET Core standaard de volgende functionaliteit in: Pagina met uitzonderingen voor ontwikkelaars Deze pagina wordt geactiveerd wanneer aan bepaalde voorwaarden wordt voldaan (meestal in de ontwikkelomgeving). De DeveloperExceptionPageMiddleware-middleware, die aan het begin van de HTTP-pipeline is geplaatst, wordt aangeroepen. Onderschep onafgehandelde uitzonderingen, zowel synchroon als asynchroon.en gedetailleerde informatie weergeven.

De pagina met uitzonderingen voor ontwikkelaars kan het volgende bevatten: Stacktraces, query string-parameters, cookies, HTTP-headers en endpoint-metadata.Het is een fantastisch hulpmiddel tijdens de ontwikkeling, maar logischerwijs... Het mag in een productieomgeving niet ingeschakeld worden.omdat het openbaar maken van interne details het leven voor aanvallers gemakkelijker maakt.

In een productieomgeving is het aanbevolen om een ​​configuratie in te stellen. aangepaste foutpagina met UseExceptionHandlerDeze middleware vangt onafgehandelde uitzonderingen op, registreert ze en voert het verzoek opnieuw uit via een alternatieve pipeline, die doorgaans verwijst naar een route zoals /Error.

Bij het opnieuw installeren van de leidingen is het belangrijk om rekening te houden met het volgende: Middlewares kunnen opnieuw worden aangeroepen met dezelfde HttpContext.Het is daarom raadzaam om interne statussen op te schonen, resultaten in de cache op te slaan of reeds gelezen gegevens (zoals de request body) opnieuw te gebruiken om extra fouten te voorkomen. Bovendien blijven de scoped services tijdens de heruitvoering ongewijzigd.

Toegang tot uitzonderingen en gecentraliseerde controle met IExceptionHandler

Om gedetailleerde informatie te verkrijgen over de uitzondering die de foutpagina heeft veroorzaakt, biedt ASP.NET Core de mogelijkheid om deze functie te gebruiken. IExceptionHandlerPathFeature. Via HttpContext.Features.Get Zowel het oorspronkelijke aanvraagpad als het Exception-object zelf kunnen worden opgevraagd.

Een veelvoorkomend patroon in Razor Pages bestaat uit: Sla de RequestId en een gebruiksvriendelijke foutmelding op in het paginamodel.Met IExceptionHandlerPathFeature kunt u het bericht aanpassen op basis van het uitzonderingstype (bijvoorbeeld FileNotFoundException) of het pad dat de fout heeft veroorzaakt. Hierdoor kunt u nuttigere foutmeldingen aan de gebruiker tonen zonder interne details te filteren.

Naast de paginagebaseerde of controllerspecifieke aanpak biedt ASP.NET Core de interface IExceptionHandler als een gecentraliseerd mechanisme voor het afhandelen van uitzonderingen. Implementaties van deze interface worden geregistreerd met AddExceptionHandler. Ze worden in volgorde uitgevoerd en retourneren true wanneer ze de uitzondering hebben afgehandeld en false wanneer ze de voorkeur geven aan het standaardgedrag.

Dit systeem maakt het bijvoorbeeld mogelijk om: Registreer fouten in een extern systeem en pas voorwaardelijke logica toe op basis van het type uitzondering. Of u kunt de globale HTTP-respons aanpassen zonder elke controller afzonderlijk te hoeven wijzigen. Vanaf .NET 10 kunt u met de exception middleware ook SuppressDiagnosticsCallback configureren om te bepalen wanneer metrics en logs moeten worden onderdrukt in het geval van reeds afgehandelde uitzonderingen.

Een andere zeer flexibele optie is om gebruik te maken van een lambda in UseExceptionHandlerDit houdt in dat je rechtstreeks toegang krijgt tot de context, de statuscode en het Content-Type instelt en handmatig het antwoord schrijft. Je kunt zelfs IProblemDetailsService binnen die lambdafunctie gebruiken om een ​​standaard ProblemDetails-antwoord te genereren dat het probleem duidelijk beschrijft.

Statuscodepagina's en ProblemDetails-reacties

Standaard is een ASP.NET Core-applicatie Het toont geen pagina's die geschikt zijn voor HTTP-statuscodes zoals 404.Het retourneert simpelweg de code en een lege body. Om deze ervaring te verbeteren en het debuggen te vergemakkelijken, kunt u de middleware voor statuscodepagina's inschakelen met UseStatusCodePages.

UseStatusCodePages ondersteunt verschillende modi: Platte tekst met een algemene boodschap, lambda-functies om het antwoord volledig aan te passen. of varianten die de pipeline omleiden of opnieuw uitvoeren naar een alternatief eindpunt, zoals UseStatusCodePagesWithRedirects en UseStatusCodePagesWithReExecute.

Met UseStatusCodePagesWithRedirects kan de middleware Het geeft een 302 Found-antwoord terug en stuurt de client door naar een URL die doorgaans een gebruiksvriendelijkere weergave biedt.Dit retourneert doorgaans een 200 OK-statuscode. Deze aanpak is zinvol wanneer je wilt dat de adresbalk het uiteindelijke foutpad weergeeft en je de oorspronkelijke statuscode niet wilt behouden.

UseStatusCodePagesWithReExecute, daarentegen, De initiële statuscode verandert niet.In plaats daarvan wordt het verzoek opnieuw uitgevoerd via een andere route om de responsbody te genereren. De oorspronkelijke URL blijft behouden in de adresbalk van de browser en het foutpunt kan de oorspronkelijke route en query ophalen via IStatusCodeReExecuteFeature, wat erg handig is voor logging en debugging.

Op het gebied van API's heeft ASP.NET Core de standaard omarmd. ProblemDetails als standaardformaat voor foutmeldingenDoor AddProblemDetails in de servicecontainer te registreren, kan de middleware automatisch JSON-reacties genereren met velden zoals type, title, status en traceId wanneer er client- of serverfouten optreden zonder body.

Dit gedrag kan worden aangepast door ProblemDetailsOptions.CustomizeProblemDetailsDit houdt in dat er extensies worden toegevoegd, zoals een knooppunt-ID (bijvoorbeeld een machinenaam) of andere metadata die helpen bij het traceren van problemen in gedistribueerde omgevingen. Het is ook mogelijk om een ​​aangepaste IProblemDetailsWriter te implementeren die bepaalt welke statussen moeten worden afgehandeld en hoe de details moeten worden geserialiseerd.

Lessen voor DevSecOps en continue best practices

De reeks kwetsbaarheden in ASP.NET Core en het bijbehorende .NET-ecosysteem biedt een aantal belangrijke lessen voor elk serieus ontwikkelteam: Afhankelijkheid van derden is een kritieke factor; slecht geïmplementeerde cryptografie ondermijnt het hele vertrouwensmodel. En authenticatiemechanismen zijn een belangrijk doelwit geworden voor aanvallers.

Vanuit een DevSecOps-perspectief wordt dit essentieel. integratie van afhankelijkheidsanalyse Voer in CI/CD-pipelines continue beveiligingstests uit en zorg voor een helder overzicht van alle componenten van derden die in het project worden geïntegreerd. Software Composition Analysis (SCA)-tools en kwetsbaarheidsscanners zouden geen optie meer moeten zijn, maar onderdeel moeten uitmaken van de standaard integratieworkflow.

Het is ook van essentieel belang om te versterken. Logboekcontroles en monitoring van beveiligingsincidentenDit geldt met name voor authenticatie, het uitgeven van tokens, het aanmaken van sessies, het wijzigen van machtigingen en administratieve handelingen. Zonder goede logging en waarschuwingen kan een kwetsbaarheid zoals CVE-2026-40372 of CVE-2025-55315 maandenlang ongemerkt worden misbruikt.

Ondanks de complexiteit en de vele recente bugs blijft ASP.NET Core een robuust framework, mits het correct wordt bijgewerkt en veilig geconfigureerd. De combinatie van Snelle updates, sleutelrotatie wanneer nodig, goede foutafhandeling en een proactieve benadering van beveiliging. Dat maakt het verschil tussen een robuust platform en een gemakkelijk doelwit voor aanvallers.

Deze hele reeks kwetsbaarheden en bijbehorende mechanismen om ze te verhelpen, herinnert ons eraan dat Beveiliging in ASP.NET Core is meer dan alleen het af en toe toepassen van patches.maar eerder om uit te gaan van een continue discipline: het bewaken van pakket- en runtimeversies, het afhandelen van fouten en uitzonderingen, het controleren van de HTTP-reacties en ProblemDetails die we beschikbaar stellen, en dit alles ondersteunen met volwaardige DevSecOps-processen waarmee we snel kunnen reageren wanneer er een nieuwe kritieke fout optreedt in het .NET-ecosysteem.