Cryptshare Security Measures & Methods

Aus Cryptshare Documentation
Version vom 26. November 2021, 07:09 Uhr von Hartwigr (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu:Navigation, Suche

As a security product, Cryptshare is developed using numerous methods aiming to mitigate and prevent functional issues as well as common security risks like the OWASP Top Ten.

The Cryptshare Server development process, starting with the product design over the development and quality assurance phase is ISO-27001 certified and includes the following measures[1]:

  • Agile development in a defined and self-optimizing Scrum process including quality assurance as a constant part: Developers and members of the QA team work together in an iterative process during Sprints with the goal to discover flaws (in terms of security and quality) at the earliest possible point in the process and before they can get into the final product version. During this phase developers make use of agile methods such as:
    • Test Driven Development (TDD)
    • Pair Programming
  • In addition to the forementioned manual tests during a sprint, developers take care of maintaining automated quality assurance measures such as:
    • Static code analysis
    • Unit Tests
    • Integration Tests
    • Automated UI Tests
  • During release preparation, additional measures are taken in the form of:
    • Regression Tests
    • Vulnerability Scans using the Acunetix vulnerability scanner
    • SSL checks using tools like the services provided by Qualys SSL Labs

Complementary to the measures taken during the development phase, the following internal guidelines exist to assure quick responses to discovered vulnerabilities and to prevent the publication of releases with known vulnerabilities:

  • Library updates in the last phase of the release process to fix discovered vulnerabilities before the official release.
  • Upon discovery of a critical vulnerability in the current release, 14 days internal reaction time to fix the vulnerability and prepare a hotfix release.

Furthermore, regular internal Security Risk Assessments take place to identify possible attack vectors on the product and to identify, prioritize and plan appropriate countermeasures against them.


[1] The development processes for other parts of the product are not ISO 27001 certified. However, they follow the same procedures as described here.