Skip to content
Talk to an engineer

Security Assessment & Penetration TestingA finding you cannot reproduce is an opinion.

Most penetration test reports are a scanner export with a logo on it. They arrive as a list of CVEs ranked by a number that was calculated without any knowledge of your environment, and the engineering team reasonably ignores them. We test the way an attacker does: chained, against your actual architecture, aimed at an outcome you would care about. Every finding comes with the exact steps to reproduce it, the observed impact, and the change that closes it.

Talk about this

Commitments

Every finding, with the steps to prove it
Reproducible
Findings shown as a path, not a list
Chained
Fixes verified inside the engagement
Retested

Cybersecurity Assessment

This is a fixed-price assessment of what an outsider can see about your business: your websites, exposed systems, leaked passwords, and public information about your staff. You get a report that ranks each finding by risk and explains how to fix it.

It comes in two versions:

Standard
A search over everything your business exposes publicly, with nothing attacked
Intrusive
Active testing of those same systems, which needs your written permission and a scope agreed first, so your operations are not disrupted

When would I want this?

  • You want an initial assessment to set your security baseline
  • You want a routine checkup of your security posture
  • You want to confirm that a fix actually worked
  • You want to meet a regulatory requirement
  • You want to check that your team follows your security standards

Penetration Test

We test your systems the way an attacker would, within limits we agree on in writing before testing starts. Depending on your needs, we test a single application, your network, or the whole business. You get a report on each vulnerability: how we found it, how serious it is, and how to fix it.

A test can cover any of three areas:

Network
Inside and outside your network: databases, sign-in points and network equipment
Social engineering
Targeted emails, phone calls and online research aimed at information that should stay private
Physical
At your location: getting past locks and access controls, and on-site reconnaissance

When would I want this?

  • You want to see the ways an attacker could get in today
  • You want a routine, in-depth test of your security
  • You want to confirm that a fix actually worked
  • You want to meet a regulatory requirement
  • You want to check that your team follows your security standards

Sounds like

You might recognize one of these.

  • The pen test came back with sixty findings and we do not know what to fix first.

  • A customer requires an annual third-party test before they will sign.

  • We ship a device and we have no idea what happens if someone opens it.

  • We built an AI feature and we are not sure what a hostile prompt can make it do.

  • We would like to know whether our detection would actually catch this.

What you get

What lands on your side, and stays there.

  • Findings with exact reproduction steps, evidence and observed impact
  • Severity rated against your environment, not a generic CVSS base score
  • Attack narrative showing how findings chain into an outcome that matters
  • Detection gap analysis mapped to MITRE ATT&CK techniques
  • Specific remediation guidance, at the code or configuration level
  • Free retest of remediated findings within the engagement window
  • An executive summary an executive can actually act on

Shapes

How this usually runs.

  1. External security assessment

    3 business days

    A fixed-price read of what an attacker sees before they touch anything: your certificates and how they are served, the security headers your site returns, the DNS records that decide whether a stranger can send mail in your name, and whether there is any way to report a problem to you. Every finding arrives with what it lets somebody do, the steps to confirm it yourself, and a call to walk through the list. The findings are yours to keep and to hand to whoever fixes them, whether or not you go further with us.

  2. Scoped penetration test

    1–3 weeks

    One application, network or cloud environment, tested manually against a defined scope, with the report and a walkthrough session. Retest included.

  3. Adversary emulation

    3–6 weeks

    Objective-based testing against a stated goal, with an agreed rules-of-engagement document and a purple-team debrief with your defenders.

What this includes

The work, specifically.

Not every engagement needs all of it. This is the range we cover and what each part is actually for.

  • Application and API penetration testing

    Manual testing against OWASP ASVS and the API Top 10: authentication and session handling, the whole authorization matrix, injection, business-logic abuse, file upload, SSRF and the multi-step flows scanners never reach because they cannot hold state.

  • Network, cloud and identity assessment

    External and internal network testing, cloud configuration and IAM privilege-escalation paths, and the identity plane specifically, because in most breaches the interesting move is not an exploit, it is a credential used somewhere it should not have worked.

  • Adversary emulation and purple teaming

    Named techniques mapped to MITRE ATT&CK, executed against your environment with your defenders watching, so the deliverable is a detection gap analysis rather than a trophy. We have written custom implants and command-and-control tooling for exactly this purpose, which means we are not limited to what an off-the-shelf framework already has a signature for.

  • AI and LLM red teaming

    Prompt injection through retrieved content, tool-invocation abuse, data exfiltration through the model’s context, and authorization that was implemented in a system prompt rather than in code. Assessed as an application security problem, because that is what it is.

  • Continuous vulnerability research

    We hunt on public disclosure programs between engagements, against systems whose owners did not scope the test for us and will push back on anything we cannot prove. That is where the discipline on this page comes from: authorization checked before the first packet, findings ruled out on the target’s threat model rather than written up anyway, and a validator that will not let a draft claim something no captured request supports. Being plain about what that record is: the harness produces leads rather than findings, and most of what it has surfaced was low severity, already known, or ruled out on the threat model. The discipline is the transferable part, not the trophy case.

Tooling

What we build it with.

No tool here was picked because it was new. Where we do reach for something novel, it is in one place, for a stated reason, and it is written down.

Application
  • Burp Suite
  • OWASP ASVS
  • Semgrep
  • Custom tooling
Network & cloud
  • Nmap
  • Nessus
  • Metasploit
  • Hashcat
  • Aircrack-ng
Emulation
  • MITRE ATT&CK
  • Custom implants and C2
  • Elastic
  • Sysmon

Questions

Security testing, honestly.

  • A scanner tells you which versions are old. It cannot chain three low-severity issues into an account takeover, it cannot reason about your business logic, and it cannot tell the difference between a vulnerable library you import and a vulnerable library you actually call. Scanning is a control you should run continuously and automatically. Testing is what tells you whether the controls work.

  • Not without asking. The rules of engagement are written before anything starts and they name the destructive classes explicitly: denial of service, data modification, credential lockout, social engineering of named staff, and the deployment of persistence or implants, including how every artifact is removed afterward. Anything in those categories happens only against a non-production environment or with written go-ahead, and there is a documented stop procedure with a phone number attached.

  • Yes. An attestation letter suitable to share with a customer or an auditor, describing scope, dates, methodology and remediation status, without disclosing the findings themselves.

  • For breadth, yes: enumeration, correlating one host’s behavior against another, reading more source than a person can in the time. Never for the claim itself. Disclosure programs are currently drowning in AI-written reports that cite functions which do not exist and debugger output that was never captured, and two well-known open-source projects have curtailed their bounty programs over it. Our own research harness enforces the counter-rule mechanically: a finding cannot be written up unless every endpoint, parameter and response in it maps to a request we actually sent. You will get fewer findings from us than from a tool, and you will not spend your engineers’ time disproving them.

  • We will, but we will also tell you that an independent tester is worth more. Testing your own work has a real blind spot: you inherit the assumptions you made while building it. For anything where the assurance is the point, use someone else, and we are happy to be the someone else for a system another firm delivered.

  • Probably not yet, and the honest sequence is disclosure policy first, paid bounty later. A vulnerability disclosure policy costs you a published page, a security.txt and a commitment to answer; it converts the finder who was going to tell you anyway from a legal risk into a report. A bounty adds money, and money buys volume rather than quality. The question that decides it is not budget, it is whether you can absorb the queue: an engineer who can reproduce a claim, a path to a fix with an owner and a date, and someone willing to write “not a vulnerability” and defend it. If a report today would sit unanswered for three weeks, a bounty will make that visible to the entire researcher community rather than fix it.

Further reading

What we think about this, at length.

All posts

Often paired with

Sources

  1. 1.OWASP Top 10:2025 (opens in a new tab), OWASP Foundation
  2. 2.RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (opens in a new tab), IETF,
  3. 3.BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy (opens in a new tab), CISA,
  4. 4.The CERT Guide to Coordinated Vulnerability Disclosure (opens in a new tab), CERT/CC, Carnegie Mellon Software Engineering Institute
  5. 5.The end of the curl bug-bounty (opens in a new tab), Daniel Stenberg (curl),
  6. 6.Due to AI: Bug bounty programs without rewards, now also at Nextcloud (opens in a new tab), heise online,

Next step

Tell us what’s breaking.

Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether the thing you’re worried about is actually your biggest risk.

Talk to an engineerSee how we work
Reply
A person replies, not a sequence: within one business day, from someone who would be on the engagement.