Security.txt and reporting channel
Use the published security.txt file and the existing security contact for vulnerability reporting or coordination.
Security program, disclosure policy, and evidence model
This page explains how Eresus handles security reporting, responsible disclosure, pentest methodology, AI security validation, and evidence-first deliverables without decorative trust claims.
Coordinated disclosure by default
We prefer responsible disclosure, timeline alignment, and evidence handling that does not increase downstream risk.
Offensive validation methodology
Web, API, cloud, identity, and external attack paths are scoped around exploitability, business impact, and remediation clarity.
AI and MCP testing model
We validate prompts, agents, MCP servers, tool boundaries, model intake, RAG leakage, and release-risk decisions with adversarial workflows.
What a report contains
Every deliverable is built around proof-of-exploit, impact, remediation direction, retest notes, and executive-readable closure guidance.
What you can verify publicly
Advisories, press references, release notes, open-source artifacts, and dated research writing remain the public proof system.
Report anatomy
Sample report anatomy
Instead of publishing a fake sample badge, we show the layers buyers and engineers should expect in a real deliverable.
01
Scope and rules of engagement
02
Attack narrative and reproduction path
03
Business impact and exploitability summary
04
Developer remediation guidance
05
Retest notes and closure state
Public references
Public proof stays in the main motion.
Press, advisories, release notes, and security.txt are treated as direct trust signals instead of decorative marketing surface.