Skip to main content

Migrating our Helm Charts to OCI registries

· 2 min read
Jannik Hollenbach
Core Developer

With the secureCodeBox 4.6.0 release, we are transitioning our installation instructions from the old Helm registry to the new Helm registry infrastructure, which uses Open Container Initiative (OCI) images to store charts.

What Will Happen?

  • The existing registry ( will be deprecated with secureCodeBox 4.6.0 and will be shut down at the end of the year.
  • All 4.x secureCodeBox Helm charts are already published to our OCI registry.
  • All 4.x releases of secureCodeBox will be published to both registries. Version 5.0.0 will be the first release to be exclusively published to the OCI registry.
  • All users are advised to migrate their Helm releases based on the charts from the OCI registries to ensure smooth operations.

What Steps Are Required by Users:

You'll need to switch the source of your Helm charts to point to the OCI registry. This process is straightforward.

When using Helm via the CLI/CI:

# Before
helm --namespace securecodebox-system install securecodebox-operator secureCodeBox/operator

# After
helm --namespace securecodebox-system install securecodebox-operator oci://

Existing releases that have been installed using the registry can be switched easily:

# Prior installation:
helm upgrade --install nmap secureCodeBox/nmap --version 4.5.0

# To switch the same Helm release to OCI, simply install the release with the same name from OCI:
helm upgrade --install nmap oci:// --version 4.5.0

Both ArgoCD and Flux also support OCI Helm charts.

Why Are We Doing This:

  • 🧱 Stability: The registry is the only component we need to self-host to provide secureCodeBox to the internet. There have been issues and downtime before, which we’d like to avoid in the future by having the charts hosted for us by the GitHub container registry.
  • 💰 Cost Efficiency: Hosting the charts requires a significant amount of bandwidth (about 4TB a month for the now quite large index.yaml file and the zipped Helm charts). We have migrated to a cheaper setup, but it has cost us some money in the past.
  • 🤹 Ease of Use: OCI-based charts don't require users to add the registry to their Helm installation beforehand. This will hopefully ease some friction for users who are not familiar with Helm.

Developing an SBOM Workflow – Part 2: SBOM Consumption

· 14 min read
Lukas Fischer
Core Developer

A river mouth

Cover photo by Look Up Look Down Photography on Unsplash.

This is part two of the SBOM story which covers the consuming side. If you missed part one, you can find it here.

One would assume that with a standardized format the combinations of generator and consumer are interchangeable, but as noted previously, the SBOMs still vary in content and attributes.

Automate ZAP with Authentication

· 22 min read
Rebecca Falke
Core Developer
Max Maass
Core Developer

A Robot Hand Cover photo by @possessedphotography on Unsplash.

The OWASP Zed Attack Proxy (ZAP) can be a powerful tool for pentesters and AppSec testing. However, some of its functionality can be a bit hard to wrap your head around at first. In this post, we will describe how to use one of the more powerful features of the software: Authentication and session management. First, we will show you how to develop an authentication script for a new, previously-unsupported authentication scheme, using the graphical ZAP interface. Afterwards, we will dive into how the same can be achieved inside the secureCodeBox using the newly-supported ZAP Automation Framework.

Developing an SBOM Workflow – Part 1: SBOM Generation

· 15 min read
Lukas Fischer
Core Developer

A waterfall

Cover photo by Mike Lewis HeadSmart Media on Unsplash.

In the previous blogpost we described how to use scans to find infrastructure affected by Log4Shell, but wouldn't it be way more convenient to already have this information available? SBOMs promise to offer that convenience of only having to look up, where an affected dependency is used, and immediately being able to mitigate it. This blog post details our plans to integrate an SBOM creation workflow into the secureCodeBox and our troubles with using different tools for it.

How We Used the secureCodeBox In Our Log4Shell Incident Response

· 11 min read

A burning log

Cover photo by Ray Shrewsberry on Unsplash.

By now, you must have heard about Log4Shell, the present that ruined Christmas for many developers and IT specialists, whether naughty or nice. This blog describes how we used the secureCodeBox as one building block in our incident response process at iteratec.

Introducing SAST Scanning With secureCodeBox 3.3

· 12 min read
Max Maass
Core Developer

A magnifying glass pointed at a laptop keyboard

Cover photo by Agence Olloweb on Unsplash.

With secureCodeBox 3.3, we have added several features that allow you to use secureCodeBox for static application security testing (SAST). This blog post gives an introduction to how several new features of secureCodeBox 3.3 can be used to quickly run targeted SAST scans of your entire codebase. By the end of this post, you will know how to build a SAST workflow to detect which of your repositories include a malicious dependency. We will cover all steps of the process: obtaining a list of all software repositories in your organization, cloning and scanning them, and even dropping all of the results into a DefectDojo instance for later inspection.

Why secureCodeBox Version 2

· 8 min read
Sven Strittmatter
Core Developer


Cover photo by Evan Dennis on Unsplash.

In this article I will give you a deeper insight why we decided to make a major breaking rewrite of the secureCodeBox. First I'll give you an overview of the v1 architecture and the rationale behind. Also outline the problems we stumbled upon using secureCodeBox v1 for some years now. Afterwards I introduce you to the new secureCodeBox v2 architecture and the rationale behind.