Porão Security / Platform
Porão BAS.
Autonomous offensive
security.
Our in-house Breach & Attack Simulation platform runs an engagement end to end — and refuses to claim what it did not measure. The difference between finding and proving.
Illustrative example. Always run against authorized scope.
01 / What it is
Not a scanner. A simulated attack that runs on its own.
A typical scanner lists possible flaws and returns "clean" — without telling you what it actually tested. Porão BAS goes further: it simulates the attack end to end and only flags a vulnerability when it can prove it in practice, not when it merely "looks" present. And when something couldn't be tested, it tells you exactly what and why. The result is a report you can trust: no false alarms and no hidden blind spots.
02 / Non-negotiable principles
When design conflicts with a principle, the principle wins.
Five rules decide every architectural choice — and they are what makes each finding defensible in the client review.
P1 · Proof, not reflection
Confirms by what only the target could produce
A parser error, a computed value, a differential against a same-shaped control, measured timing or an out-of-band callback. A payload that merely "shows up in the response" never becomes a finding.
P2 · Honest verdict
capability_off never becomes clean
A disabled confirmation arm, a missing binary or an invalid credential each produce their own line naming what was missing — never a false "clean" that hides a blind spot.
P3 · Layered containment
No layer replaces another
Policy blocking, audited approval, a non-destructive request guard, pacing (OPSEC) and a volume budget operate as independent layers — turning up the aggressiveness of the test never lowers the protection of your environment.
P4 · Suppression ≠ discard
Any decision can be refuted
A downgraded signal stays auditable, with the rule that downgraded it named. Coverage is complete: you know what was tested, what was suppressed and why.
19,000+
Attack vectors
26
In-house techniques
21
API modules
790+
Versioned payloads
5
Possible verdicts
03 / Pipeline
A pipeline in two families.
Head phases run in a fixed order and cannot be skipped. Analysis phases adapt to the target — but reporting and remediation are never optional.
Head
Ordered · non-skippable- 01EnumerationHost consolidation, scope and ownership verification.
- 02SurfaceOrigin discovery, port scanning and surface modeling.
- 03ReconnaissanceProvenance graph and secret → route correlation.
- 04Attack waveThe adaptive offensive round, per host.
Analysis
Adaptive- 05Correlation & qualityGroups signals and measures the confidence of each finding.
- 06ChainingComposes isolated flaws into real attack paths.
- 07Assisted exploitationImpact validation with containment at every step.
- 08Reporting & remediationTechnical, executive and remediation plan. Never optional.
04 / Confirmation
Six ways to prove. None is "the payload showed up".
Each vulnerability class has its own oracle — the signal that tells real execution apart from a mere echo.
01
Parser error
The target reveals it interpreted the payload — not just echoed it.
02
Computed value
The response contains something only the server could have computed.
03
Differential with control
Compared to a same-shaped control with a benign value, against a measured baseline.
04
Measured timing
A delay statistically separated from baseline jitter, not a guess.
05
Out-of-band callback
The target calls us back over our own DNS channel — proof outside the HTTP response.
06
Negative control
If the benign control also matches, it's reflection — and the finding is withheld.
05 / Deliverables
What's left when the run ends.
Every run delivers a report and a remediation plan — never optional. And each artifact has its own failure boundary: losing one never erases the others.
01
Technical report
HTML and PDF, finding by finding, with the reproduction and the oracle that confirmed each one.
02
Executive report
Risk and coverage for decision-makers — including what was not tested and why.
03
coverage.json
One line per (technique, host) pair: executed, variants sent, requests, verdict and reason.
04
Retest scripts
One per confirmed finding, for your team to reproduce and validate the fix.
05
Hashed evidence
SHA-256 integrity on every evidence artifact — what holds the finding up under review.
06
SARIF & suppressions
Plugs into your code pipeline; nothing downgraded is discarded — it all stays auditable.
06 / Who it's for
A standalone service, engaged on its own.
Porão BAS is an independent service — you engage it for what it delivers, with its own scope and proposal.
Use case
Before an audit
An honest read of your surface — with what was tested and what was left out named, no false "clean".
Use case
Recurring coverage
Periodic runs against authorized scope to track how risk evolves between manual engagements.
Use case
Evidence that holds up
Technical and executive reports with proof per finding — the kind that survives your team's review.
Next step
See Porão BAS
against your scope.
Book a demo and we'll show, in your context, the difference between a report you can refute and one that holds up.