Raport de pentest cu AI: de la notițe brute la raportul final

Testarea e partea frumoasă. Raportul e lucrul pentru care plătește clientul și de obicei e scris la finalul angajamentului, de cineva obosit. Ghidul ăsta îți arată cum să folosești Odin v1 ca să transformi notițe brute, output de scanner și capturi de ecran descrise în text într-un raport de pentest curat, gata de predat clientului, fără să cedezi judecata profesională sau secretele clientului.

La ce e bun AI-ul într-un raport de pentest și la ce nu

Un model de limbaj e bun la părțile raportării care țin mai ales de scris: transformă notițe telegrafice în fraze complete, păstrează o structură consecventă pe 30 de finding-uri, scrie un executive summary pe care îl poate urmări și un cititor non-tehnic și redactează recomandări de remediere potrivite cu stack-ul pe care îl descrii.

Nu este însă o sursă de adevăr. N-a văzut ținta. Nu poate confirma că un finding e real, că severitatea ta e corectă sau că un pas de reproducere funcționează. Tratează fiecare draft ca pe prima trecere a unui tester junior: util, rapid și de revizuit.

Asistenții mainstream mai adaugă o problemă. Lipești „un utilizator autentificat poate citi facturile altor tenanți schimbând ID-ul” și unii dintre ei încep să-ți țină predici despre accesul neautorizat în loc să scrie finding-ul. Odin v1 răspunde direct când contextul e un raport pentru un angajament autorizat, adică exact meseria ta. Explicăm de ce contează asta în articolul de lansare.

Înainte ca ceva să plece de pe calculatorul tău: anonimizează

Notițele tale conțin hostname-uri ale clientului, IP-uri interne, nume de utilizator, uneori session token-uri sau hash-uri de parole. Elimină-le înainte să trimiți ceva către orice API.

Un set simplu de reguli acoperă aproape totul:

• Înlocuiește domeniile clientului cu placeholdere precum client.example.com.
• Înlocuiește IP-urile interne și externe cu range-uri de documentație (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) sau cu tokeni ca HOST-A.
• Înlocuiește numele reale de utilizator cu user1, admin1.
• Elimină complet secretele. Un finding despre un token expus are nevoie de tipul și locația token-ului, nu de valoarea lui.
• Păstrează local un fișier de mapare, ca să poți pune la loc valorile reale în documentul final.

Pe InterOdin, prompturile și răspunsurile trimise prin API nu sunt stocate niciodată. Se păstrează doar metadate, precum numărul de tokeni, latența și statusul, pentru facturare, iar serverele sunt în Germania. E un punct de plecare bun, dar nu înlocuiește anonimizarea. Contractul cu clientul stabilește ce date au voie să iasă din mediul angajamentului, așa că verifică-l mai întâi.

Structura de raport spre care țintești

Majoritatea rapoartelor pentru clienți au același schelet. Dă-i modelului structura asta explicit, ca fiecare draft să iasă în aceeași formă:

Fiecare bloc de finding ar trebui să aibă: titlu, severitate, vector CVSS v4, active afectate, descriere, impact, pași de reproducere, dovezi, remediere, referințe.

Un template de prompt pentru un finding

Iată un set realist de notițe brute dintr-un test autorizat pe o aplicație web (deja anonimizate):

target: app.client.example.com (in scope per RoE section 2)GET /api/v2/invoices/{id} returns invoice JSONlogged in as user1 (tenant A), changed id 10442 -> 10443got invoice for tenant B, includes name, billing address, line itemsids sequential, tried 50 in a row, all returned 200no rate limit seenburp request saved as req-17.txtscreenshot 17: tenant B invoice in user1 session

Și un prompt care le transformă într-un finding:

You are writing one finding for a penetration test report for an authorizedengagement. Use only the facts in the notes. If something is missing, write[NEEDS TESTER INPUT] instead of guessing.
Output Markdown with these headings: Title, Severity, CVSS v4.0 vector,Affected assets, Description, Impact, Reproduction steps, Evidence,Remediation, References.
Rules:- Propose a CVSS v4.0 base vector and explain each metric choice in one line.- Reproduction steps must be numbered and reproducible by the client's  developers in their own test environment.- Remediation must be specific to the endpoint, then general.- Neutral, factual tone. No blame.
Notes:<paste notes>

Ce primești înapoi: un titlu în genul „Insecure Direct Object Reference in Invoice API Exposes Other Tenants' Data”, o descriere a verificării de autorizare la nivel de obiect care lipsește, un paragraf de impact despre expunerea între tenanți a datelor personale și de facturare, pași numerotați care folosesc două conturi de test din tenanți diferiți și o remediere care cere verificarea pe server a apartenenței la tenant pentru fiecare căutare de obiect, cu mențiunea că trecerea la ID-uri aleatorii nu e, singură, o remediere. Referințele includ de obicei OWASP API Security Top 10 (API1, Broken Object Level Authorization) și CWE-639.

Pentru vector, te poți aștepta la ceva de genul:

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

cu câte o linie pentru fiecare metrică, cu justificarea ei, de exemplu „PR:L pentru că e nevoie de un cont autentificat obișnuit”. Calculează întotdeauna singur scorul final în calculatorul oficial FIRST CVSS v4.0 și verifică fiecare metrică față de ce ai observat efectiv. Modelul poate raționa despre metrici, dar scorul din raport e responsabilitatea ta.

Un script Python care redactează un finding din notițe

Scriptul citește un fișier de notițe, aplică o mică mapare de anonimizare, îl trimite la odin-v1 și scrie un draft în Markdown. Folosește SDK-ul oficial OpenAI, îndreptat spre URL-ul de bază InterOdin (vezi ghidul pentru OpenAI SDK).

import osimport reimport sysfrom pathlib import Path
from openai import OpenAI
SYSTEM = """You write findings for penetration test reports on authorizedengagements. Use only facts from the notes. Mark gaps as [NEEDS TESTER INPUT].Output Markdown with headings: Title, Severity, CVSS v4.0 vector, Affectedassets, Description, Impact, Reproduction steps, Evidence, Remediation,References. Explain each CVSS metric choice in one line."""
# Local mapping: real value -> placeholder. Keep this file out of the report.REDACTIONS = {    "portal.realclient.internal": "app.client.example.com",    "10.20.30.40": "192.0.2.10",    "j.doe": "user1",}
TOKEN_PATTERN = re.compile(r"(eyJ[\w-]+\.[\w-]+\.[\w-]+)|(Bearer\s+\S+)")

def redact(text: str) -> str:    for real, placeholder in REDACTIONS.items():        text = text.replace(real, placeholder)    return TOKEN_PATTERN.sub("[REDACTED-TOKEN]", text)

def main(notes_path: str) -> None:    notes = redact(Path(notes_path).read_text(encoding="utf-8"))
    client = OpenAI(        base_url="https://api.interodin.com/v1",        api_key=os.environ["INTERODIN_API_KEY"],    )    resp = client.chat.completions.create(        model="odin-v1",        messages=[            {"role": "system", "content": SYSTEM},            {"role": "user", "content": f"Notes:\n{notes}"},        ],    )
    out = Path(notes_path).with_suffix(".finding.md")    out.write_text(resp.choices[0].message.content, encoding="utf-8")    print(f"Draft written to {out}")

if __name__ == "__main__":    main(sys.argv[1])

Rulează-l pentru fiecare finding: python draft_finding.py notes/finding-17.txt. Înainte de prima rulare reală, afișează o dată în terminal textul anonimizat, ca să vezi exact ce se va trimite.

Output de scanner și capturi de ecran

Exporturile din scannere sunt zgomotoase. În loc să lipești un raport întreg, filtrează-l mai întâi (doar plugin ID-urile sau template-urile pe care le-ai confirmat manual), apoi cere modelului să grupeze problemele înrudite. Zece linii de tip „missing security header” își au locul de obicei într-un singur finding de severitate scăzută, cu o listă de hosturi afectate, nu în zece finding-uri.

Odin acceptă doar text, deci nu poți încărca imagini sau PDF-uri. Pentru raportare merge foarte bine așa: descrie fiecare captură de ecran într-un rând sau două în notițe („captura 17: factura tenantului B vizibilă în sesiunea lui user1, se văd numărul facturii și adresa”). Modelul face apoi referire la dovadă după nume, iar tu pui singur imaginile reale, anonimizate, în documentul final.

Pentru angajamente mari, odin-v1 are o fereastră de context de 1.000.000 de tokeni, așa că poți trimite toate finding-urile anonimizate deodată când scrii executive summary-ul. Pentru sarcini rapide și repetitive, cum ar fi normalizarea titlurilor de finding-uri sau reformatarea listelor de referințe, odin-flash e mai rapid și mai ieftin.

Executive summary și planul de remediere

După ce finding-urile au fost revizuite, generează rezumatul pornind de la finding-uri, nu de la notițele brute:

Below are the reviewed findings from an authorized external and webapplication test. Write an executive summary for non-technical management:max 300 words, overall risk rating, the three issues that matter most and whyin business terms, and a prioritized next-steps list. Do not add findings.

Apoi cere un plan de remediere care grupează remedierile după responsabil (dezvoltare, infrastructură, identitate) și după efort. Clienții acționează mult mai des pe baza unui plan de remediere decât a unui tabel de severități.

Note de retest

După perioada de remediere, adaugă pentru fiecare finding un scurt bloc de retest: data, ce s-a retestat, rezultatul (remediat, parțial remediat, neremediat) și dovezile. Un prompt util este: „Iată finding-ul original și notițele mele de retest. Scrie un bloc de status al retestului de cel mult 80 de cuvinte și semnalează orice nepotrivire între pașii de reproducere originali și ce am retestat eu.” Ultima parte prinde retesturile care, fără să-și dea cineva seama, au testat altceva.

Checklist de revizuire înainte de predare

• Fiecare finding a fost confirmat de un tester uman, cu dovezi.
• Fiecare scor CVSS a fost calculat în calculatorul oficial.
• Nu a mai rămas niciun marcaj [NEEDS TESTER INPUT].
• Placeholderele au fost înlocuite cu valorile reale doar în documentul final.
• Nimic din afara scope-ului convenit nu apare în raport.

Dacă automatizezi mai mult, de exemplu cu un script care asamblează raportul complet din fișierele de finding-uri, articolul nostru despre tooling de securitate construit cu Claude Code pe Odin parcurge exact un astfel de proiect. Testerilor mai noi, care își construiesc abilitățile în laboratoare, le-ar putea plăcea și exersarea de CTF-uri cu un antrenor AI.

Primii pași

Creează o cheie API în consolă, seteaz-o ca INTERODIN_API_KEY și urmează quickstart-ul. Ține fiecare angajament în limitele scope-ului scris și ale regulilor de angajament, precum și ale Politicii de utilizare acceptabile.