Integrating an Existing Security Analysis Tool in the MEDINA Framework
6 May, 2022
By Immanuel Kunz (FhG)

MEDINA integrates different types of evidence collection tools to enable a comprehensive assessment of a cloud service’s security level. This is important for several reasons: First, security certification catalogs cover different layers including the infrastructure, the application layer, and others. Second, a requirement may be fulfilled on one or more layers. For example, encryption of a sensitive datum may be done either on the infrastructure layer by using the cloud provider’s services or may be done on the application layer, implemented by the CSP’s developers.

Rather than developing all tools from scratch, we want to facilitate an easy integration of existing tools in MEDINA. To that end MEDINA provides a modular framework with a clear data model. One tool we are integrating on the application layer is Codyze. In the following, we describe which steps we took to make this integration possible.

Codyze: A Static Code Analyzer

Codyze is a tool for static analysis of source code. It focuses on finding security vulnerabilities and general compliance violation that occur at the interface with software libraries. Nowadays, software projects rely heavily on third-party software libraries. While libraries simplify development and are the product of the vast experience of their communities, they also pose the challenge of integration. Developers need to understand how to use and more importantly not to use libraries. Standards and guidelines can augment these challenges by requiring adherence to functional and non-functional requirements.

In particular, security-critical functionality such as encryption or secure data communication is often a key requirement in standards such as EUCS and is subject to regularly changing guidelines such as ENISA’s “Algorithms, key size and parameters report 2014” or BSI’s technical guideline “TR-02102 Cryptographic Mechanisms”. At the same time, usage of cryptographic libraries seems difficult and error-prone. Codyze tackles this challenge by analyzing usage of cryptographic libraries, validating correct usage, and certifying adherence to state-of-the art standards and guidelines. To this end, Codyze analyzes source code written in Java and C/C++ and affirms correct usage of cryptographic librarieslike Bouncy Castle for Java and Botan.

To check whether the usage of such security libraries is done correctly, Codyze uses a domain-specific policy language, called MARK. Using MARK, one can define, for example, the key length that is considered secure for an encryption operation. As many of the requirements defined in different certification schema target such security properties, Codyze is a valuable tool for the MEDINA framework. Once the desired policies are defined, it can then scan large source code bases for the specified libraries and their usage in compliance with the MARK-specified rules. Examples of such rules for Bouncy Castle and Botan are available in the GitHub repository of Codyze.

Integrating Codyze with the MEDINA Framework

MEDINA is built as a modular framework that allows to integrate tools at different points. For example, a new tool for evidence collection can reuse the existing Clouditor security assessment tool and simply provide evidences in the evidence data format. Alternatively, it can implement its own security assessment, call out to the Orchestrator component, and provide assessment results directly. Regardless of the specific integration, tools just need to implement the MEDINA data model.

For Codyze we decided to go the direction of providing assessment results and relying on the Orchestrator component to handle the rest. As an existing, standalone tool with a well-defined output format, we found it easier to transform findings from Codyze into the MEDINA data model. Moreover, Codyze already implements an assessment of correct usage patterns for cryptographic libraries. Thus, it was guiding itself towards providing assessment results in the MEDINA data model as well.

We have developed a wrapper that communicates between Codyze and the MEDINA framework. The wrapper takes care of transforming Codyze’s findings into MEDINA assessment results and communicating with the MEDINA components such as the Orchestrator. This wrapper first executes Codyze and collects its findings. Afterwards the wrapper maps findings to MEDINA metrics. Finally, the wrapper generates assessment results of the MEDINA data model and submits them to the Orchestrator for further processing.

One metric, that Codyze can assess, is the TlsCipherSuites metric which defines a set of allowed TLS cipher suites that may be used in a TLS connection. Insecure cipher suites configured in source code would propagate to the final application and would make it easier to compromise it. Thus, it’s essential to detect these problems early during development and prevent the deployment of vulnerable applications. The reported assessment result assists in verifying which applications are compliant with the TlsCipherSuites metric.

As static analysis tool, Codyze can be integrated in Ci/CD pipelines (cf. Figure 1). It acts a compliance and quality gate in a pipeline. It prevents the automatic deployment of application that contain vulnerabilities or non-compliant code. Within MEDINA, Codyze also documents and reports assessment results to allow auditing and automatic certifications.

Figure 1: Architectural overview of how Codyze is used as compliance and quality gate in CI/CD pipelines and integrated with the MEDINA framework.

All in all, we have made an important step forward with the integration of Codyze, since the collection and assessment of evidences from the software layer is an important part of the overall monitoring of any cloud system. We also hope that the architecture we are using now sets the basis for an easy integration of other tools in the future.


[1] Mohammadreza Hazhirpasand, Oscar Nierstrasz and Mohammad Ghafari, “Dazed and Confused: What’s Wrong with Crypto Libraries?,” 2021 18th International Conference on Privacy, Security and Trust (PST), 2021, pp. 1-6, doi: 10.1109/PST52912.2021.9647786

[2] David Lazar, Haogang Chen, Xi Wang, and Nickolai Zeldovich. 2014. Why does cryptographic software fail? a case study and open problems. In Proceedings of 5th Asia-Pacific Workshop on Systems (APSys ’14). Association for Computing Machinery, New York, NY, USA, Article 7, 1–7. https://doi.org/10.1145/2637166.2637237