How to read a pentest report without panicking.

The first time someone hands you a 100-page security report, the natural reaction is to look at the red CRITICAL badge, count the findings, and panic. Don't. The report is structured to be read, not survived. This guide walks through every section in order, explains what each one is telling you, and shows you how to turn the document into a triage list and a fix plan. By the end you'll be able to open a Violet report like a grocery list.

01. Before you open the report

Violet just ran your application through a six-phase automated assessment. It started with external reconnaissance — scanning ports, discovering subdomains, fingerprinting frameworks. Then it mapped the attack surface: every endpoint, every auth boundary, every parameter that accepts input. In the analysis phase, five parallel agents hunted specific vulnerability classes — injection, XSS, authentication, authorization, and SSRF. The exploitation phase attempted to prove each candidate finding is real and reproducible. Finally, a reporting agent synthesized everything into the document you're holding. Nothing in the report is theoretical. If it's there, Violet tried to exploit it.

This report is written for three different readers. Engineers need the proof-of-concept steps and the fix code — they're the ones making the changes. Buyers — CTOs, heads of security, product managers — need the business-impact summary and the count of show-stoppers. Auditors and compliance reviewers need the scope statement and the methodology. The report is structured so all three can extract what they need without reading sections meant for someone else.

02. The executive summary

The executive summary is the first real page after the cover. It's designed to be readable in under three minutes. Every claim in it is backed by a specific finding later in the report. It contains four things: a two-sentence description of what was tested and how, the headline finding counts broken out by severity, a one-paragraph business-impact narrative written in plain English, and an "immediate action required" block when something is critical.

The headline numbers tell you something before you read a single finding. Mostly criticals means your fundamentals are broken — authentication, session management, input validation, or all three. Mostly mediums and lows means the basics are solid but the edges are sharp. An even spread across all severity levels usually means an immature codebase that hasn't had a systematic security pass. Eight criticals and nine highs, like in the sample above, means you have a structural problem, not a one-off oversight.

The business-impact paragraph is where the report tells you what an attacker would actually do with these findings — not what they could theoretically do, but what a real attacker would do in the first thirty minutes. Read this carefully. It is calibrated to your specific application, your data model, your user base. If the impact paragraph reads like it could apply to any web app, that's a flag — the analysis upstream missed something application-specific.

03. Methodology & scope

Methodology

The methodology section tells you how Violet tested. The most important distinction is whether the assessment was black-box or source-connected. Black-box means Violet only had access to the live running application — the same access a real external attacker would have. Source-connected means Violet also had read access to your source repository, which lets the analysis find vulnerabilities that only show up in code review, like hardcoded secrets, insecure defaults, or logic flaws that don't produce visible errors at runtime. The methodology page also lists the external tools used (nmap for port scanning, subfinder for subdomain enumeration, whatweb for technology fingerprinting) and the exact start and end timestamps for the assessment window.

Scope

The scope page is the canonical record of what Violet was allowed to test. It lists the target URL, whether source code review was enabled, how authentication was configured (black-box unauthenticated, agent-initiated login, or a configured credential recipe), and any explicit exclusions — paths or features that were deliberately left out of scope. Read the scope page even if you wrote the scan config yourself. It's the authoritative record. Anything not listed is not in scope. If a finding you expected to see isn't in the report, the scope page is the first place to check — it may simply have been excluded.

04. Risk overview

The risk overview page contains the risk matrix — a grid that plots every finding along two axes. The vertical axis is Impact: how much damage the vulnerability causes if exploited — data exposure, account takeover, service disruption. The horizontal axis is Likelihood: how easy it is to exploit given real-world prerequisites. A finding that's trivially exploitable from the public internet with no account required sits in a different position than one that requires admin credentials on an internal network.

The top-left cell — high impact, high likelihood — is the danger zone. It maps to the critical findings that are reachable from the open internet, require no authentication, and cause serious damage. Fix everything in that cell first, regardless of any other consideration. A finding in the high-impact, low-likelihood cell is still serious but you have time — these are typically vulnerabilities locked behind admin authentication, allowlisted networks, or feature flags. They matter, but they won't be exploited before your next sprint.

Empty cells are signal too. A zero in the bottom-left (low impact, high likelihood) tells you Violet didn't find any trivially exploitable low-stakes bugs — usually a good sign that your app has mature defenses against the easy stuff, like missing headers and information disclosure. Concentration in one cell is different from findings spread evenly. Sixteen findings in one cell means you have a class-of-bug problem. Sixteen findings spread across the matrix means you have a coverage problem. The fixes you need are completely different.

05. Observation notes

Observation notes are structured commentary organized by security domain. There are six domains, and every assessment produces at least one note per domain — even if no findings were recorded there. Here's what each domain actually covers.

• Authentication — Can someone log in as a user they shouldn't be? This covers password policy, session token generation, MFA bypasses, brute-force protection, and password reset flows. If authentication is broken, everything else is moot.
• Authorization — Once someone is logged in, can they do or see things they shouldn't? This covers IDOR (Insecure Direct Object Reference — accessing another user's data by changing an ID in the URL), privilege escalation, and role bypass. Authorization bugs are the most common finding in mature applications because they're hard to catch with automated scanning alone.
• Data Validation & Injection — Does the app check what users send before using it? This covers SQL injection, OS command injection, XML external entity attacks, and path traversal. When input gets interpreted as code, the attacker controls the code.
• XSS (Cross-Site Scripting) — Can someone inject JavaScript that runs in another user's browser? Stored XSS persists in the database and executes for every user who views the affected page. Reflected XSS lives in a URL and executes only when the victim clicks it. DOM-based XSS happens entirely in the browser without touching the server.
• Session Management — Are session cookies issued, stored, and expired safely? This covers the Secure and HttpOnly flags, SameSite policy, session token entropy, session fixation, and token invalidation after logout.
• Business Logic — Does your application's actual workflow have abusable holes that exist only because of how your specific features are designed? Examples include buying items at a negative price to gain credits, skipping steps in a multi-stage process, or exploiting race conditions in payment flows. These are often the highest-impact findings and the ones hardest to find with automated tools.

Each observation note ends with a Recommendation callout — a short remediation block. Read it even if you skip the narrative above. The recommendation tells your engineers exactly what control is missing and what the industry standard is for adding it.

06. Findings summary

The findings summary is a single table that lists every confirmed finding. Each row gives you: a finding number, the title, the category, the severity, the CVSS score (more on that in Appendix A), impact level, likelihood level, confidence, and current status. This table is the master triage board. Spend five minutes here before opening any individual finding.

The Confidence column is the one most people miss. Violet only marks a finding "Confirmed" when the exploitation phase produced a reproducible proof — it ran the payload, captured the response, and verified the result. Every finding in a Violet report defaults to Confirmed. If you ever see a different confidence status, investigate before scheduling the fix — the recommendation may need to be validated manually first.

The table is a multi-purpose triage tool. Sort by CVSS descending and you have a priority order for the engineering team. Sort by category and you can route whole sections to specific teams — all injection findings go to the backend team, all auth findings go to the platform team. Sort by status and you can see what's already been addressed in prior sprints versus what's net new.

07. Anatomy of a finding

Every finding follows the same eight-part structure. Once you know the structure, you can read any finding in under three minutes. Here's finding #1 from the sample report:

1. Header. The chips across the top are the bottom line. Read them left to right: severity badge, CVSS number, impact level, likelihood level, status. Before you read a word of description, the header tells you whether this is a drop-everything finding or a schedule-for-next-sprint finding.

2. Description. One paragraph explaining what the bug is, where it lives in the codebase, and how it works mechanically. Written for engineers, but non-technical readers can usually extract enough to understand the attack surface.

3. Proof of concept. The exact reproduction steps. This is not a theoretical description — it's a recipe. Real curl commands, real payloads, real parameter names from your application. Anyone on your engineering team should be able to follow these steps and reproduce the finding in a staging environment.

4. Evidence. The captured output proving the PoC worked. Usually a request/response pair — the exact HTTP request Violet sent and the response that proves exploitation succeeded. This is the difference between "this might be vulnerable" and "this is definitely vulnerable."

5. Impact. What an attacker can actually do with this finding, calibrated to your application. For the SQLi above: complete unauthenticated read access to the users table, including password hashes, email addresses, and session tokens. Not "the database could be read" — what data, from where, with what attacker access level.

6. Likelihood. What prerequisites the attacker needs. No account? A regular user account? Admin? Must they be on your internal network? The likelihood rating tells you how many real-world attackers could plausibly execute this. A 9.8 CVSS with no prerequisites means every automated scanner on the internet is a threat.

7. Recommendation. Root cause first, then fix code, then additional hardening, then verification steps. This is the section your engineers need. The fix code is real — it shows the parameterized query, the prepared statement, the sanitized output. The verification steps at the end tell you exactly how to confirm the fix worked.

8. References. OWASP cheatsheets, the relevant CWE entry, and any vendor documentation specific to your framework. These are calibrated to the finding, not generic. The OWASP SQL Injection Prevention Cheatsheet link in this finding is more useful than a Google search.

# VULNERABLE: f-string lets username inject SQL
query = f"SELECT * FROM users WHERE username = '{username}'"
user = db.execute(query).fetchone()

# SECURE: parameterized query prevents injection
user = db.execute(
  "SELECT * FROM users WHERE username = ?",
  (username,)
).fetchone()

08. Severity vs urgency

Severity is a property of the finding. Urgency is a property of your week.

Severity describes how bad a vulnerability would be if exploited — how much access it grants, how much data it exposes, how much damage it does. A CRITICAL badge means a class of bug that does serious, typically irreversible damage if an attacker gets there. A MEDIUM badge means real damage but bounded scope — limited data exposure, limited blast radius, or limited attacker access required. The badge is calibrated to the bug's technical characteristics, not to your deployment context.

Urgency is different. Urgency is what you actually have to act on given your specific situation. A CRITICAL finding locked behind a two-factor admin console on an internal VPN is less urgent than a MEDIUM finding on the public signup form that the entire internet can reach right now. Urgency factors in reachability, active threat intelligence, current sprint capacity, and deployment risk. Severity doesn't know any of that.

Here's a concrete example. Violet finds a stored XSS bug in your internal admin dashboard — accessible only to employees behind SSO. CVSS 8.1, rated HIGH. Violet also finds a reflected XSS bug in the public password reset form — no authentication required. CVSS 6.1, rated MEDIUM. Which one do you fix first? The medium. The password reset form is reachable by every phishing campaign targeting your users right now. The admin dashboard XSS requires a compromised employee account to exploit, which is a separate, harder problem. Schedule the admin XSS for next sprint. Fix the password reset form today.

Sort findings by severity. Schedule them by urgency.

09. Triage on Monday morning

You have 12 new findings and 45 minutes before standup. You don't have time to read the full report. Here's the sort that gets your team moving without missing anything critical.

1. Anything CRITICAL that's reachable from the public internet with no authentication — fix today. Not this sprint. Today. Assign it before standup ends.
2. Anything touching authentication, authorization, or payment flows — page the relevant team lead before standup regardless of severity. These categories are where business logic bugs hide.
3. Anything that spans multiple teams — don't assign it to one person. Schedule a 30-minute alignment meeting before the next sprint planning.
4. Anything in a public-facing input field that's currently unvalidated — high-priority ticket for the current sprint, not the next one.
5. Everything else — default-priority ticket, triage during the week when you've had time to read the individual findings properly.

When in doubt, sort by reachability before sorting by severity. A critical bug nobody can reach is a low-urgency finding. A medium bug on your highest-traffic endpoint is a high-urgency finding. Reachability is the variable severity doesn't tell you.

10. Fix, mitigate, or accept

Every finding has exactly three legitimate end states. Understanding the difference matters because teams that blur them end up with stale open tickets that no one trusts.

Fix means you changed the code so the vulnerability no longer exists. The parameterized query replaced the f-string. The output encoding replaced the raw HTML render. The fix is the root cause addressed, not a workaround around it. You re-ran the PoC from the report and it failed. The finding gets marked Fixed.

Mitigate means you added a control that reduces the likelihood or impact of the vulnerability without fixing the root cause. A WAF rule that blocks the specific payload. An IP allowlist that restricts who can reach the endpoint. A feature flag that disables the vulnerable feature until the fix is ready. Mitigations are valid — sometimes they're the only move you have before the next release window. But they're temporary. Mark the finding Mitigated, not Fixed, and schedule the real fix.

Accept means you've decided the risk is tolerable given your threat model and you're not going to fix or mitigate it right now. This is a first-class action. Teams that refuse to ever formally accept any risk end up with a pile of "open forever" tickets that train engineers to ignore the security queue entirely. The accept decision must include a one-paragraph written rationale and a re-evaluation date. "We'll revisit this in Q3 when we rebuild the admin panel" is a valid accept rationale. "Low priority" is not.

11. Remediation roadmap & SLAs

The remediation roadmap section at the back of the report maps every finding to a recommended remediation timeline based on its severity. These aren't arbitrary deadlines — they're calibrated to real-world attacker dwell times and the window organizations typically have before exploitation in the wild begins for findings at each severity level.

The 24-hour clock on criticals starts when you receive the report, not when you read it. If the report landed in your inbox on Friday afternoon, that critical needs to be addressed by Saturday afternoon. Drop in-flight work. This isn't a policy suggestion — it reflects how fast automated exploitation frameworks can pick up new vulnerabilities once they're known.

These timelines are forecasts, not commitments carved in stone. They're useful because they give the next person to read this report — your CTO, your auditor, your next-quarter self — a clear expectation of what state things should be in. If you're going to slip a deadline, update the Status column in the remediation roadmap with the new expected date and a short reason. Silent slippage destroys the report's usefulness as a living document.

12. Closing a finding honestly

The temptation is to mark a finding closed when the engineering ticket closes. Resist it. The honest test for a finding is not "did we ship a fix?" — it's "can I re-run the proof of concept from the report and watch it fail?" Those are different questions. Code gets shipped that doesn't actually fix the root cause. Parameterized queries get added to the wrong query. WAF rules get deployed to the wrong environment. The PoC is your ground truth.

• Re-ran the PoC and it failed cleanly in the secure direction? Mark it Fixed.
• Added a control that reduces risk but didn't fix the root cause? Mark it Mitigated and add a target date for the real fix.
• Decided the risk is acceptable given your current threat model? Mark it Accepted with a written rationale and a re-evaluation date.

You haven't fixed a finding until you've re-run the verification and watched it fail in the secure direction.

13. Sharing the report

Not everyone needs the full report. Different audiences need different cuts, and sharing the wrong cut causes two kinds of problems: information overload for leadership or insufficient context for engineers.

• Engineers — full PDF, every finding. They need the exact PoC steps, the fix code in the recommendation, and the verification recipe at the end. Don't summarize for them.
• Leadership — executive summary and risk matrix only. They need the headline numbers, the business-impact paragraph, and the immediate action required callout. A 100-page PDF in an executive's inbox generates one of two outcomes: ignored or misread.
• Customers or auditors — executive summary and scope page, with specific endpoints redacted if your customer is in a competitive relationship with one of your other customers. When in doubt, redact the technical details and preserve the summary.

The full PDF contains exact endpoint paths, sample payloads, request/response pairs, and working exploit code. Treat it like internal source code. Don't paste it in a public Slack channel. Don't email it without confirming who else is on the chain. Don't store it in a shared folder with broad read access. The report is a capability document for fixing your application — it's also a capability document for anyone who wants to attack it.

Appendix A · Glossary

Security reports use a lot of jargon. These are the terms you'll encounter most often in a Violet report, with definitions that don't require a computer science degree.

Appendix B · Further reading

Each section of this overview has a dedicated deep-dive guide with more detail, worked examples, and printable cheatsheets. Start with whichever chapter your report made most relevant.

1. Severity vs urgency — The standalone triage manifesto. Three worked examples showing how the same severity rating maps to completely different urgency decisions depending on deployment context and attacker reachability.
2. Anatomy of a finding — One finding dissected end to end. The Description, PoC, Evidence, Impact, Likelihood, Recommendation, and Verification chain explained step by step against the real SQLi finding from the Chirpy assessment.
3. CVSS, demystified — How to read a CVSS vector string in plain English. What each component means, why two 9.8s can require completely different responses, and when to trust the number versus when to override it with your own context.
4. Triage on Monday morning — The full 45-minute standup-to-tickets playbook, with a printable cheatsheet your team can pin to the sprint board for every new report.
5. Remediation SLAs — The 24h / 7d / 30d / 90d framework as a decision tool. How to apply it, when to override it, and how to use it to write credible security commitments to customers and auditors.