en
Support
Status
Shop
Commissioned
RedTeam Pentesting GmbH
Time frame
Summer 2025
We will publish the results of the penetration test by RedTeam, as well as the findings and reactions of SerNet and the verinice Team, shortly after the test's completion
Pentests and Quality Assurance
The verinice team relies on test-driven software development to ensure the highest quality standards. Our development processes include tests for both the frontend and the backend.
An important part of our security strategy is regular penetration testing (pentests), which also includes the hosting platform. These tests are designed to identify potential vulnerabilities and fix them before they can be exploited. The results of the pentests are incorporated into our continuous improvement processes, constantly enhancing the security of our platform.
Vulnerability assessment
We emphasize the importance of responsible security testing. Therefore, we ask that tests be carried out under defined conditions – our security policy contains our guidelines for the acceptable execution of tests.
Accessibility
We also place great emphasis on usability and accessibility. In the future, we will carry out tests in these areas. verinice should be user-friendly and accessible to everyone.
Talk to us! Use the verinice forum or write to us at verinice@sernet.de. We are happy to answer questions about our security measures.
2023
Commissioned
RedTeam Pentesting GmbH
Time frame
February 2023
Overall assessment of the RedTeam
"The penetration test by verinice.veo comes to a positive result. Only very few vulnerabilities and anomalies could be uncovered. In the core system, there is only one anomaly: in the reporting area, it is possible to call up an endpoint without any authentication. However, the returned data is so general and not customer-specific that the behaviour does not pose a risk and is merely inconsistent and unexpected. All other vulnerabilities and irregularities were uncovered outside of the core system in external, connected systems. [...]
Overall, the tested system is secure and meets the requirements for the intended use and the data that will be managed with it. The vulnerabilities and irregularities uncovered should presumably be easy to address in the short term, in order to further increase the already high level of security."
Findings and reactions of SerNet
- Missing authorisation when accessing main user accounts
Risk: low
Status: Accessing the URL now requires a registered shop account to which the subscription is assigned, so it has been fixed.
- Information disclosure of user account email addresses
Risk: low
Status: Error messages for existing email addresses have been changed in line with the pentesters' advice.
- Client-side protection against changing user names
Risk: information only
Status: Change to the Keycloak configuration to prevent user names from being changed.
- Missing authentication for reports
Risk: Info only
Status: No action required. The fact that the available report templates can be queried does not pose a risk. These can be accessed in the same way via the public source code repository and are not confidential.
2021
Commissioned
Cure53, Dr.-Ing. M. Heiderich
Time frame
December 2021
Findings by Cure53
‘’The Cure53 team achieved excellent coverage of the WP1 to WP3 area items, identifying a total of eight vulnerabilities. Of these, two were categorised as security vulnerabilities and six as general weaknesses with less potential for exploitation. None of the discovered issues are critical or high severity, with the highest severity assigned being ‘medium’. This demonstrates that the SerNet team exercises care in their web and application security processes. While the application itself is very robust, most of the issues involve HTTP headers and could allow an attacker to prepare or execute an exploit."
SerNet's response
This first penetration test was carried out against an early development version to detect problems in the security architecture at an early stage. All identified vulnerabilities were fixed, largely through configuration changing the CSP, customising the HTTP headers, etc. Removing the ‘unsafe-inline’ directive proved more complex due to the open-source components used in the web UI, which contained inline Javascript. These were ultimately also eliminated by making our own modifications.
