Guide till Secure SDLC Review

Vad det är

Granskningen tittar på hur ert utvecklingsteam i dag hanterar säkerhet genom planering, design, kodning, testning, release och löpande underhåll. Omfattningen bekräftas skriftligt innan arbetet börjar. Beroende på vald tjänst kan detta omfatta hotmodellering eller designgranskning, kodgranskningsprocesser, användning av säkerhetstestverktyg, beroendehantering, hantering av hemligheter, godkännandeflöden för releaser, åtkomstkontroller i produktion, incidentberedskap och hur säkerhetskunskap delas inom teamet. Arbetet är utformat för att bedöma underlag och observera arbetssätt, inte för att granska enskilda utvecklare eller störa leveransplaner. Ni får en strukturerad rapport som förklarar vad som verkar fungera, var luckor eller inkonsekvenser observerades och vad ett proportionerligt nästa steg kan vara. Observationerna är ordnade så att tekniska och icke-tekniska intressenter kan se skillnaden mellan en prioriterad förbättring, en rimlig nästa investering och en fråga som kan kräva specialistkompetens eller ett separat uppdrag.

Vem det är för

En Secure SDLC Review passar företag som:

• Har ett internt eller inhyrt utvecklingsteam och ännu inte har låtit granska formellt hur säkerhet beaktas under programvaruleveransen
• Nyligen har utökat utvecklingsteamet, ändrat leveranssätt, flyttat till en ny plattform eller infört nya verktyg och vill kontrollera att säkerhetsarbetet har hängt med
• Förbereder företagsförsäljning, en regelefterlevnadsprocess eller ett större kunduppdrag där belägg för säker utvecklingsdisciplin förväntas
• Behöver besvara en fråga om säker utveckling från en revisor, investerare, kund eller styrelse på ett genomtänkt sätt utan att överdriva sin nuvarande position

Vad det hjälper till att klargöra

En Secure SDLC Review hjälper till att klargöra:

• Vilka säkerhetsrutiner som verkar finnas på plats under design, kodning, testning och release, och var underlaget är ofullständigt eller processen behöver tydligare ägarskap
• Var beroende av enskilda personers kunskap, informell kommunikation eller odokumenterade vanor kan göra säkerhetsbeslut inkonsekventa eller osynliga för nya teammedlemmar
• Vilka verktyg, kontrollpunkter eller godkännandesteg som används effektivt och vilka som skapar brus, fördröjning eller falsk trygghet
• Vad som kan åtgärdas inom det nuvarande teamet, vad som kräver utbildning eller tydligare vägledning och vad som bör diskuteras som en separat avgränsad teknisk eller organisatorisk förändring

Vad ingår

• Skriftlig bekräftelse av omfattningen innan arbetet börjar, inklusive teamstruktur, leveranssätt och de underlag som ska granskas
• Granskning av överenskomna utvecklingsrutiner genom dokumentgenomgång, intervjuer med teamet och observation av arbetsmaterial där det är lämpligt
• En strukturerad rapport med praktiska observationer, rangordnade efter relevans och genomförbarhet och inte bara teoretisk allvarlighetsgrad
• Lättbegriplig förklaring av varje observation med sammanhang för både tekniska och icke-tekniska beslutsfattare
• En ledningssammanfattning som kan delas internt som underlag för beslut om planering, rekrytering, utbildning eller verktyg
• Ett uppföljningssamtal för att gå igenom fynd, prioriteringar och realistiska nästa steg

Vad som inte ingår

• Fullständig penetrationstestning av applikationen, infrastrukturgranskning eller aktiv exploatering om det inte avgränsats separat
• Certifiering av regelefterlevnad, revisionsutlåtande eller ett intyg om att företaget uppfyller alla tillämpliga utvecklingsstandarder
• Omformning av processer, införande av verktyg eller utbildning av teamet under själva granskningen
• Löpande övervakning, kontinuerlig bedömning eller omtestning efter att det överenskomna uppdraget avslutats
• Granskning av team, kodförråd, system eller leveranspipelines som inte ingår i den skriftliga omfattningen

När det passar att välja den

Välj en Secure SDLC Review när ni vill ha en tydlig, belagd bild av hur ert utvecklingsteam hanterar säkerhet i dag, innan ni binder er vid en viss verktygsinvestering, ett utbildningsprogram eller en processförändring. Det är ett användbart steg när teamet har vuxit, leveranssätten har förändrats eller en intressent har ställt en rimlig fråga om säker utveckling som ännu inte kan besvaras med säkerhet. Den kan också vara till hjälp inför en revision, en kunds säkerhetsgranskning eller en intern planeringscykel där utvecklingsförmågan ska diskuteras. När ni redan vet exakt vilket tekniskt problem eller processproblem det gäller och behöver ett fokuserat genomförande är ett avgränsat förbättringsprojekt oftast det bättre valet. Värdet med granskningen är att den gör nästa investering mer genomtänkt och mer sannolik att träffa den verkliga begränsningen.

Vår strategi

Vi börjar med att bekräfta granskningens avgränsning och hur underlaget ska tas fram skriftligt. Ni får en lättbegriplig beskrivning som förklarar vilka team, kodförråd, rutiner och arbetsmaterial som ska granskas, vilken åtkomst eller vilka samtal som behövs och vad ni får vid överlämningen. Granskaren arbetar med den information och åtkomst som tillhandahålls, och där tillgängligt underlag lämnar en fråga öppen anger rapporten det tydligt så att den kan följas upp. Observationerna skrivs som praktiska bedömningar: rutinen som observerades, sammanhanget där den kan spela roll och en proportionerlig rekommendation eller nästa fråga. Rapporten är tänkt att stödja ett konstruktivt samtal mellan teknisk ledning, produktägare och företagsledning om vilka förbättringar som ska få resurser och när. Vid överlämningen går vi igenom prioriteringarna med er så att dokumentet kan ligga till grund för realistisk planering i stället för att bli en lista som är svår att prioritera eller agera på.

Vanliga frågor

Relaterade artiklar