01 / Riziko
Pomenujeme, o čo ide
Väzba medzi tokom údajov, aktérom a obchodným pravidlom ukáže, prečo je dané miesto dôležité.
Softvér a bezpečný vývoj
Od rizika k overenej oprave
Zistenie má cenu až vtedy, keď vedie k oprave v aplikácii.
02 / Zistenie
Opíšeme podmienky a dôkaz
Zistenie obsahuje dotknutú časť, predpoklady a minimálnu reprodukciu bez zveličovania dopadu.
03 / Dopad
Premeníme techniku na rozhodnutie
Dopad na údaje, dostupnosť alebo oprávnenia pomáha určiť prioritu a zodpovedného vlastníka.
04 / Oprava
Navrhneme opravu a jej overenie
Oprava mieri na príčinu. Ak je retest súčasťou ponuky, overí pôvodný scenár aj možné regresie.
Prístup k objednávkam iných zákazníkov cez API
- Dotknuté aktívum
- API objednávok, endpoint /api/orders/{id}
- Dopad
- Prihlásený používateľ zmenou čísla objednávky číta údaje iných zákazníkov.
- Dôkaz
- Reprodukčné kroky a skrátená požiadavka a odpoveď bez citlivých údajov.
- Odporúčanie
- Na serveri overovať vlastníctvo záznamu pri každej požiadavke.
- Overenie
- Retest opravy podľa dohodnutého rozsahu ponuky.
# prihlásený ako účet A
GET /api/orders/1044 HTTP/1.1
Authorization: Bearer ••••••••
HTTP/1.1 200 OK
{ "order": 1044, "owner": "účet B" }Rôzne metódy odhaľujú rôzne problémy
Bezpečnostná analýza softvéru nie je jeden automatický sken. Podľa cieľa a dostupných podkladov kombinujeme pohľad na návrh, zdrojový kód, závislosti a správanie aplikácie. Kombináciu metód a hĺbku práce určíme v zadaní.
Architektúra a hrozby
Toky údajov, hranice dôvery, identity, oprávnenia, integrácie a oddelenie tenantov. Odhalí riziká, ktoré sken kódu nevidí.
Manuálne code review
Kritické časti implementácie a obchodnej logiky s odkazom na konkrétnu revíziu a miesto v kóde.
SAST a SCA
Statická analýza kódu a kontrola závislostí ako podpora manuálneho review. Výsledky deduplikujeme a posúdime v kontexte.
DAST a aplikačný test
Overenie správania bežiacej aplikácie a API vrátane prihlasovania, oprávnení a obchodných scenárov.
SaaS a enterprise dodávky majú špecifické otázky
Ako kontrolný rámec môže poslúžiť OWASP ASVS, ako zdroj testovacích postupov WSTG a OWASP API Security. Konkrétne pokrytie vždy opíšeme v zadaní, aby bolo jasné, kde analýza končí.
- Vynucuje server oddelenie tenantov pri každej relevantnej operácii?
- Zodpovedajú roly a oprávnenia skutočnému obchodnému procesu?
- Ako aplikácia pracuje s integráciami, webhookmi, tokenmi a tajnými kľúčmi?
- Rozhoduje aplikácia o bezpečnosti rovnako v UI, v API aj na pozadí?
- Aké riziko predstavujú závislosti, konfigurácia a cesta nasadenia?
Výstupy, s ktorými môže vývojový tím pracovať
- Zhrnutie rizík, dopadov a priorít pre vedenie.
- Technický opis scenára, dôkaz a kroky reprodukcie.
- Dotknuté komponenty, verzie a odkazy na kód alebo konfiguráciu.
- Odporúčaná oprava a konzultácia zložitých alebo sporných zistení.
- Voliteľný retest pôvodných zistení na dohodnutej verzii.
Aké podklady si pripraviť
Na prvý rozhovor stačí stručný opis aplikácie, technológií, dôvodu analýzy a požadovaného termínu. Na samotnú zákazku môžeme potrebovať architektúru, konkrétnu revíziu kódu, postup zostavenia, testovacie prostredie, používateľské roly a dokumentáciu API.
Nie každá analýza potrebuje všetky vstupy. Čo chýba, sa však vždy premietne do uvedených obmedzení výsledku.
