Akamai — „Tell me about yourself"

Product Security · Penetration Tester (remote) · po angielsku · metoda „I-CAN" (Interview Gold / Joe)

Metoda z filmu — formuła „I · C · A · N (+P)":

Senior: celuj w 2-3 min. Spokojnie, nie na pamięć. Na końcu zadaj pytanie do panelu.

Twój gotowy skrypt (do przećwiczenia na głos)

I — Introduction

"I'm a penetration tester with 12 years of hands-on offensive security experience, specializing in web applications and APIs. I currently run B2B engagements, after working with firms like Trustwave and Securitum."

C — Career & achievements (3)

"Over my career I've delivered more than 500 security assessments, heavily in the financial sector — over ten banks — plus government agencies and SaaS. A few highlights:
1. I discovered a zero-day in Oracle's Access Manager SSO — an authentication-logic flaw that got a CVE assigned (CVE-2020-2747).
2. On bank engagements I've repeatedly found critical Web/API and business-logic flaws before they hit production, and delivered remediation the dev teams could act on directly.
3. Most recently I built my own tooling that integrates local LLMs into the audit workflow — speeding up source-code analysis and vulnerability discovery while keeping client data in-house for NDA compliance."

A — Attributes & skills (top 3 z JD, ich językiem)

"My core strengths map directly to this role: deep white-box web and API penetration testing; using AI and LLMs to enhance static and dynamic analysis and automate vulnerability discovery; and communicating findings clearly to both technical and non-technical audiences with actionable remediation guidance. I also write my own custom tools in Python."

N — Next (motywacja)

"What excites me about Akamai is doing product security at global scale — and especially the AI/LLM part of this role, which is exactly what I've been building on my own. I see this as the ideal next step to bring that into a world-class team."

P — Personal (opcjonalnie, lekko)

"Outside work I'm into building small automation side-projects and I follow security research closely — it keeps me sharp."

Zakończ pytaniem do panelu (top tip z filmu)

"Would you like me to go deeper on any of these — for example the AI/LLM tooling or the bank work?"

Delivery (kluczowe wg Joe)

Twój hak: WAF-y Akamai znasz produkt od strony atakującego

"I've actually come up against Akamai's WAF on several authorized web engagements — Kona Site Defender and App & API Protector — and I've had to work through it to reach real findings. So I know your flagship product from the attacker's side, which I think is genuinely useful perspective for a Product Security role: I understand not just how to break apps, but how the WAF sees traffic and where its blind spots tend to be."
Konkrety, gdyby dopytali „how did you bypass it?" (mów o autoryzowanych testach):

Ton: z szacunkiem, nie „pobiłem wasz produkt" — raczej „rozumiem obie strony i dlatego mogę pomóc go wzmacniać". WAF = warstwa obrony-w-głębi, nie zastępstwo bezpiecznego kodu.

Gaps — uczciwie, potem pivot

IDA Pro / RE: "Solid fundamentals — x86, memory, stack-based buffer overflows, I can read assembly. But deep binary RE isn't my daily focus — my strongest value is Web, API and AI automation."
Fuzzing: "I do application-layer fuzzing daily — Intruder / Turbo Intruder in Burp for logic flaws and race conditions. I know how binary fuzzers like AFL work, but the app layer is my main vector."

Pieniądze — najpierw wyciągnij ICH widełki (uwaga: to UoP!)

"I usually work B2B, so for a permanent employment contract at Akamai I'd need to translate expectations. Could you share the approved gross monthly range for the role first? Then I'll tell you if we're aligned."
Realia (ich budżet ≈ 17-18k brutto UoP):

Jeśli powiedzą 17-18k: spokojnie — „that's below my current earnings; I'm open if there's flexibility, or if a B2B contract is possible." Nie pal mostu — świetna linijka w CV.

Notice: 1 mies., elastyczny (dogadam z managerem).

Popularne pytania (gotowe odpowiedzi)

„What do you know about Akamai?" / „Why Akamai?"

"Akamai started as the CDN pioneer and is now one of the largest edge and cloud platforms — the tagline says it well: you power and protect life online. Over the years the security side became huge: WAF and API protection (App & API Protector), DDoS mitigation (Prolexic), Bot Manager, and Zero-Trust / microsegmentation after Guardicore. With Linode you also moved into cloud compute — Akamai Connected Cloud. For me the exciting part is that this is Product Security: I'd be testing the very products that protect a big chunk of the internet, at global scale."

Fakty: założona 1998 (z MIT), „powers and protects life online"; security: App&API Protector (WAF), Prolexic (DDoS), Bot Manager, Guardicore (Zero Trust/segmentacja), Neosec (API security); cloud/edge: Linode → Akamai Connected Cloud.

„Why are you leaving / looking for a change?"

"It's all positive — I'm looking for a stable, long-term role with full scope and global scale. My current setup is a young, growing practice, so utilization isn't always full-time, and I'd like to commit fully to one strong team. This role fits that exactly — and it means I'm quite flexible on start date."

„Greatest strength?"

"Deep Web/API testing combined with business-logic thinking — I find the flaws scanners miss. And lately, turning that into AI-assisted automation."

„Weakness?"

"Deep binary reverse engineering isn't my daily focus — I have the fundamentals but I've deliberately gone deep on Web/API and automation instead. It's an area I keep sharpening when a job needs it."

„Proudest finding / a tough vulnerability" (STAR)

"On a bank engagement I dug into an SSO flow — Oracle Access Manager. By analysing the authentication logic I found a flaw that let me forge valid sessions. I reported it responsibly and it received a CVE (CVE-2020-2747). It's a good example of how logic analysis beats pure tooling."

„How do you explain a vulnerability to non-technical people?"

"I drop the jargon and frame it as business impact: who can do what, and what it costs the company — data, money, trust, compliance. Then I give the technical team the exact reproduction and a concrete fix."

„How do you keep up to date?"

"PortSwigger Research, Project Zero, watchTowr, CISA KEV, conferences and bug-bounty write-ups — plus hands-on labs. It's a habit, not a one-off."

„Walk me through how you test a web app" (metodyka)

"Recon and mapping, understand the roles and the business logic, then systematically: auth/session, access control (IDOR/BOLA with two accounts), injection, then the logic and chaining. I verify everything manually — the scanner gives candidates, not verdicts — and I write it up with clear remediation."

6 obszarów wprost z ogłoszenia (req 2900) — szybka powtórka

To są tematy, których nie było w starej ściądze, a stoją w wymaganiach czarno na białym. Do każdego jest 6-8 pytań w quizie (na samej górze listy).

1. Fuzzing — „experience with techniques like fuzzing"

"I use coverage-guided fuzzing — AFL++ or libFuzzer — where the binary is instrumented so the fuzzer keeps only inputs that hit a new edge. In my experience the bottleneck is never the mutation engine, it's harness quality and running with sanitizers. Without ASAN you simply miss the bugs that don't segfault — a few-byte heap overflow or a use-after-free won't crash on its own."

Musisz mieć w głowie: coverage-guided vs dumb · harness = LLVMFuzzerTestOneInput, ma być bezstanowy i szybki · afl-cmin (korpus) / afl-tmin (pojedynczy plik = minimalny PoC do raportu) · ASAN/UBSAN/MSAN i czemu bez nich kampania to teatr · dedup po stack trace, ocena: READ vs WRITE, kontrola nad offsetem · structure-aware (libprotobuf-mutator, gramatyki) gdy jest checksuma/magic bytes · protokoły = maszyna stanów, stąd AFLNet/boofuzz albo wyciągnięcie parsera do harnessu.

Pułapka: jeśli powiesz „fuzzing" mając na myśli Burp Intruder, a oni pytają o AFL++ — zgrzyt. Rozróżnij oracle: web = kod odpowiedzi/czas/treść, binarny = crash + sanitizer.

2. Bug bounty triage — „supporting Akamai's bug bounty programs"

"My rule is that the burden of proof is on the report, and what gets judged is the evidence, not the narrative. I reproduce on a clean account before anything else — that single step filters out most of the noise. On duplicates I go by root cause, not by symptom: same unescaped sink means one bounty, two components means two. And I always give the researcher the technical reason, because a program runs on its reputation."

Musisz mieć w głowie: kolejność (zakres → reprodukcja → impact → duplikat → severity → hand-off) · duplikat = root cause · CVSS Base nie zna kontekstu aktywa, stąd Environmental/Threat + własna macierz · self-XSS = informative, ale zaproś do pokazania łańcucha (CSRF, login CSRF, render u admina) · „nie odtworzyłem" ≠ „nie ma" — na CDN różni się region, wersja konfiguracji, feature flag, stan cache · AI slop: odsiewaj po dowodzie (halucynowane CVE/pliki są falsyfikowalne), nie po stylu.

3. LLM jako narzędzie — „leverage AI and LLMs to enhance static and dynamic analysis"

"I treat the model as a hypothesis generator, never as an oracle. For code review I force a verifiable structure — quote the code with file and line, give me the source-to-sink path, the preconditions, and tell me what would falsify this. Line numbers are mechanically checkable, so a hallucination dies on the first grep. The proof always comes from execution: a request, a crash, a grep."

Musisz mieć w głowie: mocne (transformacja: streszczanie kodu, warianty payloadów, skrypty, szkielety harnessów, triaż szumu, redakcja raportu) vs słabe (orzekanie o istnieniu podatności, stan rozproszony, wyścigi) · triaż SAST z cytatem+linią, próbka kontrolna na FN · poufność: kod klienta do publicznego API to disclosure stronie trzeciej (NDA, RODO, retencja) → model lokalnie/VPC, anonimizacja · sycophancy: nie pytaj „pokaż mi tu SQLi" · OSS-Fuzz generuje harnessy LLM-em, Big Sleep (P0+DeepMind) znalazł realny bug w SQLite — ale oracle dalej mechaniczny · automatyzuj odwracalne, nie zakres i nie akcje nieodwracalne.

4. Secure code review — „white-box penetration testing"

"In an unfamiliar repo I start from the attack surface rather than reading top to bottom — routing, request handlers, parsers, deserialization, process invocation, database access — and then I follow taint from the source the attacker controls to the sink. Before I call a control effective I check the sink's context, every path that reaches it, and whether I can bypass it — validation that rejects '../' is format validation, not an authorization control."

Musisz mieć w głowie: source→sink i czemu skaner myli się na sanitizerach zależnych od kontekstu · C/C++: integer overflow → undersized alloc → memcpy, off-by-one, signed/unsigned, UAF · Go: ignorowany err, wyścigi, brak limitu rozmiaru, text/template vs html/template, SSRF przez redirecty · git jako źródło: silent fix, patch gap, wariantowanie poprawki · finding z kodu bez instancji: pokaż ścieżkę i warunki, nazwij to uczciwie (kod ≠ potwierdzony exploit).

5. Edge/CDN — ich własny produkt

"Cache poisoning is about unkeyed input — a header that changes the response but isn't part of the cache key, so one poisoned entry gets served to everyone. Before I test anything on a CDN I profile the cache first: what's in the key, what the TTL is, and I use a cache buster so I don't poison a shared entry for real users."

Musisz mieć w głowie: cache poisoning (unkeyed input) vs cache deception (ścieżka wygląda na statyczną, treść jest prywatna) · ESI injection · request smuggling front-end/back-end, H2 downgrade · ekspozycja origin i Site Shield · EdgeWorkers/EdgeKV jako nowa powierzchnia (kod na brzegu!) · WAF bypass przez różnicę normalizacji między brzegiem a origin · Pragma: akamai-x-cache-on i debug headers.

To jest twój hak: 12 lat web/HTTP przekłada się wprost na ich domenę — smuggling, cache, host header to nie ciekawostki, tylko rdzeń produktu CDN.

6. Custom tooling — „developing custom tools as needed"

"I write a tool when the check is repeatable and the oracle is mechanical — otherwise I'm just automating my own guesses. The hard part is never the requests, it's the oracle: I need a baseline, a control request, more than one indicator, and out-of-band confirmation where I can get it. And anything that touches a live product needs rate limiting, a kill switch, and traffic I can identify as mine in their logs."

Musisz mieć w głowie: kiedy własne vs gotowe · BCheck (deklaratywny, szybki) vs rozszerzenie Montoya API (logika, stan) · budowa oracle: baseline + kontrola + wiele wskaźników + OOB · backoff, bezpiecznik, identyfikowalny ruch testowy · Python (ekosystem, prototyp) vs Go (współbieżność, jeden binarek do wysłania) · co odróżnia skrypt od narzędzia utrzymywanego przez zespół: testy, obsługa błędów, dokumentacja, ktoś inny to uruchomi.

Bonus: retest — „re-test known vulnerabilities to validate that they've been fixed"

"A fix isn't verified until I've proven the vulnerability is gone across the full original scope — not that the old payload stopped working. I re-test every component and every surface from the original finding, and I actively try to bypass the new control: suffix and userinfo tricks against an allowlist, encoding and traversal against validation. Default verdict is 'still vulnerable' until I can show otherwise."

To twoja mocna strona — masz na to spisany protokół. Powiedz o domyślnym werdykcie i o tym, że odrzucony request niczego nie dowodzi o ścieżce, której nie odpaliłeś.

⭐ Twoja karta nr 1 — CVE-2020-2747 (naucz się tego na pamięć)

Reflected XSS w Oracle Access Manager SSO, endpoint /oamcustompages/pages/pswd.jsp. Zgłoszony 2018, CVE nadane 2020 (Oracle długo procesuje — jeśli ktoś zauważy rozjazd dat, to normalne). Ta jedna historia obsługuje: proudest finding, hardest finding, why should we hire you, pytanie o CVE i o supply chain. To dowód, że jesteś seniorem naprawdę.

Gotowa opowieść — na głos, ~75 sekund

"The one I'm proudest of is CVE-2020-2747. I was testing a Polish public institution that used Oracle Access Manager for single sign-on. On the password reset page I noticed one of my inputs was being reflected straight back in the response — a classic reflected XSS signal. The specific endpoint was the standard OAM page, oamcustompages/pages/pswd.jsp. The important part wasn't the XSS itself — it was realizing where it lived. This wasn't the client's code. That page ships with the product, so every organization running Oracle OAM for SSO — banks, governments, enterprises worldwide — exposed the same page and the same bug. It stopped being one client's finding and became a supply-chain problem. So I reported it to Oracle directly through responsible disclosure. I worked with their security team through the proof of concept, pinned down the exact OAM version, and it went through their full process — resulting in a vendor security advisory and a patch, CVE-2020-2747. What I took from it: the highest-impact findings often aren't the most technically complex. This was a reflected XSS, textbook. The value was in recognizing the blast radius and handling the disclosure properly."

Fakty, którymi się posługujesz (żeby brzmieć konkretnie)

Podatność: reflected XSS · produkt: Oracle Access Manager (OAM), moduł SSO · endpoint: /oamcustompages/pages/pswd.jsp (strona resetu/odzyskiwania hasła) · jak znalazłeś: testowałeś polską instytucję publiczną, zauważyłeś, że parametr jest odbijany w odpowiedzi na stronie odzyskiwania konta · kluczowy wniosek: to strona standardowo dostarczana z produktem, więc dotyczyła KAŻDEJ instalacji OAM · proces: responsible disclosure do Oracle (secalert_us), PoC, ustalenie wersji OAM · skutek: vendor security advisory + patch, CVE-2020-2747.

Jak to zagrać — trzy ruchy:
1. Rzuć konkretną nazwą endpointu (pswd.jsp) — taki detal nikt nie zmyśla, to uwiarygodnia całą historię.
2. Postaw akcent na blast radius, nie na technikę XSS — to pokazuje, że myślisz jak product security, o skali, nie o pojedynczym bugu.
3. Zakończ pokorą („podręcznikowy XSS, wartość była w rozpoznaniu skutku") — brzmi jak senior, nie jak przechwałka.

Czego NIE mówić: że Oracle pomylił cię w mailu z kimś z ING — tylko zaciemnia. I nie zawyżaj impaktu: to reflected XSS, więc wymaga dostarczenia linku ofierze; jeśli dopytają, powiedz to uczciwie — reflected, nie stored.
Jak pomostować z tego do „why Akamai": "That experience is actually part of why product security at Akamai appeals to me — I've seen how one issue in a widely-deployed product cascades to everyone using it. That's exactly the scale you operate at."

🤖 Twój projekt VPA — gdyby zapytali (pasuje wprost do „leverage AI/LLMs")

Virtual Pentesting Army. Ogłoszenie dosłownie wymaga „leverage AI and LLMs to enhance static and dynamic analysis, and create automation for vulnerability discovery" — a ty to zbudowałeś, nie tylko używasz. To twoja druga karta atutowa po CVE.

Krótka odpowiedź techniczna — na głos, ~45 s

"VPA — Virtual Pentesting Army — is an AI orchestrator I built that runs offensive workflows end-to-end, local, cloud or hybrid. It ties together more than ten of my own custom tools into one pipeline. Two design decisions matter most. First, what I call a Red Team Dialectic: two agents work against each other — one proposes a vulnerability hypothesis, the other tries to refute it — so a finding has to survive disagreement before it's kept. Second, Proof-of-Exploit Gating: nothing gets reported as a vulnerability unless there's a deterministic, live HTTP replay proving it. No PoC replay, no finding. The reason I built it that way is exactly the lesson I'd bring to a product-security team: an LLM is great at generating hypotheses at volume, but it hallucinates, so the proof has to come from execution, never from the model's say-so. The orchestrator scales the hypothesis generation; the gating keeps it honest."

Fakty, którymi się posługujesz

Co to: end-to-end multi-model AI orchestrator (local / cloud / hybrid) · skala: integruje 10+ własnych narzędzi ofensywnych w jeden pipeline · Red Team Dialectic: dwa agenty — jeden stawia hipotezę podatności, drugi ją obala; finding musi przetrwać spór · Proof-of-Exploit Gating: zero podatności zgłoszonych bez deterministycznego, żywego HTTP replay (dowód z uruchomienia, nie ze słowa modelu) · filozofia: „Intelligence Embedded in Code" — logika seniora zakodowana w deterministycznych algorytmach, LLM tylko tam, gdzie wnosi wartość.

Dlaczego to działa na rozmowie: nie mówisz „używam ChatGPT do pentestów". Mówisz, że zaprojektowałeś system, który rozwiązuje główny problem AI w security — halucynacje — przez wymóg dowodu z uruchomienia. To jest dokładnie dojrzałość, której szukają. I łączy się z twoim CVE: obie historie mówią „dowód pochodzi z uruchomienia, nie z założenia".

Uczciwa granica: to twój własny projekt/narzędzie, nie produkt z tysiącami użytkowników. Jeśli dopytają o skalę czy testy — powiedz wprost, że to twój warsztat i R&D, ciągle rozwijany. Nie zawyżaj.
Pomost do ich pracy: "That's why the AI part of this role appeals to me — I've already built the human-in-the-loop, proof-gated approach, and I'd rather apply it to one product deeply than spread it thin across short engagements."

Karta atutowa — research z 5 sierpnia 2026

Dzień przed twoją rozmową James Kettle opublikował HTTP Terminator (Black Hat USA 2026, DEF CON 34). Jeśli padnie pytanie „how do you keep up?" albo „what's interesting in web security right now?" — masz odpowiedź, której nie ma nikt, kto przygotowywał się tydzień temu.

Kwestia gotowa do powiedzenia

"Actually the most interesting thing landed this week — James Kettle published HTTP Terminator, his latest desync research, presented at Black Hat. What struck me isn't just the new triggers, though those are neat — Transfer-Encoding gzip with HTTP/1.0 producing a CL.0 pattern, multipart/byteranges, duplicate Content-Length. It's the new attack classes. Shared-parser confusion in particular generalizes beyond desync: if a server reuses parsing code between requests and responses, it'll process response-only features like Set-Cookie in an inbound request. That's a whole category, not a trick. And the part I found genuinely relevant to how I work: the research was AI-assisted, but his conclusion was that human-AI collaboration outperformed full autonomy — the autonomous runs drowned in false positives from HTTP pipelining. That matches my own experience: the model is good at generating hypotheses at volume, but someone still has to decide what's real."

Gdyby dopytali o szczegóły

Nowe wyzwalacze: Transfer-Encoding: gzip + HTTP/1.0 → CL.0 · Content-Type: multipart/byteranges · metoda CONNECT · Early-Data bez Pre-Shared-Key · dwa identyczne Content-Length.
Nowe klasy: shared-parser confusion · status-line injection (kopiowanie ciągu protokołu z żądania do linii statusu) · range cache poisoning (żądania zakresu bez 206 → cache zapisuje niepełną treść) · response forking (dwie odpowiedzi na jedno poprawne żądanie).
Dangling-byte: przemycone żądanie bez ostatnich bajtów odracza drugą odpowiedź i eliminuje wyścig w Response Queue Poisoning — atak losowy staje się powtarzalny.
Obrona: HTTP/2 upstream (usuwa dwuznaczność u źródła) · allowlista metod po obu stronach · osobna allowlista metod z ciałem (POST/PUT/PATCH, nigdy GET/HEAD/OPTIONS) · sanityzacja ciągów protokołu.
Narzędzia: HTTP Terminator (kod otwarty), zaktualizowany HTTP Request Smuggler, Turbo Intruder z interfejsem MCP, Param Miner z techniką protocol ruler.

Jak tego użyć, żeby zabrzmiało dobrze: nie recytuj listy. Powiedz jedną rzecz ze zrozumieniem — najlepiej shared-parser confusion, bo to nowa klasa, nie kolejny payload — i zaznacz, dlaczego to istotne u nich: każda architektura z warstwą pośredniczącą między klientem a origin jest dokładnie tym środowiskiem, w którym te błędy żyją.

Czego nie mów: że to testowałeś. Czytałeś research opublikowany wczoraj — to wystarczająco mocne i jest prawdą.

„How would you approach testing one of our products?"

Pytanie, na którym większość kandydatów improwizuje. Poniżej gotowa struktura — pięć kroków, w kolejności, w jakiej je wypowiadasz. Nie musisz znać ich produktu od środka; masz pokazać sposób myślenia i to, że rozumiesz, czym różni się testowanie platformy brzegowej od testowania zwykłej aplikacji.

Kwestia otwierająca — powiedz to na początku

"I'd start by understanding the architecture rather than the features — specifically, where the trust boundaries are. In a CDN the most interesting boundary is between the edge and the origin, because that's where two systems parse the same request and can disagree. Most of the serious bugs in this space — smuggling, cache poisoning, WAF bypass — are really parser or normalization disagreements across that boundary."

To jedno zdanie ustawia cię jako kogoś, kto rozumie klasę problemów, a nie zna listę technik. Dalej rozwijasz w pięciu krokach.

Krok 1 — architektura i granice zaufania

"First I map what actually sits in the path: edge, WAF, cache, any edge compute, then the origin. For each hop I ask what it parses, what it rewrites, and what decision it makes based on that. A control that's enforced at the edge but acted on at the origin is where allowlists leak."

Wymień konkretnie: co jest w kluczu cache · gdzie następuje normalizacja nagłówków i ścieżek · czy jest downgrade H2 → HTTP/1.1 · kto podejmuje decyzje autoryzacyjne (brzeg czy origin).

Krok 2 — profilowanie cache'a, zanim cokolwiek wyślesz

"Before I test anything I profile the cache: what's in the key, what the TTL is, which responses are cached at all — including error responses — and how I'd purge an entry if I needed to. That's reconnaissance, and skipping it is how people damage production."

To jest moment, w którym pokazujesz dojrzałość operacyjną. Wymień: X-Cache/Age/Vary · testowanie różnicowe klucza · Param Miner do ukrytych wejść.

Krok 3 — hipotezy specyficzne dla brzegu

"Then I work through hypotheses that are specific to this architecture: unkeyed inputs that reach the response, cache deception on paths the app and the cache classify differently, request smuggling including the H2 downgrade variants, header normalization differences like underscore versus hyphen, and error responses being cached — the CPDoS pattern."

Dorzuć, jeśli będzie przestrzeń: ESI injection, ekspozycja origin (obejście brzegu), EdgeWorkers/EdgeKV jako kod wykonywany przed wszystkim innym i współdzielony stan między żądaniami różnych użytkowników.

Krok 4 — bezpieczeństwo samego testu (to jest twój najmocniejszy punkt)

"Throughout, I work with a cache buster so I'm operating on my own entry rather than one served to real users, my proof-of-concept payloads are harmless — a marker in a canonical tag, not a working redirect — I agree a purge path before I start, and I make my traffic identifiable in their logs. If I need to demonstrate real impact without a buster, that's a conversation to have in advance, not a decision I make alone."

Dlaczego to jest najmocniejsze: Akamai obsługuje ruch ogromnej części internetu. Kandydat, który sam z siebie mówi o niepsuciu produkcji klientom, brzmi jak ktoś, komu można dać dostęp. To rzadsze niż znajomość technik.

Krok 5 — co z tego wynika

"And I'd report it in two layers — the business impact in a paragraph for people deciding priorities, and the exact path, preconditions and a concrete fix for the engineers. If the risk turns out lower than it first looked, I say so myself. Then I'd retest, and my default verdict is that it's still vulnerable until I've proven the issue is gone across the full original scope — not just that the old payload stopped working."
Wersja skrócona, gdyby czasu było mało — trzy zdania, które i tak zrobią robotę:
„Architecture and trust boundaries first, not features. Profile the cache before sending anything. And work in a way that can't hurt their customers — cache buster, harmless payloads, a purge plan agreed up front."
Jeśli padnie pytanie o ich bug bounty: powiedz, że to legalna ścieżka i że śledzisz takie programy — ale nie udawaj, że testowałeś ich infrastrukturę. Nieautoryzowane testy przed rozmową o pracę są dokładnie tym, czego zespół product security nie chce zobaczyć u kandydata. Twoją wiarygodność buduje to, że wiesz, gdzie przebiega granica autoryzacji.

Quiz do powtórki: przygotowanie.netcuter.duckdns.org · Powodzenia o 11:00! ALLELUJA