Applications, APIs and mobile
Authentication and authorization, session handling, input validation, business logic and data exposure, exercised against a running instance. REST, GraphQL and SOAP services, plus iOS and Android clients.
What AXUM SEC does
AXUM SEC is an offensive security company. We test the applications, APIs, networks and cloud infrastructure an organisation depends on — using the techniques an attacker would, inside an agreed scope — and report what we find with the evidence to reproduce it and the guidance to fix it.
The work runs either as scoped engagements delivered by our own testers, or continuously through a managed bug bounty programme with our researcher community. Our AI engine, AXUMIS, assists both, and one platform holds scoping, submissions, triage, remediation and reporting.
At a glance
Services
Web, API, mobile, network and source code testing; attack surface management; security awareness training.
Delivery
Expert-led engagements (PTaaS), a managed bug bounty programme, or a vulnerability disclosure route.
Output
Ranked findings with severity, proof of concept and remediation guidance, plus a retest once fixes ship.
Coverage
What we test
Scanners and code review find part of it. The rest — broken authorization between services, logic flaws, misconfigured storage, credentials in the wrong place — only shows up when someone exercises the running system.
Infrastructure and cloud
External and internal networks, exposed services, segmentation and identity configuration, on your own hardware or inside a cloud account. Privilege escalation and lateral movement included.
Source code
Manual review supported by tooling, tracing how untrusted input actually reaches a sink. Findings are tied to the file, the line, and the commit that introduced them.
Attack surface
Continuous discovery of the domains, hosts, certificates and services you expose, and an alert when something appears that nobody remembers deploying.
Pipeline
How a finding moves
A report is only useful if it is reproducible, rated, owned and closed. The platform enforces that sequence from the moment something is submitted.
Submitted
A tester or researcher reports it through the platform with reproduction steps and supporting evidence.
- Structured report: Affected asset, request and response, impact, and the steps to reproduce.
- Evidence attached: Screenshots, logs or a proof-of-concept script, captured before anything is changed.
- Scope checked: Reports that fall outside the agreed scope are flagged rather than actioned.
Validated
We reproduce the finding ourselves before it reaches you, and rate how serious it is.
- Reproduced independently: Anything we cannot reproduce is rejected with a written reason.
- Deduplicated: Repeat reports are linked to the original instead of being counted again.
- Severity assigned: Rated on a scale agreed at scoping, based on what it exposes and what it can reach.
Remediated
Your team fixes it, and the platform tracks each item until it is actually resolved.
- Guidance per finding: A concrete fix in the stack you run, with the trade-offs called out.
- Owner and status: Each item is assigned, dated, and visible to whoever has to report on it.
- Questions answered: Your engineers can ask the tester directly in the report thread.
Verified
We retest the fix and close the finding only when the issue no longer reproduces.
- Retest recorded: The result is attached to the original finding, pass or fail.
- Reopened if partial: A fix that only narrows the issue goes back with a note on what still works.
- Closure report: A dated record of what was found, fixed and verified, ready for an auditor or customer.
Delivery
Expert-led, crowd-sourced, or a disclosure channel
They cover different ground rather than competing. Most organisations start with one and add another as coverage needs grow.
Continuous, named team
Expert-led (PTaaS)
A named team of testers works through an agreed scope on a cadence you choose, reporting validated findings as they are confirmed rather than holding everything back to the end.
The right model when you have a defined application or estate to cover, or you need evidence for a customer, insurer or auditor.
How expert-led testing worksContinuous, community
Managed bug bounty
Our researcher community tests across your estate continuously and is paid only for submissions we validate as genuine. We run the triage queue, the dispute process and the payouts.
The right model for breadth, and for coverage between engagements — including the assets nobody thought to put in scope.
How the bounty model worksAlways-on intake
Vulnerability disclosure
A published channel with a safe-harbour statement, so a researcher who finds something reports it to you instead of posting it publicly.
A sensible first step, or a permanent companion to either model. It closes the gap where no intake channel exists today.
How disclosure programmes workAXUMIS, our AI engine
AXUMIS runs as a first pass across all three models: reading repositories and probing systems at machine speed, surfacing candidate findings, and cutting the time between shipping code and hearing about it. A human tester confirms every result before it reaches you, so the queue stays signal rather than noise.
How the AI engine fits inWorking together
How we work with your team
Findings go to the engineers who will fix them and to the people who report on them. The platform is built for both, and the process is set up so nothing depends on us being in the room.
- Every finding opens with its business impact in one paragraph, before the technical detail and the raw request and response.
- Severity ratings follow a scale agreed at scoping, so results line up with whatever framework you already report against.
- You keep control of scope, timing and visibility: what we may test, when we may test it, and who inside the company sees the results.
- Nothing is published or shared with a third party without your written agreement. Confidential is the default.
- Findings land in the platform, assignable to owners and trackable to closure, rather than in a document nobody opens twice.
- If you would rather not run the programme internally, we can operate it and report to you on a schedule.
What we need from you
Someone who can authorise the scope, someone who can answer questions about how a system is meant to behave, and someone who owns the remediation. Access to a staging or test environment where one exists, and a named contact for anything urgent.
Start to finish
How an engagement runs
The same five stages, whether we are testing a single application or running a programme all year.
- 01
Scoping
We agree the assets in scope, what is explicitly excluded, the testing window, and the commercial terms.
- 02
Rules of engagement
Written authorisation, emergency contacts, out-of-hours arrangements, and the escalation path if a critical finding turns up.
- 03
Testing
Manual testing supported by tooling, with validated findings reported as they are confirmed rather than held back to the end.
- 04
Reporting and remediation
The ranked report arrives with owners assignable in the platform, and your team works through it with us available to explain any item.
- 05
Verification and closure
We retest every fix, record the result against the finding, and issue a closure report you can hand to an auditor or a customer.
The deliverable
What you receive
A ranked, reproducible report your engineers can work from and your leadership can sign off.
- Prioritised findings with severity ratings
- A reproducible proof of concept for each finding
- Affected assets named explicitly, not implied
- Remediation guidance in the stack you run
- A retest of every fix, recorded against the finding
- Platform access for your team, with role-based visibility
Our commitments
What we never do
We are asking for access to the systems your business depends on. These limits are not negotiable, and they are written into every engagement.
- We never test outside the agreed scope, or without written authorisation.
- We never use real customer data where a synthetic example proves the same point.
- We never sell, share or reuse your data or your findings.
- We never publish a finding without your agreement — not even after it is fixed.
- We never leave an environment in a changed state. If a test turns risky, we stop and tell you.
Questions
Frequently asked questions
If your question is not answered here, ask us directly.
How do you decide severity?
Each finding is rated on a scale agreed at scoping, based on what it exposes and what an attacker could reach from it. The rating travels with the finding through remediation, so you can report against it without re-scoring anything yourself.
How do you handle false positives and duplicates?
Every submission is reproduced before it reaches you. Anything we cannot reproduce is rejected with a written reason, duplicate reports are linked to the original rather than counted twice, and only validated findings are billed.
What do you need from us before testing starts?
A scope: domains, IP ranges, applications and repositories. Plus written authorisation, a testing window, and an emergency contact. A staging environment is welcome where one exists, but production testing is normal and handled carefully.
Can you test production without disrupting it?
Yes, and that is the default. Rate limits, excluded endpoints and quiet-hours windows are agreed up front, and destructive testing is off unless you specifically ask for it. If something looks risky mid-test, we stop and contact you before continuing.
Do you sign NDAs?
Yes, before scope or architecture is shared, and before any researcher enters a programme. If you have your own agreement, we can work under that instead.
How do you handle personally identifiable information?
We work from the minimum evidence needed to prove a finding, redact records where a redacted version is just as convincing, and delete any test data we created once the finding is closed.
What happens after the fixes ship?
We retest, record the result against each finding, and issue a closure report. From there you can keep continuous cover running, or come back for a scheduled retest when the next major release lands.
Do you work alongside an in-house security team?
Often. We can take a defined slice of the work — one application, a quarter of testing, or the triage queue itself — and hand results back into your existing process, tooling and ticket flow.
Explore
Go deeper
The detail behind each part of the work.
Web, API, network, mobile and source code testing, plus awareness training and support.
PTaaS: continuous testing with a named team on a scope you agree.
Managed bug bounty: reward structure, triage and dispute handling.
Publish a safe-harbour policy and receive reports through a proper channel.
AXUMIS: machine-speed code analysis and triage, confirmed by a human.
The testers and researchers who do the work.
Not sure where to start?
Tell us what you run and what matters most to protect. We will come back with a proposed scope, what it involves, and what it costs.
Confidential by default. Nothing is tested without written authorisation.