Senior-only security · web, API, cloud, Kubernetes
Senior engineers with 10+ years of production experience test your web apps, APIs, cloud and Kubernetes the way an attacker would. You get a prioritised report that developers and management can both act on. If you want, we then fix the findings in code and infrastructure and verify every fix with a re-test.
What is a pentest
Penetration testing services put your application, API or infrastructure through an authorised, pre-agreed attack. The goal is not the longest possible list of issues but the vulnerabilities a real attacker could exploit – from broken access control, SQL injection and XSS to a misconfigured cloud account – together with a clear picture of what each one means for your data and your business.
A typical pentest ends with a PDF report and a list of recommendations. That is exactly where the real work starts: findings have to be understood, prioritised, fixed and verified. At Megu, that work is done by the same senior engineers who build and run production software every day, including cloud, Kubernetes and CI/CD. So we can design fixes that fit your architecture, and ship them ourselves.
If your product is still being built, start earlier. A secure architecture review catches flaws in authentication design, customer data separation or secrets management before they turn into code. Changing a design is usually far cheaper than fixing a system that is already running in production.
Services
We test the applications, APIs and infrastructure your business runs on. Order a single service or combine them into one engagement with remediation and a verification re-test.
Hands-on testing of customer portals, admin panels, online stores and internal systems against the current OWASP Top 10. We focus on what scanners miss: access control between roles and customers, authentication and sessions, SQL injection, XSS, file uploads and business logic flaws such as bypassing approvals or discount rules.
We test REST APIs, webhooks, partner integrations and mobile app backends against the OWASP API Security Top 10. Can one user read another user's records (BOLA)? Change fields they should not touch? Bypass token authorisation or hammer endpoints that have no rate limits? We find out, with proof.
We map what is exposed to the internet and what an attacker gains after the first foothold. In AWS, GCP and Azure we review IAM permissions, public storage and services, network rules and secrets management; in Kubernetes, RBAC, network policies and workload isolation; in CI/CD, leaked credentials and the risk of tampered builds.
A white-box review of source code and configuration: authorisation logic, password and token handling, cryptography, input validation, vulnerable dependencies and secrets committed to the repository. A source-level security review often uncovers issues an external test cannot reach within the agreed time, and fits well before a launch or a funding round.
If you are designing or building a product, we review the architecture before flaws reach the code: data flows, authentication and authorisation, tenant isolation in multi-tenant systems, secrets management, AI assistants' access to internal data, logging and backups. You get concrete design changes with the reasoning behind them, not a generic checklist.
This is where we differ from a typical pentest. Findings are fixed by the same senior engineers who build production software every day: pull requests to your repository, Terraform and Kubernetes changes, cloud hardening and CI/CD checks so the issue does not come back. Finally, we verify every fix with a re-test.
Typical scenarios
Typical situations where a penetration test or security audit pays off most. We shape each test around what is genuinely critical for your organisation.
B2B SaaS
A large prospect sends a security questionnaire and wants to see the application tested before signing. We test the app and API, including data separation between tenants, fix the findings and hand you a re-test report showing the status of each fix, ready to share with the customer.
E-commerce
Attackers go after customer accounts, orders and discount mechanics. We test account takeover, access to other customers' orders via IDs in the URL, price and basket manipulation, the payment gateway integration and the admin panel, which is often the weakest point.
Transport and logistics
Logistics systems share shipment, pricing and route data with many parties. Building our own transport management platform taught us the typical risks: guessable tracking links, carriers who can see other companies' orders, weakly protected TMS and ERP integrations and driver app backends.
Finance and accounting
In systems holding financial and personal data, what matters is who can see what and who can approve what. We test role separation, approval workflows, exports and audit logs, and deliver the results as technical evidence for your security controls, for example if NIS2 applies to your organisation.
IT operations and cloud
Migrations often leave overly broad IAM permissions, public storage buckets, credentials in CI/CD variables or dashboards open to the internet. We review the cloud accounts, cluster and pipelines and fix the issues in infrastructure as code (Terraform, Pulumi) so they do not return with the next deployment.
Startups
The product is about to take payments and sign up its first customers, but authentication, permissions and secrets management were built under time pressure. We focus the test on sign-in, password reset, account separation, the payment flow and public APIs, fix critical findings before launch and confirm the fixes with a re-test. A broader review of the codebase for investors is covered by our technical due diligence.
Process
Five steps with clear deliverables and no black boxes. You know what we are testing at every stage, and critical findings are reported immediately rather than saved for the final report.
On a free first call we agree the goals, systems, environments and approach (black, grey or white box). Then we set the rules of engagement: testing windows, test accounts, what is out of scope and who to call if we find something critical. NDA on request.
We combine automated tooling with hands-on testing by a senior engineer. Automation covers breadth; a human finds logic flaws, chains vulnerabilities and proves real impact. We prefer a staging or test environment and touch production only under the agreed rules.
Every finding comes with severity, business impact, reproduction steps and a concrete, developer-ready recommendation. An executive summary serves management, the technical section serves engineers. We walk through the results together and agree the order of fixes.
We deliver fixes straight into your repository and infrastructure, or work through them with your team and help wherever needed. The code stays yours, and we work transparently through pull requests and code review.
Once the fixes are in, we re-test every finding and check that nothing broke and no new issue was introduced. You receive an updated report with the status of each finding and advice on what to keep checking continuously in CI/CD.
Why Megu
A report alone does not remove risk. The engineers who tested your system know the context of every finding and ship the fix in code and infrastructure, with no hand-off between a security firm and a development vendor.
Every engineer has 10+ years of production experience, and the company has 15+ years and 100+ production projects behind it. You talk directly to the people doing the testing, not to a sales rep or an anonymous freelancer.
We design and run cloud on AWS, GCP and Azure, Kubernetes, Terraform and CI/CD ourselves. We know where real deployments go wrong, so our recommendations are realistic for your team rather than theoretical.
We are based in Košice, Slovakia, under EU jurisdiction, handle data in line with GDPR and sign an NDA on request. We work in English, German or Slovak with clients in Slovakia, Czechia, Austria, Germany and across the EU.
Technology
We test the technologies we work with every day. We know their common misconfigurations, which is why we can not only describe the findings but fix them too.
FAQ
Penetration testing is an authorised, simulated attack in which security engineers look for vulnerabilities in an application, API or infrastructure and verify whether they can actually be exploited. Unlike an automated scan, a pentest proves impact: what an attacker could read, change or take over. It runs within an agreed scope and rules of engagement, usually on a test environment. The output is a report with severity ratings and recommendations, and with Megu, the option to have the findings fixed.
The cost of a penetration test depends on its scope, so we quote each engagement individually after a short scoping call rather than from a price list. The main drivers are the number of applications and API endpoints, user roles, the authentication setup (SSO, multi-factor), the approach (black, grey or white box), the number of environments and whether you want remediation and a re-test. For SMBs and startups we can narrow the scope to the riskiest areas. The first call is free and we reply within 24 hours.
How long a penetration test takes depends on scope: a smaller web application can typically be tested in a matter of days, while a large system with many APIs and cloud infrastructure can take several weeks. You get a concrete schedule together with the scope proposal. Preparation (access and test accounts), reporting and any remediation and re-test come on top of the testing itself. Critical findings are reported to you immediately rather than waiting for the final report.
A common baseline is at least once a year and after every significant change, such as a new API, a payment integration or a cloud migration. Systems that change frequently or handle sensitive data benefit from more frequent testing, ideally combined with automated security checks in the CI/CD pipeline between tests. Compliance frameworks and customer contracts may also set their own frequency. We help you plan a testing rhythm that matches how fast your product changes.
Vulnerability scanning is an automated search for known weaknesses, whereas penetration testing is hands-on work by an engineer who verifies, chains and exploits findings like a real attacker. A scanner or a DAST tool will spot an outdated library or a missing security header, but usually misses business logic flaws, such as one customer seeing another customer's orders. A compliance audit, in turn, reviews processes and documentation rather than attacking systems. Regular scanning in CI/CD complements a pentest; it does not replace it.
For most web applications and APIs we recommend grey box, meaning testing with regular user accounts and basic documentation, because it offers the best balance of realism and coverage. Black box simulates an outside attacker with no information: realistic, but part of the effort goes on reconnaissance. White box, with access to source code and architecture, finds the most, especially authorisation and logic flaws, and suits critical systems or pre-investment reviews. We recommend the approach on the scoping call based on what you need to prove.
Not explicitly for most organisations: NIS2 does not name penetration testing as such, but it requires organisations in scope to have policies and procedures for assessing the effectiveness of their cybersecurity measures, and a penetration test is one of the most direct technical ways to evidence that. Other frameworks and sector rules may set their own testing requirements. Whether and how these rules apply to you is a question for your legal adviser or auditor; we provide neither legal advice nor certification. We deliver the testing, a report you can use as evidence and the fixes.
After a penetration test, prioritise the findings by severity and business impact, fix them and verify the fixes with a re-test. Start with critical and high findings that are exploitable from the internet, then plan the rest into your backlog with clear owners. Look for root causes too: if one endpoint lacked an authorisation check, others may as well. With Megu you do not have to do this alone, because the engineers who tested your system can fix the findings in code and infrastructure and run the re-test.
Contact
Tell us what you need tested. We reply within 24 hours, and on a free scoping call we propose the scope, approach and plan, including remediation of findings. In English, German or Slovak.
