BlogWissenwertesMastering the Cloud: part II

Mastering the Cloud: part II

Ein Beitrag von Helder Sousa und Benjamin Breitenstein

Introduction

As mentioned in our earlier post (see here), we at communicationX are currently working in application and cloud security domains and in this article, we are going to provide an overview of what we have been doing to solve security related requirements. One of our customers has a complex IT landscape with multiple front-end, back-end and mobile applications that need to be scanned regularly to show vulnerabilities. Together we came up with solutions to scan both applications and infrastructure, enabling teams to have visibility on security issues, so that they can address them as soon as possible. 

It was clear for us that our customer would benefit the most if we could automate security scans and offer the ability to run scans either periodically or on demand. The solution would need to perform: 

  • static application security testing (SAST): verify the source code without running it, find programming errors, coding standard violations and security vulnerabilities. 
  • dynamic application security testing (DAST): analyze the application while running it, to identify bugs, memory problems or performance bottlenecks. 
  • analyze licenses and compliance: show licensing issues and compliance with internal company policies. 
  • penetration testing: name security weaknesses that could be exploited to gain unauthorized access or disrupt operations. 

Following an agile approach, we started by breaking down the problem into smaller pieces, which are represented by the following steps: 

Step 1 Where to perform security scans in the software development lifecycle? 

Figure 1

Figure 1 – Sofware Development Lifecycle

We looked to the SDLC, and we showed primarily three points where security scans should be implemented:

  • Develop (also known as implement or build)  

With developers constantly changing the code base it is important to implement checks directly at earlier stages of development. This brings advantages such as faster feedback and continuous improvement, enabling developers to evaluate the code directly upon commit. On a technical level, SAST should be done directly when committing code to the version control software branch. Developers can then verify the scan results and solve findings before writing added code or moving to peer-review or testing. 

  • Test 

A quality gate focused on the infrastructure is necessary at this stage, allowing container scans and penetration tests to perform before releasing the code to production. Depending on the tool (or scanner) used, this quality gate could also work as a control mechanism to check if all issues from earlier scans were addressed. From a technical point of view, we are performing DAST analysis during the test phase. 

  •  Deploy 

During the time between development and production deployment new vulnerabilities can arise and depending on the criticality, they need to be shown and solved as soon as possible. Code dependencies are often updated, and libraries become deprecated over time, therefore it is important to guarantee that the most updated and/or secure version is deployed.     

Step 2 Evaluate security software 

Our customer had already the following software stack available for security scans:  

Fortify (https://www.opentext.com/products/fortify-static-code-analyzer) 

Fortify is a security application (AppSec) that in our use case is used for:  

  • SAST (Static Application Security Testing) 
  • display findings via Fortify Software Security Center Portal 

 This application can be used for code analysis, finding programming errors or missing security mechanisms in the source code. It has the following components:  

  • scan-engine 
  • central repository to load the results of the scan 
  • web-client, where users can see and work on the issues found 
  • web-API 

Fortify supports a wide range of programming languages (like for example C++) and allows to organize findings per application. Additionally, it supports complex tracing analysis of fields and variables. As the downside is it is difficult to work with multiple code branches because each branch is analyzed independently which can cause the same vulnerability to be reported multiple times.

Pricing: License required.

 

SonarQube (https://www.sonarsource.com)

SonarQube is an open-source platform for continuous inspection of code quality. Under the premise “Clean Code” this tool helps teams to perform code reviews and build code according to best practices, combining code quality and code security. It supports more than 30 programing languages, knows the most development frameworks and IAC Platforms. Key features include:

  • SAST (Static Application Security Testing)
  • Secrets detection
  • web UI, where results from the scans can be checked

For our business case SonarQube was integrated as a linter to prevent long term code deterioration, ensure code quality as well as finding bugs or code duplications.

Pricing: There are several paid editions and one free edition (Community edition).    

 

Mend SCA (https://www.mend.io/sca)

Mend (formerly WhiteSource) has developed Mend SCA (Mend Software Composition Analysis Tool) which we are using for:

  • find vulnerabilities and malicious packages
  • make risk assessment based on CVSS scores
  • check license compliance

Mend provides a Web-app for storing the scan results and continuously scan for new vulnerabilities or policy violations.

Pricing: License required.

 

Trivy (https://trivy.dev/) 

Trivy is an open-source security scanner that for our use case is being used for:  

  • container images scans 
  • filesystem scans 

It can show risks in OS packages, software dependencies, known vulnerabilities, misconfigurations, secrets, or software licenses. It provides a fully correct report of findings and receives frequent updates to its vulnerability database. It also allows export findings in Table format (text format) or Json, meaning that you can integrate it with other observability tools. There is no central UI app or web app to store the scan results and display new findings. 

Pricing: Open source (Apache License 2.0) 

 

OWASP Zap (https://www.zaproxy.org/) 

OWASP ZAP (Zed Attack Proxy) is a powerful open-source web application scanner developed by the Open Web Application Security Project (OWASP) that we are using for:  

  • vulnerability assessments 
  • penetration testing 
  • runtime testing 

The automation framework can be configured with active scan job(s) that simulate attacks to the application. In other words, it performs DAST tests of the application(s). 

This web app scanner is special beneficial in the first stages of development, since it can point out issues resulting from the use of certain web frameworks.  However, its correct configuration is time consuming (like maintaining unit tests) and not easy to archive. We also have seen a high number of false positives in the findings reported. 

Pricing: Open source 

Step 3 Design & Build solution 

We started by making all security tools available in containerized environments using Docker. Building Docker images and storing them in antifactory management software gave us the flexibility to have multiple versions and deploy them in multiple instances if necessary. 

We ensured automatization by building pipelines to run containerized jobs when developers commit the code (or on-demand by executing the pipeline manually). On the development phase it was decided to incorporate security scans in the build pipeline. Directly upon commit the build of the pipeline would:  

Figure 2

Figure 2 – Security scans on the development phase

During the test phase, two different pipelines were built: one for container image scans and another for penetration and DAST tests.   

1) Penetration & DAST testing

Figure 3Figure 3 – DAST scans via pipeline

The pipeline test job will find potential vulnerabilities by running containerized OWASP Zap application to launch known attacks against selected targets (application URLs). The results of the scans are automatic uploaded to the pipeline as artifacts as well as sent to the vulnerability portal for further analysis.

 

2) Container scans:

Figure 4

Figure 4 – Container image scans via pipeline

The pipeline was built in a way to be easily extended for added instances and ran from one single instance. Using SSH it will connect to each instance and search for images (get job). We have decided to export images to a simple storage system to avoid scanning those multiple times. This will also allow to execute scans from one single instance avoiding problems such as insufficient resources in instances with high workloads (scan job). After scanning each image with Trivy the findings are submitted to our internal vulnerabilities portal and/or attached in the pipeline as artifacts (submit job).

Conclusion & future prospects 

SaC (Security as Code) is a key principle of modern software development within DevSecOps frameworks. This means, companies should incorporate security scans into their CI/CD pipelines and implement at least the following security checks:  

  • SAST with data flow tracing
  • DAST
  • check code for readability, maintainability, reliability (following Clean Code principles)
  • SCA capable of creating SBOMs, in order to provide faster reaction to newly discovered vulnerabilities
  • Penetration testing or applying concepts like red teaming

A mixed approach of scanning multiple environments provides the most comprehensive security assessment in preparation for the live system.

We believe that cloud and application security will continue to evolve in the future. We are seeing collaborative version control platforms such as GitHub and Gitlab integrating solutions for container scanning and software composition analysis into their platforms. This will bring seamless integration of security scans to users/developers, providing a starting point for keeping your code secure. However, it is important to mention that such features might only be available for certain pricing tiers, and it is recommended to use multiple tools to avoid gaps where certain vulnerabilities might not be detected.



Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert