Säker apputveckling: frågor att ställa efter Dustin-incidenten

Börja med att bestämma vem som ansvarar för appens åtkomst, ändringar och återställning efter lanseringen. En kundportal eller intern app behöver mer än en fungerande inloggningssida. Företaget behöver kunna beskriva vilka handlingar varje användare får utföra, vilka andra system appen behöver och vem som agerar när något avviker.

Den här artikeln utgår från offentliga källor kontrollerade 4 november 2026. Dustin-incidenten ger en aktuell bakgrund till frågor om verksamhetsberoenden och återgång. Den tekniska grundorsaken är inte fastställd i det underlag vi använder. Våra råd nedan är därför generella rekommendationer för utveckling och förvaltning, inte en förklaring till intrånget eller ett påstående om vad som skulle ha förhindrat det.

Vad har Dustin själva bekräftat?

Dustin meddelade den 3 september 2026 att obehörig åtkomst upptäckts i vissa interna IT-system och att vissa system tillfälligt stängts. Den 10 september bekräftade företaget att webbplatser och kundportaler för beställningar åter var tillgängliga. I den FAQ som fanns vid vår kontroll anges att incidenten är begränsad och den forensiska undersökningen avslutad. Läs Dustins egen incidentinformation.

Informationen ger inte stöd för att här ange en läckt nyckel, en särskild exploatering, en namngiven angripare eller ett kringgånget inloggningsskydd som orsak. När sådana uppgifter saknar verifierat underlag behöver de förbli okända. En teknisk säkerhetsgenomgång av ert eget system ska bygga på dess faktiska funktioner och behörigheter.

För ett företag som beställer en app är en användbar fråga hur arbetet fortsätter om en central funktion behöver begränsas. Vilka beslut går att fatta utan kundportalen? Vilken information måste finnas tillgänglig på annat sätt? Det är frågor ni kan besvara i ert eget projekt utan att spekulera om ett annat företags incident.

Beskriv det som ska skyddas innan ni väljer lösning

Utgå från en verklig arbetsuppgift. En kund kan exempelvis följa en beställning, en handläggare ändra status och en ekonomiansvarig godkänna ett underlag. Skriv ner vilket resultat var och en behöver och vilken information som krävs. Det gör det lättare att se när en funktion har fått mer åtkomst än arbetet motiverar.

Vår rekommendation är att ge varje viktigt flöde en verksamhetsägare. Den personen behöver inte vara utvecklare, men ska kunna svara på vem som får fatta ett visst beslut. Utvecklingsteamet kan sedan omsätta beslutet i kontroller och tester. Utan ett tydligt verksamhetsbeslut riskerar en behörighetsregel att bli ett tekniskt antagande som ingen har godkänt.

Skriv också ner konsekvensen av ett fel. Att en intern färgmarkering blir fel och att en kund ser någon annans underlag kräver olika prioritering. En konkret konsekvensbeskrivning hjälper beställare och utvecklare att välja var tester, granskning och driftuppföljning behöver vara mest noggranna. Den ger också bättre underlag för att avgränsa uppdraget.

Skilj inloggning från rätten att göra något

Inloggningen svarar på vilken användare systemet känner igen. Behörighetskontrollen avgör vad den personen får läsa, ändra eller godkänna. För en kundportal behöver beslutet ofta även omfatta vilket företag användaren tillhör och vilken kunds uppgifter en handling gäller. Dessa frågor behöver besvaras för varje relevant serverfunktion.

Att dölja en knapp i appen är en användbar del av gränssnittet, men servern behöver själv avgöra om handlingen är tillåten. När en användare begär ett orderunderlag ska beslutet bygga på den verifierade användarens behörighet till underlaget. Appens visning ska följa samma regel så att användaren förstår vad som går att göra.

Ett bra acceptanskriterium är begripligt för båda parter: en användare hos företag A får se företag A:s godkända orderunderlag, medan en motsvarande användare hos företag B inte får se det. Kontrollera detta med påhittade testuppgifter i en avsedd testmiljö. Komplettera med vad som ska hända när användaren saknar en roll eller när behörigheten återkallas.

Ge servrar och integrationer ett avgränsat uppdrag

En app kan behöva läsa lagersaldo, skapa ett ärende och visa betalningsstatus. Det betyder inte att varje del behöver samma möjlighet att ändra affärssystemets uppgifter. Be utvecklingsteamet beskriva vilken systemidentitet varje koppling använder och vilka handlingar som ingår i dess uppdrag. Skriv ner vem som kan godkänna utökad åtkomst.

Vår rekommendation är att hålla behörigheterna knutna till funktionen. En koppling som visar information behöver bedömas utifrån sitt läsbehov. En koppling som genomför en affärshändelse behöver dessutom tydliga regler för godkännande och felhantering. Då blir det möjligt att granska en förändring utan att först förstå hela företagets tekniska miljö.

För systemintegration är ansvar för fel lika viktigt som själva anslutningen. Om ett externt system inte svarar behöver appen veta om arbetet ska pausas, visas som väntande eller lämnas till en människa. Ett tydligt beslut minskar risken att användaren upprepar en åtgärd eftersom det första resultatet är oklart. Dokumentera vilken part som äger uppföljningen.

Hantera hemligheter som en egen förvaltningsuppgift

API-nycklar och andra tekniska åtkomstuppgifter behöver en ägare och en plan för hela användningstiden. OWASP:s vägledning behandlar bland annat samlad hantering, begränsad åtkomst, rotation, återkallande och spårbarhet för hemligheter. Den tar också upp bygg- och leveransflöden. Det är generell säkerhetsvägledning och ingen källa till orsaken bakom Dustin-incidenten. Läs OWASP:s Secrets Management Cheat Sheet.

I ett beställningsunderlag kan ni kräva en förteckning över vilka anslutningar som använder tekniska åtkomstuppgifter, vem som ansvarar för dem och hur ett byte godkänns. Själva värdena ska inte finnas i förteckningen. Uppdraget behöver också täcka hur berörda funktioner verifieras när en uppgift har bytts och vem som bekräftar att den gamla åtkomsten kan avvecklas.

Be om ett praktiskt svar på vad som händer om ansvarig utvecklare blir otillgänglig. Företaget behöver kunna förvalta tjänsten utan att en ensam persons privata anteckningar är den enda vägen vidare. Samtidigt ska ett överlämningsdokument inte sprida hemliga värden till alla som behöver förstå systemet. Skilj därför teknisk orientering från faktisk åtkomst.

Håll testmiljön användbar utan att göra den till produktion

En testmiljö ska göra det möjligt att kontrollera förändringar utan att påverka riktiga beställningar och kundärenden. Bestäm vilka externa tjänster den får kontakta och vilka testuppgifter som ska användas. En utvecklare behöver kunna se skillnad mellan test och produktion även när ett ärende är stressigt och flera miljöer är öppna samtidigt.

Vår rekommendation är att skriva ner konkreta förbud och förväntningar i acceptansen. En testbeställning ska exempelvis inte skapa ett verkligt leveransuppdrag. Ett testmejl ska gå till en beslutad mottagare. Ett fel i testmiljön ska gå att undersöka utan att någon behöver kopiera en riktig kunds fullständiga ärende till en chatt.

Kontrollera också vad en miljöförändring kan påverka. Att publicera ny kod, ändra konfiguration och göra en databasförändring är skilda operationer med olika följder. En användbar leveransbeskrivning förklarar vilka som ingår och vad som behöver verifieras efteråt. Då blir granskningen konkret och risken lättare att diskutera med verksamheten.

Välj loggar som hjälper utan att samla allt

Bestäm vilka frågor ni behöver kunna besvara när en användare rapporterar ett problem. Det kan vara vilken funktion som kördes, när den kördes, om den lyckades och vilken intern ärendereferens som hör till händelsen. Utgå från dessa frågor när ni bestämmer vad systemet ska dokumentera. Att spara hela innehållet i varje anrop är ett dåligt standardbeslut för en kundportal.

Vårt råd är att välja begränsade, användbara uppgifter och bestämma vem som får läsa dem. Lösenord, tekniska nycklar och andra hemligheter ska inte hamna i vanliga felloggar. Även kundinnehåll kan behöva särskild hantering. Ett supportärende bör börja med en referens och en beskrivning av felet, så att mer känsligt underlag bara delas när det behövs.

Låt teamet visa ett exempel på ett lyckat flöde och ett avsiktligt framkallat fel i testmiljön. Kan ansvarig person följa händelsen? Framgår vad som är okänt? Finns onödiga uppgifter i underlaget? Den kontrollen ger beställaren något konkret att bedöma och kan bli en del av överlämningen till supporten.

Planera återgång innan publiceringen

En återgångsplan behöver beskriva mer än hur föregående kodversion startas. Fråga vad som händer med uppgifter som skapats efter publiceringen, om databasen har ändrats och om externa system redan har fått nya händelser. Om de delarna påverkas kan en enkel kodåtergång vara otillräcklig eller olämplig.

Bestäm vem som bedömer ett fel efter lanseringen och vem som får godkänna åtgärden. Skriv också vilka observationer som ska få arbetet att stanna upp. Det kan vara att ett godkänt grundflöde inte längre fungerar eller att resultatet från en integration inte går att fastställa. Undvik lösa löften om att allt kan rullas tillbaka utan förberedelser.

En återställningskontroll bör visa hur en relevant del av systemet kan återfås i en avsedd miljö. Dokumentera vad som provades och vilka beroenden som inte ingick. Ett företag behöver den avgränsningen för att förstå vad kontrollen faktiskt säger. Den är mer användbar än ett allmänt besked om att backup finns.

Kräv acceptans som går att granska

För apputveckling och systemutveckling rekommenderar vi att beställaren godkänner några centrala flöden tillsammans med utvecklingsteamet. Be om förväntat resultat och faktiskt utfall. Testerna ska använda godkända testkonton och syntetiska uppgifter i rätt miljö.

1. Behörighet: rätt användare kan utföra uppgiften och en användare utan rätt behörighet får ett begripligt avslag.
2. Kundgräns: två testföretags uppgifter hålls åtskilda i både visning och serverns svar.
3. Beroende: ett otillgängligt anslutet system ger ett förutbestämt resultat som användaren och supporten förstår.
4. Ändring: en ny version kan verifieras och det finns ett dokumenterat beslut om återgång eller annan återställning.
5. Överlämning: någon annan än den ursprungliga utvecklaren kan hitta ansvarig kontakt, driftunderlag och nästa steg vid ett fel.

De här exemplen ersätter inte projektspecifik säkerhetsgranskning. De hjälper er formulera ett avgränsat krav som går att kontrollera. För en app med känsliga uppgifter eller kritiska processer behöver omfattningen bedömas utifrån dessa förutsättningar innan arbetet beställs.

Gör driftsansvaret synligt i avtalet

Lansering är en leveranspunkt, medan förvaltning är ett fortsatt ansvar. Bestäm vem som hanterar fel, följer förändringar i anslutna tjänster och beslutar om underhåll. Ange också hur verksamheten beställer nya funktioner och hur en sådan förändring bedöms mot befintliga behörighetsregler. Annars riskerar säkerhetskraven att försvinna när utvecklingen går vidare.

Ett samtal om drift och förvaltning bör därför omfatta både teknik och beslut. För en befintlig lösning kan en första leverans vara en avgränsad nulägesbild med ansvar, kända luckor och föreslagna kontroller. En bredare fråga om IT-säkerhet behöver samtidigt skiljas från det som specifikt ingår i appuppdraget.

Beskriv gärna antalet användarroller, de viktigaste arbetsflödena, anslutna system och vem som förvaltar lösningen i dag. Ange vad ni vill kunna besluta efter första genomgången. Skicka inga hemligheter eller riktiga kunduppgifter i den första kontakten. Beskriv företagets app- eller förvaltningsbehov, så kan omfattning och pris diskuteras innan arbete påbörjas.

Källor och avgränsning

Dustin: Information är primärkälla till det korta händelseförloppet ovan. Kontroll gjord 4 november 2026. Uppdateringarna och den senare FAQ:n behöver läsas med sina olika tidsperspektiv; artikeln tillskriver inte incidenten någon teknisk grundorsak.

OWASP: Secrets Management Cheat Sheet är källa till den uttryckligen markerade sammanfattningen om hantering av hemligheter. Kontroll gjord 4 november 2026. Övriga exempel är redaktionella rekommendationer för beställning, acceptans och ansvar i företagets eget utvecklingsprojekt.