Our testing platform

Hiraya

Tagalog for aspiration — the gap between what you believe about a system's security and what's actually true about it. It's also what our testers run on every engagement.

Built in-house

Written and maintained by the same people who use it on client engagements — not licensed from a third party we can't fix.

Human-verified

Every candidate finding is confirmed by a tester before it's reported. Hiraya widens what we can look at; it doesn't decide what's real.

Fifteen categories deep

Covers the same fifteen attack categories in every engagement, from injection to dangling DNS to PII exposure.

Where Hiraya earns its keep

Some engagements need it more than others. It matters most when the scope is too large or too complex for manual testing alone to cover in the timeline.

Complex, multi-role applications

Several user roles with different permissions
Deep authenticated flows a scanner alone can't navigate
Best suited to a graybox engagement

Large, sprawling attack surfaces

Many subdomains, some of them forgotten
Higher risk of dangling DNS and takeover
Hiraya maps the surface before testers go deep

Regulated, data-sensitive environments

Systems holding personal or financial data
Data Privacy Act (RA 10173) exposure in scope
Findings documented to hold up to a compliance review

Hiraya-assisted vs. the alternatives

	Hiraya-assisted testing	Automated scanner alone	Manual-only testing
Every finding human-verified	Yes	No	Yes
Coverage across a large surface	Yes	Yes	Limited by time
Understands business logic & auth flows	Yes	No	Yes
Fixed, reproducible scope & timeline	Yes	Yes	Varies by tester load
False-positive rate in your report	Near zero	High	Low

Testing for ISO 27001 & PCI DSS

If a certification or a QSA is the reason you're testing at all, the report has to hold up to someone else's checklist, not just your own team. Hiraya-assisted engagements are scoped and written to be handed straight to an auditor.

ISO 27001

Annex A.8.8 (Management of technical vulnerabilities) expects regular, documented vulnerability testing feeding into your risk treatment plan — and auditors routinely ask to see a recent, credible penetration test as evidence for it.

Scope & methodology documented against your Statement of Applicability
Severity ratings and remediation tracking auditors can cite directly
Best fit: graybox, run annually or ahead of your surveillance audit

PCI DSS

PCI DSS requires periodic penetration testing of the cardholder data environment, including segmentation testing wherever segmentation is used to reduce scope, plus retesting after significant changes.

Coverage of both external and internal paths into the CDE
Segmentation testing scoped separately from general app testing
Best fit: graybox or whitebox, with the retest step built into every engagement

Tell us your audit date, we'll scope around it

Why we don't ship raw scanner output

We've watched automated username and profile checkers report accounts that didn't exist — a plausible-looking match with nothing real behind it. The fix wasn't a smarter scanner; it was requiring a second, independent check before anything counts as confirmed.

Hiraya carries that same discipline into every VAPT engagement: a candidate finding only becomes a reported finding once a tester has reproduced it. That's slower than trusting the first scan, and it's why our reports don't waste your engineering time chasing phantoms.