Independent penetration test — scope brief
What an independent tester would be asked to attack, ranked by what would be most damaging if wrong. Published so that commissioning a test is a purchasing decision rather than a scoping project.
Nothing on this page is evidence of anything — the whole point is that no independent party has yet tried to break this.
Why this cannot be self-served
Every other gap in the assurance register has been closed by writing code and a test that tries to falsify it. This one cannot be. The value of a penetration test is that the person testing did not build the thing, and no amount of adversarial self-testing substitutes for it.
Our own adversarial suites found real defects — a credential leak from an unauthenticated health endpoint, an SSRF bypass via RFC 6598 space, vendored CVEs invisible to a lock-based scan — which is evidence the discipline works, and is not evidence that an outsider would find nothing.
Two systems, and they need different tests
| ecokure.com | Assurance Runtime | |
|---|---|---|
| What it is | Marketing and evidence site | The deployable enterprise product |
| Runs where | Our hosting | The customer’s own account |
| Priority | Secondary | Primary |
| Test type | Standard web application test | Application + API + tenancy isolation |
A tester who scopes only the website has tested the wrong system. The runtime is what a bank deploys and what an attacker would target.
Priority scope — the Assurance Runtime
Ranked by what would be most damaging if wrong.
HIGHESTTenant isolation
Two tenants, credentials for both supplied. Can tenant A obtain, infer, or influence tenant B’s evidence, control packs, review queue, metering or existence? Our own testing covers the metering and export paths; assume it is incomplete.
3.2Evidence integrity
Can a decision record be altered, replayed, back-dated, or made to verify under a key that did not sign it? Can an entry be inserted into or removed from the chain? Can the independent verifier be made to pass a pack it should reject?
3.3Identity and the two-authority boundary
The reviewer endpoint requires an API key and an OIDC token. Can either be bypassed? Can a service credential resolve an abstention? Can a token from one tenant’s identity provider be made to work against another’s queue? Algorithm confusion, alg: none, kid manipulation, audience and issuer substitution.
3.4The verdict contract
Can a gate be induced to return something outside ALLOW / BLOCK / ABSTAIN, or can an unknown outcome be made to resolve to ALLOW rather than ABSTAIN? An attacker who can turn “I don’t know” into “yes” defeats the product.
3.5Fail-open under stress
Under evidence-store outage, database failure, key unavailability, memory pressure and clock skew: does anything return a verdict that looks attested and is not? STRICT mode is supposed to refuse. Try to make it not refuse.
3.6Supply chain and container
Non-root enforcement, escape from the runtime container, dependency substitution, and whether the image ships anything it should not.
Secondary scope — the website
Standard OWASP-style web application test: injection, XSS, CSRF, session and account handling, access control on /admin/* and /api/*, rate limiting, SSRF via any user-supplied URL, information disclosure through error paths, and the payment and merchandise flows.
Rules of engagement
- Environment: a dedicated instance, not production, seeded with synthetic tenants. We will supply infrastructure-as-code so the tester builds their own.
- Credentials: grey-box. Two tenant API keys, two OIDC identities at different privilege levels, and the source. Withholding source makes the test cheaper and less useful.
- Out of scope: denial of service against shared infrastructure; social engineering of staff; physical; and third-party subprocessors (see the list), which are not ours to authorise.
- Data: synthetic only. If real personal data is encountered, stop and report it — that finding is itself a defect.
- Disclosure: we intend to publish the report’s existence, the finding counts by severity, and the retest outcome. We will not publish exploit detail before remediation.
What we will do with the result
Findings enter the enterprise gap register as capabilities with a state, the same as everything else. Failing evidence is preserved alongside the correction — the register already carries several FAILING artefacts deliberately, because a register showing only passes tells a reader nothing about how hard anyone looked.
A clean report is not the goal. A report that finds nothing either means the test was shallow or the scope was wrong, and we would rather pay for findings than for reassurance.
Deliverables required
- Findings with severity, reproduction steps, and evidence.
- An explicit statement of what was tested and found sound — as valuable as the findings, and usually omitted.
- What was in scope and not reached, and why.
- Retest after remediation.
- A letter of attestation suitable for a customer’s vendor assessment.
Not yet decided
- Vendor. No firm has been approached.
- Budget and timing.
- Whether to pursue CREST/OSCP-credentialled testers specifically — likely yes, since regulated buyers ask.
- Whether the runtime test waits for the AWS target environment to be benchmarked, or runs against the local enterprise-representative lab first.
This brief exists so that if you want an independent test run before you commit, the scope is already written and the rules of engagement are already decided. What is missing is a vendor and a budget line, not a plan.