secureCodeBox: continuous security scanning with Kubernetes operators

What it is, and the two things it is not

secureCodeBox is a Kubernetes based, modularized toolchain for continuous security scans of a software project. Its goal, in the README's words, is to orchestrate and easily automate a bunch of security-testing tools out of the box. It is an official OWASP project, and the badge in the README header records that as OWASP Lab Project.

The subject is a toolchain rather than a scanner, and that distinction defines the project. A scanner finds one class of problem in one language or one stack. secureCodeBox runs scanners, several of them, in a way that a pipeline can trigger, and the project is organised around making that repeatable.

Two disclaimers shape how the project presents itself, and they are worth reading in full.

The first is scope. The purpose of secureCodeBox is not to replace the penetration testers or make them obsolete, and the README strongly recommends running extensive tests by experienced penetration testers on all your applications. The second is usability. The secureCodeBox is no simple one-button-click solution. You must have a deep understanding of security and how to configure the scanners, and an understanding of the scan results and how to interpret them is also necessary.

That second disclaimer is unusual and it changes how the project should be judged. A tool that automates security testing could easily be sold as removing the need for expertise. This one says the opposite, in the same section, and puts the requirement in bold. The claim is narrower and more credible because of it.

The consequence for an adopter is straightforward. secureCodeBox is a way to run the easy half of the security work continuously and cheaply, not a way to run the hard half automatically. A team that installs it without reading the scanner documentation will get a pipeline that produces findings nobody can triage, which is worse than not scanning at all.

The argument: a penetration test is a snapshot

The Purpose of this Project section explains the reasoning, and it is a good argument.

The typical way to ensure application security is to hire a security specialist, a penetration tester, at some point in the project to check the application for security bugs and vulnerabilities. The README identifies two major drawbacks with that.

The first is that a lot of projects do continuous delivery, deploying new versions multiple times each day, while the penetration tester is only able to check a single snapshot. Some further commits could introduce new security issues after the test, and to ensure ongoing application security the tester would also have to test continuously, which is rarely financially feasible.

The second drawback is subtler. Due to a typically time boxed analysis, the penetration tester has to focus on trivial security issues, the low-hanging fruit, and therefore will probably not address the serious, non-obvious ones.

Put together, those two points describe a structural mismatch. A human expert with a fixed budget cannot cover a codebase that changes several times a day, and the same budget pressure means they spend it on the shallow checks.

The response is to split the work by cost. With secureCodeBox, the toolchain scans continuously and finds the low-hanging fruit early in the development process, which frees the resources of the penetration tester to concentrate on the major security issues. The automation takes the work that a scanner does well, done often, and leaves the human the work that a scanner cannot do at all.

That is a defensible division of labour, and it is worth being clear that the project is not claiming the low-hanging fruit is unimportant. A dependency with a known vulnerability, a missing security header, a leaked secret in a repository, those are cheap to find and expensive to miss, and they are the class of problem that grows without anyone noticing.

The architecture: operators, hooks, parsers and a control CLI

The repository layout describes the architecture, and it is a hybrid project rather than a single Go binary.

The operator directory is the Kubernetes piece, and the topics list names a kubernetes-operator explicitly, so the design is operator based: each scanner is a custom resource whose lifecycle the operator manages on a cluster. The scanners directory holds the scanner integrations themselves, and the scanner topics mention zaproxy, which is the OWASP ZAP proxy and the most likely first scanner in a setup like this.

The hook-sdk and parser-sdk directories are the part that makes the toolchain modular rather than a fixed pipeline. A hook is the unit of work that runs against a target, and a parser is the unit that turns raw tool output into a normalised finding. Splitting them that way is what allows different scanners to feed the same reporting, and it is why the SDKs are separate directories rather than part of the operator.

The scbctl directory is the control tool, the command line interface for driving an installation. The auto-discovery directory and the lurker directory are for finding things to scan and for running them against targets that are not themselves a cluster workload.

Around those are the supporting pieces. The demo-targets directory holds applications to scan, the tests directory the test suite, and the documentation directory the site, which the README says has its own quickstart and installation instructions. There is a Taskfile.yaml, which is the task runner used to drive the development tasks, and a .helm-docs directory, which means the Helm chart documentation is generated rather than written by hand.

The project also carries a hook-sdk and a parser-sdk as separate published surfaces, which is a hint about how a third party would add a scanner of their own, and that is the extension point to look at if you want to add a tool the project does not ship.

The repository discipline, which is where most of the engineering is

secureCodeBox is a multi-language project, and the top level listing shows the tooling that keeps it consistent.

The linting is spread across several tools. There is a .mega-linter.yml, which is the configuration for the project that runs many linters in one place, and it is complemented by an .eslintrc.json with an .eslintignore, a .prettierrc.yaml, a .yamllint.yaml and a .cspell.json. There are also version pins for the tools themselves, in a .nvmrc for Node and a .python-version for Python, and an .envrc for direnv, which suggests the development environment is meant to be reproducible rather than whatever happens to be on the machine.

The licence handling is unusually thorough, and it is the part that stands out. There is a REUSE.toml, a LICENSES directory, a DCO file with its own .license sidecar, and .license sidecars next to configuration files such as .cspell.json.license, .npmrc.license and .prettierrc.yaml. The SPDX header at the top of the README names the copyright holders as the secureCodeBox authors and the licence identifier as Apache-2.0. This is the REUSE specification for licence compliance, and adopting it means every file in the tree, including the ones that are usually ignored, carries a known licence and a known copyright. For a security project that will be read by legal and compliance teams, that is a sensible investment.

The rest is ordinary good practice. renovate.json keeps dependencies current, .git-blame-ignore-revs records the commits that changed formatting only so that blame stays useful, netlify.toml configures the documentation site build, and there is a SECURITY.md for reporting problems in the project itself. The .templates directory holds the templates used to generate parts of the tree, and the .github directory holds the CI workflow that the build badge points at, alongside an OpenSSF Scorecard badge.

Provenance signals, and what an OWASP badge does and does not mean

The README header is a wall of badges, and reading them as a set tells you what kind of project this is.

There is a FOSSA status badge, which is the one that matters most for a security tool, because FOSSA tracks licence and dependency analysis and its shield indicates the state of that for the project. There is an OpenSSF Scorecard badge, which summarises a set of supply chain practices such as whether the project publishes signed releases, uses branch protection, has a security policy and a fuzzing setup. There is an Artifact Hub badge, which shows the project is published as a Helm chart repository, and a GitHub release badge, which shows the SemVer release is the current one.

None of those badges is a security guarantee about the scanners the project runs, and it is worth saying so plainly. They are indicators about the project's own hygiene. A tool that automates security testing has an unusually high credibility bar, because a user is being asked to run containers that attack their own application, and the question a careful adopter will ask is not whether the ZAP integration is good but whether the artefact they are about to run in their cluster came from a project that keeps its supply chain in order. The scorecard and the FOSSA badge are the visible answers to that question.

The sponsorship is the other visible signal. The README lists iteratec, SDA SE, Timo Pagel IT Consulting, Secura and Signal Iduna as sponsors, and the author information says the project is sponsored and maintained by iteratec GmbH, with secureCodeBox.io as the site. Commercial sponsors of a security project are common in the German security scene, and it tells you that the maintenance is funded work rather than a hobby with a mailing list.

Releases, licence and the size of the commitment

The licence of the code is Apache-2.0, stated in the README with a link, and every file in the repository carries a SPDX header, which the REUSE setup makes auditable. The repository's own licence field is recorded as a custom licence that GitHub cannot classify, so the LICENSE file and the LICENSES directory in the tree are the documents to read for the exact terms. This describes the published terms rather than legal advice.

The release history shows a project on a versioned cadence with pre-releases published ahead of the final: v5.9.0 came out on 2026-09-15, with a v5.9.0 release candidate on 2026-09-10, and v5.8.0 on 2026-07-07. The last push was on 2026-10-16, and the repository is not archived. A major version number, five and counting, is worth noting for an infrastructure project, because the version is tied to the Helm chart and the operator, and an upgrade moves the workloads in your cluster.

The README points at a separate upgrading guide for the steps, which is the right way to do it, and the version number is the reason that guide matters.

The last thing to weigh is the operational commitment, and the README is straightforward about it. This is a Kubernetes project. The scanners run as operators on a cluster, the toolchain is a set of custom resources, and the CLI drives it. A team without Kubernetes, or with a security team that has deliberately avoided putting offensive tooling on a shared production cluster, will find that the deployment model is the first hurdle, before any scanner configuration is considered. The topics list mentions zaproxy, so ZAP is the first integration to look at, and the documentation site has the installation instructions and a guide to first scans that the README points to rather than repeats.

Editorial conclusion

Adopt secureCodeBox when your team ships continuously and wants the cheap, obvious security checks to run on every change, because that is exactly the work the project is built to automate and to free the human testers for. It is the wrong tool if you have no Kubernetes, if you want a single command that produces trustworthy findings, or if you are looking for a substitute for a penetration test, since the project says otherwise twice. Before deploying, read the documentation on installation and first scans rather than the README, and remember that the scanners need configuration and their results need interpretation, which the README calls out as a requirement rather than a detail.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. secureCodeBox/secureCodeBox on GitHub