Fixed quotes, no surprises

One call, then a written quote. The work runs in agreed steps, and everything we hand over comes with evidence.

How a test runs

Whatever we test, it runs the same way.

  1. Learn

    Scoping

    One call on targets, rules and dates. Then a fixed quote, in writing.

    Fixed quote

  2. Learn

    Recon

    Hosts, endpoints, roles, versions and the third-party code you lean on.

    Attack surface map

  3. Learn

    Threat model

    Who would attack this, and where would they push first?

    Test plan

  4. Attack

    Testing and exploitation

    Hands-on, inside the agreed dates. Criticals reach you straight away.

    Confirmed findings

  5. Close

    Report

    Severity, evidence, reproduction steps and a fix for every finding.

    The report

  6. Close

    Remediation

    Your engineers fix. We answer their questions.

    Answers while you fix

  7. Close

    Retest

    Free, inside an agreed window. Each fix confirmed closed.

    Free retest

Who does what

  1. Learn the system

    Scoping, recon, threat model

    From you

    • The scope: URLs, apps, contracts, IP ranges or repos
    • Test accounts for each role
    • Dates, and anything off limits

    From us

    • Rules of engagement, in writing
    • A test plan
  2. Attack it

    Testing and exploitation

    From you

    • A contact who answers quickly
    • A heads-up about deploys or outages

    From us

    • Hands-on testing, inside the agreed dates
    • Nothing destructive without your written go-ahead
  3. Close it out

    Report, remediation, retest

    From you

    • Fixes for what you choose to address
    • A note when they’re live

    From us

    • The report, with evidence and a fix for every finding
    • Answers while your engineers fix

How a build runs

You see working software early and often, and nothing ships before we’ve attacked it.

What we build
  1. Shape

    Discovery

    The problem, the people, the constraints, and what release one must do.

    Scope and a fixed quote

  2. Shape

    Design

    Screens, data model and architecture. Threat model before code.

    Design and threat model

  3. BuildRepeats

    Iterations

    Short cycles, each ending in a build you can try.

    Working builds to try

  4. Build

    Security review

    We attack the build like a pentest and fix what we find before release.

    Findings fixed before launch

  5. Run

    Launch

    Config, secrets, backups and monitoring, against a checklist.

    Checklist signed off

  6. Run

    Support

    Bug fixes and patches for the period in the quote.

    Agreed support window

How we rate severity

A CVSS score in 3.1 or 4.0, whichever your team uses, plus a plain rating. If your setup makes a finding worse or milder, we adjust it and say why.

  1. Severity: Info

    Score 0.0

    CVSS: None

    Not a vulnerability on its own. Hardening advice.

    Grouped as recommendations

  2. Severity: Low

    Score 0.1 to 3.9

    CVSS: Low

    Hard to exploit or little to gain. Fix it when you’re nearby.

    Listed with a short fix

  3. Severity: Medium

    Score 4.0 to 6.9

    CVSS: Medium

    Real, but it needs extra steps, access or timing.

    Fix in your normal release cycle

  4. Severity: High

    Score 7.0 to 8.9

    CVSS: High

    Serious damage with one condition, like a signed-in account.

    Top of the report, fix first

  5. Severity: Critical

    Score 9.0 to 10.0

    CVSS: Critical

    Easy and serious. Account or server takeover, or everyone’s data.

    Fix before anything else

One finding, two versions

One sample finding, scored in CVSS 3.1 and in CVSS 4.0.

See the finding

Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

  • Base6.5Severity: Medium
  • Environmental, CR:H8.3Severity: High
AV:NAttack vector
Network
AC:LAttack complexity
Low
PR:LPrivileges required
Low
UI:NUser interaction
None
S:UScope
Unchanged
C:HConfidentiality
High
I:NIntegrity
None
A:NAvailability
None

Invoices hold personal data, so Confidentiality Requirement goes to High (CR:H) and the score rises to 8.3.

Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

  • CVSS-B7.1Severity: High
AV:NAttack vector
Network
AC:LAttack complexity
Low
AT:NAttack requirements
None
PR:LPrivileges required
Low
UI:NUser interaction
None
VC:HConfidentiality, this system
High
VI:NIntegrity, this system
None
VA:NAvailability, this system
None
SC:NConfidentiality, other systems
None
SI:NIntegrity, other systems
None
SA:NAvailability, other systems
None

Same finding, 7.1 in CVSS 4.0 and 6.5 in 3.1. So every finding shows its vector, and anyone can check the maths.

What a finding looks like

V-017Severity: HighClosed after retestExample

Any signed-in user can download any customer’s invoice

Target
app.example.com, billing API
Category
Broken object level authorisation, OWASP API Security Top 10 API1:2023
CVSS 3.1
6.5 base, 8.3 environmental
CVSS 4.0
7.1 (CVSS-B)

Summary

The invoice endpoint checks that you’re signed in, and never checks that the invoice is yours. Numbers are sequential, so one account can walk through every customer’s invoices.

Impact

Any registered user can read every customer’s name, billing address and tax ID. Sign-up is free, so the bar is one email address.

Rated High, above the 6.5 base, because the data is personal and the ID is guessable.

  1. Sign in as test customer A and download your own invoice, number 10421.
  2. Repeat the request with the next number, 10422, which belongs to test customer B.
  3. The server returns customer B’s invoice.
GET /api/v2/invoices/10422/pdf HTTP/1.1
Host: app.example.com
Authorization: Bearer 
HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Disposition: attachment; filename="INV-10422.pdf"

The PDF shows test customer B’s name and billing address (screenshot in the appendix, redacted: ).

Look the invoice up through the signed-in customer, and answer 404 for anyone else’s.

-- before
SELECT * FROM invoices WHERE id = :id;
-- after
SELECT * FROM invoices WHERE id = :id AND customer_id = :session_customer;

Add a test that asks for another customer’s invoice and expects 404. Random IDs are a second layer at best.

Retest passed

Other customers’ invoices now return 404, with or without /pdf, and the new test runs in the pipeline. Closed in the updated report.

What you share stays with us

Testing means seeing things nobody else should. We treat it that way.

  • NDA on request

    Signed before you share anything sensitive, even before the scoping call.

  • Only what’s in scope

    The targets and dates in the rules of engagement. Nothing else, never outside the window.

  • Encrypted report delivery

    Encrypted files. The password travels by a different channel.

  • Test data deleted

    Test data, credentials and evidence deleted at the end. Confirmed in writing if you ask.

  • Your findings stay yours

    Never published or discussed without your written permission.

Before you ask

vulnaratechnologies@gmail.com
How much does a security test cost?

It depends on what we test and how deep. After a scoping call you get a fixed written quote, and that is the price.

Do you test production systems?

We prefer a staging copy with realistic data. If it has to be production, we agree in writing what we may touch, and avoid anything that could affect your users.

Is it just automated scanning?

No. Tools cover ground. Every finding is confirmed by hand before it goes in the report.

Can you fix what you find?

Yes, if you want. We can make the fixes ourselves, or work beside your engineers while they do.

Tell us what to break. Or what to build.

Send the scope and your deadline, and we’ll set up a call.