Trusted Application Security Assessment.

A vulnerability assessment looks for known weaknesses, mostly with automated scanners, and produces a list of them. A penetration test goes further: the tester tries to exploit what was found, chains smaller flaws together and abuses the application's logic to show what an attacker could actually reach. Scanners rarely catch broken access control or business logic flaws, so in our assessments they are only a starting point; every finding in the report is confirmed by hand.

A penetration test looks for as many vulnerabilities as possible within a defined scope, such as an application or a network. Red teaming tests the organization as a whole: besides finding weaknesses, it shows whether an attack in progress gets detected and stopped. It pays off once your main applications have been tested and monitoring is in place; before that, a penetration test gives you more for the same effort.

Web applications are tested against the OWASP Web Security Testing Guide (WSTG) and mobile apps against the OWASP Mobile Application Security Testing Guide (MASTG). For APIs, we pair the WSTG with the requirements of the OWASP Application Security Verification Standard (ASVS). For IoT we use the OWASP IoT Security Testing Guide; AI and LLM integrations are checked against the OWASP Top 10 for LLM Applications. Network assessments follow NIST SP 800-115 and the Penetration Testing Execution Standard (PTES). On top of the methodology we add complementary tests, on both the client and the server side, aimed at the most recent classes of vulnerabilities. Wherever the client talks to a back-end, whether it is a web front-end, a mobile app or a desktop application, the assessment also covers those APIs. The testing is done by hand, supported by BeDefended's proprietary tools and by third-party ones, open source and commercial, so the result does not depend on what a single tool can see.

For penetration testing, the team holds OSCP, OSCP+, eCPPT and eJPT (networks and infrastructure), OSWE, GWAPT and eWPT (web applications), OSWP (wireless networks), CRTO (red teaming) and C-AI/MLPen (AI and machine learning systems). The full list, which also covers cloud and secure development, is on our About page.

It depends on what you want to find out. Black box shows what an outsider sees with no credentials. Gray box, with a test account for each user role, is what we usually suggest for applications, since many of the most serious flaws are only reachable after login. White box adds the source code through a secure code review and brings out issues that are hard to spot from the outside, such as backdoors or malicious code.

A report written and signed off by the testers who did the work. It opens with an executive summary for management, then lists each verified finding with its CVSS score, the evidence needed to reproduce it (a working proof of concept wherever the issue is exploitable) and concrete remediation steps. We go through the results with your team and support them while they fix the issues. Once the fixes are in, a retest checks that each issue is closed.

Both come down to scope: how many applications, user roles, features and API endpoints are involved, and on which platforms. A small web application can take a few days, while a large platform with mobile apps and APIs takes longer. After a short scoping call we send a quote with the effort in person-days and agree on the testing window with you, so cost and timeline are clear before we start.

A staging environment that mirrors production is the safer choice, but production can be tested too: we agree on the time windows, leave out destructive tests and ask you to keep a contact person reachable during the test. To start we need the scope (URLs, apps or IP ranges), a test account for each role, API documentation where available and, for mobile apps, the builds to test. Before we start, we sign an NDA and a data processing agreement, and you authorize the testing in writing. If some systems are run by a third party, such as a hosting provider or a SaaS vendor, the provider has to agree as well, unless its published rules already allow testing, as AWS, Azure and Google Cloud do within limits.

It gives you evidence, but a report alone does not make you compliant. NIS2 (Article 21), transposed into Italian law by Legislative Decree 138/2024 (Article 24), requires essential and important entities to have policies and procedures to assess the effectiveness of their cybersecurity risk-management measures, and to handle vulnerabilities in the systems they acquire, develop and maintain. DORA lists penetration testing among the tests that a financial entity's digital operational resilience testing program must provide for, where appropriate (Article 25). PCI DSS calls for internal and external penetration tests at least every 12 months and after any significant change (requirements 11.4.2 and 11.4.3). Our reports are written to be handed to an auditor.