<style> .film__track { height: auto !important; } .film__stage { position: static !important; height: auto !important; /* Ohne diese Zeile ist der Rückfall LEER: container-type: size bemisst die Bühne nicht mehr nach ihrem Inhalt, und overflow: hidden schneidet alles weg. */ container-type: normal !important; } .film__poster { position: absolute !important; } .film__content [data-film-anchor] { position: static !important; transform: none !important; opacity: 1 !important; margin: 2.5rem clamp(1rem, 5vw, 4rem) !important; max-width: 34rem; } </style>
← Back to About

Verified Qualification

Software Developer · DevSecOps Development

Security is not something you pull over a finished website afterwards. It is built in the same steps as the site itself — or it is not built at all.

Issued by Developer Akademie GmbH AZAV-accredited training providerJanuary 2026

View certificate (PDF) (Software Developer · DevSecOps Development, opens in a new tab)

The record

Issuer
Developer Akademie GmbH
Issued
Focus
Web applications focus · IT security & cloud

Competencies

  • IT Security
  • DevSecOps
  • CI/CD
  • Cloud Security
  • Data Protection (GDPR)

Technologies

  • Python
  • Shell Scripting
  • YAML
  • Docker

What the certificate states

It was issued by Developer Akademie GmbH, an AZAV-accredited training provider, in January 2026, with a web applications focus. The document lists IT security, DevSecOps, CI/CD, cloud security and data protection as competencies, and Python, shell scripting, YAML and Docker as technologies. It exists as a PDF and can be viewed on this page.

What "DevSecOps" actually means

The term describes one simple shift: security is not checked at the end, it is built into every step. Instead of producing a report once a year, the delivery process checks itself — on every change, automatically, before anything goes live. That sounds technical and has a very commercial consequence for you: mistakes then cost minutes instead of weeks, because they surface before a visitor sees them.

What it changes during the build

A site I deliver brings its own protection: a Content Security Policy that decides which sources the browser may load at all; enforced HTTPS so nobody ends up unencrypted; device permissions a website does not need, switched off. Credentials never live in the source code, they live in the delivery vault. And the delivery itself is one action, not an FTP client pointed at a folder where nobody knows which file is current.

How you can check it on this site

You can inspect this site's response headers yourself — every browser tool shows them. You will find a strict Content Security Policy, HSTS with a one-year lifetime, and a Permissions Policy that simply disables camera, microphone and location for this domain. None of this is expensive. It is just usually missing.

What this means for your project

  • Your site ships through an automated pipeline — the same steps, every time, traceable.
  • Credentials and keys never sit in the project folder and never in an email.
  • Your visitors' browsers are told what they may load — third-party scripts do not just run along.
  • A way back to the previous version is planned before it is needed.

Other certificates

Do you know what your website loads in the browser?

I will look at your headers, your embedded scripts and your delivery process, and tell you in plain words where the next outage would come from.

Project inquiry