Code Security: The 4C’s Of Cloud-Native Security – Part 4

In this part of the article series on the 4C's of cloud-native security, we will take a closer look at code security. We will briefly inspect why code security is essential, why it should be addressed from the beginning, and why trends such as shift-left security are important aspects of overall security considerations.

In diesem Artikel:

Requirements, architectures, and runtime environments continuously increase the overall complexity of applications. Both programming languages and frameworks evolve rapidly to address those challenges and maintain developer productivity without making developers write vulnerable code. However, even using the most recent frameworks does not protect you and your team from introducing massive vulnerabilities by unintentionally producing insecure code. Hopefully, no one produces insecure code by intention.

Often, authors of insecure code don’t know about vectors they introduce with a particular code section or a newly crafted API endpoint.

Those unintended security vectors must be discovered, discussed, and eliminated before deploying the malicious code to production environments. Traditionally, organizations implemented security gates that every release of an application must pass to find its way to the production environment.

In the context of cloud-native applications, organizations should think about their processes and security gates again. Securing source code late in application lifecycle management may come at a very high cost.

That’s why we see trends like shift-left security becoming more and more popular in our industry. Shift-left security puts the developer more in focus.

Developers should have robust tooling to scan and analyze their code. This allows developers to verify if the created code meets regulatory compliance and security requirements already the inner-loop. Additionally, adopting shift-left security will enable developers to address security concerns immediately and “stay in the zone” (the unintentionally malicious feature is still on top of the developers’ minds).

The developer does not have to do a “context-switch” or zone-out, which means she can address the security concerns while implementing the feature.
In the end, this speeds up the overall development process and reduces costs compared to iterating overall features of a particular release and fixing a huge list of security concerns late in the application lifecycle. When we look at code security, numerous tools are available. We can group those tools into the following categories:

  • Static Application Security Testing (SAST): Also known as white-box testing. SAST tools analyze the code of your application
  • Dynamic Application Security Testing (DAST): Also known as black-box testing. DAST tools analyze your application from the outside.
  • Interactive Application Security Testing (IAST): With IAST tools, you typically instrument the system under test to gather metrics from the running application and enrich it with insights collected by the collector integrated into your application.

For the scope of this article, we will jump into Static Application Security Testing (SAST). In my opinion, it is the first category of code security tools every development team should address and add corresponding tools and products to their tool belt.


We already learned that SAST tools scan your application’s source code for known anti-patterns, code smells, and patterns that may lead to additional attack surfaces.

SAST tools do so by checking every line of source code against vast lists of rules (some vendors call them catalogs). If we look at a single rule, it might look trivial, or you may think it would find code smells instead of actual vulnerabilities or security vectors. However, having your code checked against all those rules can and will increase the overall security of your code. And assist you and your team in authoring more secure and robust code.

For demonstration purposes, we will now look at SonarQube. SonarQube is one of the most popular and mature SAST solutions. Consult the official SonarQube website to spot the differences between available editions and possible integrations with your ALM suites and VCS.

For now, we’ll use the open-source Community Edition, which we can quickly run in a Docker container for testing purposes. We also need some code to run an analysis on. You can clone our sample repository from here on GitHub. Having the repository cloned, let’s spin up a SonarQube container to get our code analyzed:

					# pull SonarQube image
docker pull sonarqube:latest

# start SonarQube
docker run -d --name sonarqube-dev -p 9000:9000 -p 9092:9092 sonarqube:latest

Consult the container logs to see when SonarQube has finished initialization (docker log sonarqube-dev -f). Fire up your browser and navigate to http://localhost:9000 and log in with default credentials (admin:admin). From within the SonarQube portal, create a new project. Once you’ve created the project, you can generate an authentication token by setting up a local analysis, as shown in the following animation:

As you can see, SonarQube provides detailed instructions on installing the scanner and executing a code analysis. Follow the instructions and run a scan within the cloned repository:

					# install Scanner as global tool
dotnet tool install --global dotnet-sonarscanner

# start scanner
dotnet sonarscanner begin /k:"MinimalApi" /"http://localhost:9000" /d:sonar.login="<YOUR_TOKEN>"

# build the application
dotnet build

# stop scanner
dotnet sonarscanner end /d:sonar.login="<YOUR_TOKEN>"

When you stop the scanner, move back to the SonarQube portal, it should reload within a few seconds and display the code analysis results as shown here:

SonarQube does a great job analyzing complex projects and providing accountable actions based on its findings. You’ve to arrange SonarQube settings a bit according to your needs. False-positive findings are one of the most significant disadvantages when it comes to SAST. It may need some time and tinkering to get the proper configuration in place.

As you can see, developers can quickly scan their code locally before pushing changes to VCS.

Dependency Analysis

Another essential aspect modern SAST tools address is supply chain security. If you’re a .NET developer, all the dependencies of your projects are listed in the .csproj file; if you’re a JavaScript developer, package.json is your single point of truth,… almost all modern languages explicitly track dependencies in more or less the same way.

You could manually scan those files, detect outdated dependencies or take it one step further and watch all the downstream repositories for new vulnerabilities being discovered in your dependencies. However, achieving all this manually has some disadvantages:

  • doing it manually means there will be exceptions, and things will be forgotten
  • diving through all dependencies and their dependencies is way too time-consuming
  • these investigations must be synchronized in the team (think of your co-worker who is working on a dedicated feature branch)

With a proper SAST tool in place, you get all of this in no time. Vendors extend their SAST tools and dependency checking features continuously. For years now, you’ve been able to have your SAST tool create pull requests instantly when a dependency is updated.

If you’re using GitHub for storing your source code, GitHub’s Dependabot is by far the most straightforward and most obvious choice to implement supply-chain security.

Dependency analysis is enabled on all public GitHub repos by default and accessible via the Dependency graph.

You can activate even more advanced features using the settings page of your GitHub account or your GitHub organization. Currently, Dependabot offers the following optional features:

Without any configuration, Dependabot will create dedicated pull requests for outdated dependencies, as shown in the following figure:

Although Dependabot scans for outdated and vulnerable dependencies automatically, you can also integrate it in your custom GitHub Actions. Consult this guide provided by GitHub to dive deeper and learn how to integrate Dependabot in your GitHub Actions.


Code Security is a vast topic. Numerous vendors provide tools addressing different security testing categories. Generally, competition is a good thing. However, I found it cumbersome to mix and match devices from other vendors to address all concerns.

Nevertheless, organizations must invest in secreting their intellectual properties. Adopting shift-left security and equipping developers with proper tools will pay off in the long run.

Mehr Artikel zu Cloud Native

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Newsletter Anmeldung
Diese Artikel könnten Sie interessieren
Cloud Native

Cloud Security: The 4C’s Of Cloud-Native Security – Part 5

In the last part of the article series on the 4C's of cloud-native security, we will look at securing the cloud environment itself. Although actual steps to harden your cloud infrastructure differ based on the cloud vendor and the services used to architecture your cloud-native application, many concepts and methodologies are quite similar.
Cloud Native

Cluster Security: The 4C’s Of Cloud-Native Security – Part 3

Securing the Kubernetes cluster (which may act as a runtime platform for several components of typical cloud-native applications) addresses one of the 4C's in cloud-native security. If you haven't heard about the 4C's of cloud-native security yet or want a quick refresher, you should read my corresponding introduction article.
Cloud Native

Container Security: The 4C’s Of Cloud-Native Security – Part 2

Securing the container images of your cloud-native application building blocks addresses one of the 4C's in cloud-native security. If you haven't heard about the 4C's of cloud-native security yet or want a quick refresher, you should read my corresponding introduction post.
Cloud Native

Code, Container, Cluster, Cloud: The 4C’s Of Cloud-Native Security – Part 1

Containers and cloud-native design patterns gained popularity over the past years. More and more organizations use containers in production and adopt cloud-native practices and methodologies to get even more value from existing containerized applications and underlying technologies such as container orchestrators like Kubernetes.
Cloud Native

Ausführen von Containern in Azure Container Instances (ACI) direkt über die Docker CLI

Vor einigen Monaten haben sowohl Microsoft als auch Docker eine nahtlose Integration von Azure Container Instances (ACI) und Docker CLI angekündigt. Als Container-Enthusiast musste ich mich natürlich mit dieser Integration befassen. Ich habe es in verschiedenen Szenarien getestet, um zu sehen, wie es mich unterstützen und meine Produktivität steigern könnte.
Infrastructure as Code

Infrastructure-as-Code (IaC): Bicep und Terraform im Vergleich

Infrastructure as Code (IaC) ist eine wichtige Technik in der Automatisierung. Teams beginnen ihren Weg zu Cloud-Native oft so, dass sie alles automatisieren und die Infrastruktur ist hier keine Ausnahme. Die stetig wachsende Akzeptanz von Cloud-Diensten und die Digitalisierung sind nur einige Gründe, warum IaC-Tools wie Terraform so beliebt sind. Project Bicep ist hier ganz neu - eine neue Sprache, die erstellt wurde, um Azure Infrastruktur-Deployments als Code auszudrücken