Applikationssäkerhetskonsult i Sverige: rollen, vägen in och lönefrågan

Applikationssäkerhet handlar om att skydda den kod som hanterar identiteter, betalningar, journaldata, ärenden, kundportaler och API:er, där mycket av organisationers risk flyttade under 2010-talet.

En applikationssäkerhetskonsult hjälper organisationer att hitta, förstå och minska säkerhetsrisker i mjukvara genom kodgranskning, hotmodellering, säkerhetsarkitektur, testning och rådgivning genom hela utvecklingslivscykeln. Rollen passar särskilt väl för utvecklare, testare, tekniska konsulter och säkerhetsintresserade ingenjörer som vill arbeta nära både kod och verksamhetsrisk.

Uppdaterad för 2026. Resonemangen om svensk reglering utgår från etablerade referenspunkter som GDPR, EU:s NIS2-direktiv, MSB:s vägledningar, ENISA-material samt branschpraxis från OWASP Top 10 och OWASP ASVS. Löne- och marknadsfrågor behandlas kvalitativt eftersom nivåer varierar med region, bransch, anställningsform, säkerhetsklassning, konsultmodell och teknisk stack.

Varför efterfrågan ökar i Sverige

Efterfrågan på applikationssäkerhet drivs inte bara av fler cyberangrepp. I Sverige påverkas marknaden också av pågående NIS2-implementering, ökade krav i offentlig upphandling, högre förväntningar från kunder och en bredare förståelse för att sårbar kod kan skapa verksamhetsrisk långt innan en incident inträffar.

Det märks särskilt i sektorer där digitala tjänster hanterar känsliga data eller samhällsviktiga processer. Finans, försäkring, offentlig sektor, vård, energi, SaaS-bolag och större industriföretag behöver kunna visa att säkerhet är inbyggd i utvecklingen, inte endast kontrollerad i efterhand. För en konsult innebär det ofta att uppdraget omfattar både teknisk analys och förmågan att översätta risk till språk som produktägare, jurister, arkitekter och ledning kan agera på.

Offentlig upphandling har också förändrat rollen. Leverantörer kan behöva beskriva hur de hanterar sårbarheter, beroenden, åtkomstkontroller, loggning, incidentrutiner och säker utveckling. En applikationssäkerhetskonsult som kan koppla tekniska fynd till krav, evidens och praktiska åtgärder blir därför mer användbar än någon som enbart kan leverera en skanningsrapport.

Vad rollen innebär i praktiken

En vanlig missuppfattning är att applikationssäkerhet mest handlar om att ”hacka” applikationer. Exploatering och manuell testning förekommer, men vardagen består ofta av mer kodgranskning, utvecklarcoaching, arkitekturdialog och prioritering än dramatiska intrångssimuleringar. Det gör rollen tekniskt djup, men också kommunikativ.

En arbetsdag kan börja med granskning av en pull request där en ny API-endpoint införs, fortsätta med hotmodellering för en kommande identitetslösning och avslutas med triagering av fynd från SAST, DAST eller SCA. Konsulten behöver avgöra om ett fynd är exploaterbart, om det kan accepteras temporärt, om det kräver designändring eller om verktyget ger falsklarm som bör justeras så att utvecklingsteamet inte tappar förtroendet för säkerhetskontrollerna.

Skillnaden mellan applikationssäkerhetskonsult, penetrationstestare och DevSecOps-ingenjör är viktig när en karriärväg ska väljas. Applikationssäkerhetskonsulten arbetar brett över utvecklingslivscykeln med sårbarhetsbedömning, säker kodning, arkitekturgranskning och hotmodellering. Penetrationstestaren fokuserar mer på exploatering och validering av sårbarheter i en avgränsad testperiod. DevSecOps-rollen lägger större tyngd på att automatisera policyer och säkerhetskontroller i CI/CD-flöden. I praktiken överlappar rollerna, men prioriteringen av färdigheter blir annorlunda.

Svensk arbetsmarknad och lönefrågan

Det är svårt att ge en rättvis lönebild utan att använda aktuella och jämförbara källor. Den som analyserar lön för applikationssäkerhetskonsulter i Sverige bör väga samman öppna jobbannonser, lönestatistik från relevanta fack- och branschorganisationer, Arbetsförmedlingens yrkesinformation och konsultbolagens kravprofiler. Metoden är viktig eftersom rollen kan ligga nära utvecklare, säkerhetskonsult, teknisk specialist eller arkitekt beroende på organisation.

Flera faktorer påverkar ersättningen mer än själva titeln. Erfarenhet av .NET eller Java väger ofta tungt i svenska uppdrag eftersom många större organisationer har etablerade system i dessa stackar. Svenska i tal och skrift kan också vara avgörande när uppdraget innebär workshops, rapporter, myndighetsdialog, kravtolkning eller arbete i säkerhetsklassade miljöer. Molnkunskap är värdefullt, men hybrid- och on-prem-miljöer är fortfarande vanliga, särskilt där äldre system och regulatoriska krav påverkar arkitekturen.

Konsultrollen kräver dessutom förmåga att arbeta under upphandlings- och leveransvillkor. En tekniskt korrekt rekommendation räcker sällan om den inte kan prioriteras mot tidplan, budget, driftsrisk och utvecklingsteamets kapacitet. Därför premieras kandidater som kan skriva tydliga rapporter, föreslå realistiska åtgärder och visa hur risk minskar över tid.

Färdigheter som bör prioriteras

Den starkaste grunden är fortfarande praktisk förståelse för mjukvaruutveckling. En konsult som kan läsa kod, förstå ramverk, resonera om autentisering och se hur data rör sig genom en applikation kommer snabbare fram till användbara slutsatser än någon som enbart förlitar sig på skanningsverktyg.

OWASP Top 10 är en bra startpunkt för vanliga riskkategorier, men OWASP ASVS ger mer struktur för granskning och kravställning. För svenska uppdrag är det också värdefullt att förstå GDPR:s betydelse för personuppgifter, hur NIS2 påverkar styrning och rapportering i berörda organisationer samt hur MSB:s och ENISA:s vägledningar används som referenser i säkerhetsarbete. Regelverk ska dock inte blandas ihop: GDPR handlar om dataskydd och personuppgifter, NIS2 om cybersäkerhetskrav för vissa verksamheter, och PCI DSS är relevant när kortbetalningsdata behandlas.

Verktygskunskap bör ses som ett stöd, inte som kärnan i rollen. SAST kan hitta riskmönster i kod, DAST kan testa beteenden i en körande applikation, SCA kan identifiera sårbara tredjepartsberoenden och secrets-scanning kan upptäcka läckta nycklar eller tokens. Den praktiska utmaningen är att införa kontrollerna utan att stoppa CI/CD i onödan. I ett moget flöde körs SAST vid pull request, SCA vid build, DAST mot staging, IaC-skanning i repositoryt och policy-gates före deploy. Fynd behöver triageras, baslinjer sättas och regler justeras så att högriskproblem fångas utan att falsklarm gör att teamet börjar ignorera resultaten.

Kommunikationsförmåga är lika central. Applikationssäkerhet lyckas när utvecklare förstår varför en ändring behövs och hur den kan göras utan att försena leveransen mer än nödvändigt. Den som kan formulera fynd som reproducerbara, prioriterade och kopplade till affärsrisk får större genomslag än den som beskriver allt som kritiskt.

Ett konkret kodgranskningsexempel

Följande exempel visar en typisk förbättring som en applikationssäkerhetskonsult kan föreslå vid kodgranskning i en .NET-applikation. Syftet är att minska risken för SQL-injektion genom att ersätta strängkonkatenering med parameteriserade frågor.

Example — parameteriserad fråga i .NET

using Microsoft.Data.SqlClient;

public async Task<Customer?> GetCustomerAsync(SqlConnection connection, string customerId)
{
    const string sql = "SELECT Id, Name FROM Customers WHERE Id = @CustomerId";

    await using var command = new SqlCommand(sql, connection);
    command.Parameters.AddWithValue("@CustomerId", customerId);

    await using var reader = await command.ExecuteReaderAsync();
    if (!await reader.ReadAsync())
    {
        return null;
    }

    return new Customer
    {
        Id = reader.GetString(0),
        Name = reader.GetString(1)
    };
}

Förbättringen är inte bara syntaktisk. Den visar hur konsultens arbete bör leda till en säker kodstandard som utvecklingsteamet kan återanvända, komplettera med tester och dokumentera i sina riktlinjer. Vid intervju är detta också ett bra sätt att visa att säkerhetskunskap kan omsättas i kod som ett team faktiskt kan underhålla.

Vägen in på 6 till 12 månader

En realistisk väg in börjar med den erfarenhet personen redan har. En utvecklare behöver ofta bygga säkerhetsdjup, medan en testare kan behöva stärka kodförståelse och arkitekturtänkande. Den som redan arbetar som IT-konsult kan ha fördel av kundvana, men behöver visa teknisk trovärdighet i applikationsnära säkerhet.

Under de första månaderna bör kandidaten repetera HTTP, autentisering, sessionshantering, API-design och de viktigaste riskkategorierna i OWASP Top 10.

Därefter bör kandidaten granska små kodbaser och dokumentera konkreta fynd, rekommendationer och säkra kodexempel.

Nästa steg är att skapa en enkel hotmodell för en webbtjänst med användare, administratörer, databas, externa API:er och tydliga trust boundaries.

Efter det bör kandidaten lägga in SAST, SCA eller secrets-scanning i ett eget repository och visa hur fynd triageras utan att alla varningar behandlas lika.

Mot slutet bör kandidaten öva på att presentera en riskrapport muntligt, eftersom intervjuer ofta testar förmågan att förklara tekniska problem för olika målgrupper.

Denna progression är inte en garanti för ett jobb, men den skapar bevis på förmåga. Arbetsgivare och konsultbolag behöver se att kandidaten kan göra mer än att namnge sårbarheter. De vill se analys, prioritering, åtgärdsförslag och en förståelse för hur utvecklingsteam faktiskt arbetar.

Certifieringar och utbildning utan övertro

Certifieringar kan hjälpa till att strukturera lärandet och signalera bredd, men de ersätter inte kodvana. CISSP kan vara relevant för den som rör sig mot bredare säkerhetsarkitektur eller styrning. CSSLP ligger närmare säker mjukvaruutveckling och livscykelperspektivet. CISM och CISA passar bättre när arbetet lutar mot ledning, revision eller kontrollmiljöer. CEH kan ge angriparperspektiv, men bör kompletteras med praktisk AppSec-erfarenhet. CCSP blir mer relevant när applikationerna i uppdragen körs i moln eller hybridmiljöer.

En utbildningsleverantör som Readynez kan vara ett stöd när en kandidat behöver struktur, instruktörsledd träning och certifieringsförberedelse, men valet bör utgå från rollmålet. Den som vill bli applikationssäkerhetskonsult bör prioritera utbildning som stärker säker kodning, hotmodellering, säkerhetsarkitektur, riskkommunikation och praktisk testning snarare än att samla certifikat utan tydlig koppling till uppdragen.

Portfölj som gör kompetensen synlig

En portfölj behöver inte innehålla kunddata, känsliga fynd eller avancerade exploitkedjor. Den ska visa hur kandidaten tänker och hur arbetet skulle kunna användas i ett riktigt team. Det är särskilt värdefullt i Sverige, där konsultuppdrag ofta kräver både teknisk leverans och förmåga att skapa förtroende i kunddialog.

• En hotmodell för en enkel webbtjänst, gärna med STRIDE-tänkande, riskprioritering och koppling till OWASP ASVS-krav.
• En demo-pull request som åtgärdar bristande åtkomstkontroll eller injektionsrisk i ett öppet sample-repository.
• En kort rapport som visar fynd, påverkan, reproducerbarhet, rekommenderad åtgärd och verifiering efter fix.
• Ett CI/CD-exempel där SAST, SCA eller secrets-scanning införs med tydlig triage och hantering av falsklarm.

Vid intervju bör portföljen presenteras som ett beslutsunderlag, inte som en samling skärmbilder. En stark kandidat kan förklara varför vissa risker prioriterades, vilka antaganden som gjordes, hur åtgärden verifierades och hur rekommendationen skulle anpassas om teamet hade begränsad tid.

Utmaningar som formar rollen

Den största praktiska utmaningen är sällan att hitta fler fynd. Det svåra är att hitta rätt nivå av säkerhet för applikationens risk, utvecklingsteamets mognad och organisationens ansvar. Om konsulten rapporterar för mycket utan prioritering uppstår trötthet. Om konsulten förenklar för mycket kan viktiga risker lämnas kvar.

Moderna applikationer består ofta av API:er, tredjepartsbibliotek, containrar, molntjänster, äldre system och integrationer som inte ägs av samma team. Det kräver arkitekturell förståelse och tålamod. En sårbarhet kan ligga i koden, i konfigurationen, i behörighetsmodellen, i en beroendekedja eller i antaganden mellan system.

Etiken är också central. Testning ska ske med tillstånd, enligt tydlig omfattning och med ansvarsfull hantering av känsliga fynd. En konsult som arbetar med kundmiljöer behöver veta när arbetet ska stoppas, eskaleras eller dokumenteras innan ytterligare testning sker.

Nästa steg för en hållbar karriär

Den som vill bli applikationssäkerhetskonsult bör börja där rollen faktiskt skapar värde: i mötet mellan kod, risk och människor. Praktisk erfarenhet av utveckling eller testning, kombinerad med hotmodellering, säker kodning och tydlig kommunikation, ger en stabilare grund än enbart verktyg eller certifieringar.

Ett bra nästa steg är att välja en enkel applikation, göra en hotmodell, granska koden mot OWASP Top 10, åtgärda ett par konkreta brister och dokumentera hela arbetet som om det vore en kundrapport. Den övningen tränar både teknik och konsultmässighet. För den som vill komplettera med strukturerad träning kan Readynez vara ett alternativ, men den avgörande utvecklingen sker när kunskapen används i verkliga arbetsflöden och presenteras så att andra kan agera på den.