Namnge vad den får röra.
Du listar målen och väljer hur långt agenten får gå. Att läsa och kartlägga är alltid ofarligt. Allt som ändrar något körs bara där du tillåter det, och aldrig mot produktion om inte ditt scope uttryckligen säger det.
Peka en säkerhetsagent på din applikation så loggar den in, kartlägger vad du verkligen exponerar, letar svagheter en klass i taget och försöker sedan utnyttja varje hål den hittar. Du får hålen som går att återskapa, med förfrågan som bevisar vart och ett och fixen som stänger det.
Ett riktigt test är metodiskt. Agenten arbetar sig genom fem faser i ordning, bevisar det den hittar och bevisar sedan att din fix fungerade.
Du listar målen och väljer hur långt agenten får gå. Att läsa och kartlägga är alltid ofarligt. Allt som ändrar något körs bara där du tillåter det, och aldrig mot produktion om inte ditt scope uttryckligen säger det.
Varje fas är ett eget arbetsmoment med ett eget resultat, körda i ordning, så som en mänsklig testare arbetar sig genom en applikation. De fem står listade nedan.
En misstänkt svaghet är inte ett fynd. Agenten försöker utnyttja var och en, och registrerar den som bekräftad först när den går att återskapa. Det som inte kan bevisas står kvar som öppet i stället för att rapporteras som fakta.
Efter din fix kör agenten om förfrågan som bevisade fyndet, och sedan minst en variant av den, eftersom en fix som blockerar exakt den förfrågan men missar varianten bredvid inte är en fix.
Varje fas är ett eget arbetsmoment med ett eget resultat, och nästa startar från det den förra hittade.
Ge testet ett testkonto så autentiserar den sig innan den börjar. De flesta verkliga svagheter sitter bakom inloggningen, så ett test som aldrig loggar in ser dem aldrig.
Portar och tjänster, subdomäner, tekniken bakom sajten och de vägar som verkligen svarar. Med tillgång till källkoden läser den även dina beroendeversioner och route-filer, så kartan blir din verkliga angreppsyta, inte bara det startsidan länkar till.
SQL-injektion, cross-site scripting, brister i behörighetskontroll, server-side request forgery, katalogtraversering, felkonfigurerad cross-origin, exponerade inloggningsuppgifter, saknade säkerhetsheaders. Specifika svagheter, eftersökta med avsikt, en klass i taget.
Varje misstänkt svaghet får ett exploateringsförsök. De som går att återskapa blir bekräftade fynd med exakt den förfrågan som bevisar dem. Med tillgång till källkoden pekar ett bekräftat fynd dessutom ut kodraden bakom.
Varje fynd får en allvarlighetsgrad, beviset och en åtgärd. Testet räknas inte som klart förrän det har täckt de tolv sårbarhetsklasser plattformen kräver, så ett tyst test måste förtjäna tystnaden.
Black-box ser bara din publika adress, precis som en utomstående angripare. Hybrid läser även källkoden, så beteende och kod kontrolleras mot varandra och ett bekräftat fynd pekar ut fil och rad bredvid förfrågan som bevisade det.
Lämnad åt sitt eget omdöme sätter en agent betygen för lågt. En bekräftad SQL-injektion registreras aldrig under kritisk, en förbikoppling av autentiseringen aldrig under kritisk, åtkomst till en annan kunds data aldrig under hög. Nivåerna sätts av plattformen, inte av agenten.
Varje fynd bär med sig förfrågan som utlöser det, så din utvecklare kan köra den och se samma resultat i stället för att ta rapporten på förtroende. Det som inte går att återskapa skrivs inte som fakta.
Fixar verifieras genom att beviset körs om, och minst en variant av det. Fyndet kommer tillbaka antingen fixat eller fortfarande öppet, och inget stängs bara för att någon markerat det klart.
Den testar det du namngav och inget annat, inga tredjepartstjänster, ingen vandring vidare till en granne. Ingen lösenordsknäckning och ingen massskanning, så ett säkerhetstest aldrig blir en incident i sig.
Kör på infrastruktur i Stockholm, baserad inom EU, med varje åtgärd loggad.
Säkerhet är inget separat team här. Samma flotta som skeppar ditt hostade projekt med kodningsagenter kan penetrationstesta det, navigerar koden via kodbaskartor, och körs på en plattform där varje test är avgränsat och loggat.
Nej. En scanner avfyrar en fast checklista mot din adress och lämnar tillbaka en logg att reda ut själv. Det här loggar in, kartlägger vad du faktiskt exponerar, letar en svaghetsklass i taget och försöker sedan utnyttja varje misstanke, och rapporterar bara det som går att återskapa.
Att läsa och kartlägga är alltid ofarligt och alltid tillåtet. Allt som ändrar något, inloggningsförsök, injektion, förfrågningar som skriver, körs bara där du tillåter det, och aldrig mot produktion om inte ditt scope uttryckligen säger det. Den knäcker heller aldrig lösenord och massskannar aldrig.
En rubrik, en allvarlighetsgrad, svaghetsklassen, den drabbade adressen, en beskrivning i klartext, förfrågan som återskapar det och en åtgärd. Ett reflekterat cross-site scripting-hål i en sökruta kommer till exempel tillbaka som hög allvarlighetsgrad, klass xss, med exakt den förfrågan som speglar payloaden och en åtgärd som pekar ut output-kodning och en content security policy.
Ja, det är första fasen. Ge testet ett testkonto så autentiserar den sig innan något annat, eftersom svagheterna som betyder något oftast bara går att nå som inloggad.
Agenten testar om fyndet: originalförfrågan som bevisade det, och sedan minst en variant, eftersom fixar som blockerar den bokstavliga förfrågan men missar den uppenbara varianten är vanliga. Fyndet slutar antingen som fixat eller fortfarande öppet.
Endast via inbjudan medan vi introducerar ett litet antal företag. Begär en inbjudan så hör vi av oss.