Workshop

DevSecOps

Security checks as a quality gate in the pipeline, with findings developers actually fix.

DevSecOps means that security checks happen where software is created: in the pipeline, the automated sequence that turns source code into a running program. In many companies a separate team checks once a year instead, and the findings arrive when the release has long since shipped.

The difference is the same as between a final inspection at the end of the line and a check at every station. Both find faults, but only one finds them while the correction is still cheap. This workshop builds the first of these check stations into your own pipeline.

Duration
1 day
Format
On site or remote
Group size
6 to 12 people
Language
German or English
The key point up front

The most common reason why check gates are switched off again after three months is the exception that stays. The countermeasure fits on one line: every exception needs an expiry date, a name and one sentence of justification, and on the expiry date the gate takes hold again. You can introduce that today, without us. The workshop supplies the answer to the awkward cases: which threshold a gate needs so that it does not become a noise generator, and who decides when an expiry date is to be extended a second time.

Schedule

Agenda

Presentation plus rebuilding a real pipeline: by the end of the day at least one additional check gate runs in your environment.

Shift left

What that means in practice, which checks make sense early in the process and where shift left is overdone.

SAST, DAST, SCA and IAST

What each class finds and what it does not: the limits of the tool classes with concrete examples.

SBOM

Producing, checking and keeping a software bill of materials, and what it is needed for when it matters.

Container security

Base images, signatures and runtime permissions: the levers with the biggest effect.

Secrets

Scanning, rotation and central management instead of credentials in the repository.

Policy enforcement instead of rework

Policies that prevent violations before they are rolled out, instead of collecting them afterwards.

Prioritising findings

So the pipeline does not turn into a noise generator: thresholds, exceptions with an expiry date, clear ownership.

Practicalities

Who it is for, what you bring, what you take away.

Audience Development teams, platform teams, application security.
Prerequisites A running CI/CD pipeline that can be accessed during the workshop. At least one person needs write access for the rebuild.
Outcome After the workshop your pipeline has at least one additional check gate that is actively running.
Not included Tool licences and the ongoing operation of the checks. On request we take on the further build-out as a project, see Cybersecurity.

Dates and terms are agreed individually.

Contact

Request this workshop.

Write to us which group is to be trained and what should be different afterwards. You get a proposal for scope and schedule.

Request a date