DevSecOps in Practice is a hands-on course in building security into CI/CD pipelines, from secret detection, SAST and dependency scanning to container image and IaC scanning, SBOMs, image signing, DAST and Kubernetes security. It suits DevOps and platform engineers, developers and application security teams, and you leave with a working secure pipeline in GitLab CI to adapt for your own projects.
Development teams now ship code to production several times a day with CI/CD, yet much of the security work still waits for a final check just before release. Vulnerabilities are found late, when they are hard and expensive to fix, or they slip into production altogether: passwords committed with the code, libraries with known flaws, container images that were never scanned and clusters that grant far more access than they need. DevSecOps moves these checks into every stage of the pipeline so the team learns about problems while the code is still being written.
This course has learners build a secure pipeline with GitLab CI step by step on a single sample application. It starts with the shift-left mindset and basic threat modelling, then detects leaked secrets with Gitleaks, runs SAST with SonarQube, scans dependencies and container images with Trivy, checks infrastructure as code, generates an SBOM and signs images with Syft and cosign, and tests the running application with OWASP
ZAP. All the results are then combined into security gates that stop the pipeline when serious issues are found, before the course moves on to Kubernetes security with RBAC, Pod Security Standards, network policies, admission control and runtime monitoring. It closes with a capstone that builds a secure pipeline from code all the way to the cluster. (3 days, 6 hours per day, 18 hours in total, Intermediate level.)
Course Details
This is a practical DevSecOps course that shows learners how to bring security checks into every stage of a CI/CD pipeline. It runs for 3 days, 6 hours per day (18 hours in total, 09:00-16:00), as lectures with labs on a single sample application that has deliberate vulnerabilities to find and fix. Intermediate level. The pipeline examples use GitLab CI, with guidance on applying the same ideas in Jenkins, and all tools are open source or free to use. The course does not cover in-depth penetration testing or SOC operations. Learners take home a lab guide, the sample application with a complete pipeline file, sample Kubernetes manifests and policies, a threat model template and a DevSecOps checklist.
Section 1: DevSecOps and the Shift-Left Mindset
Why security checks at the end of a project cannot keep up with CI/CD delivery
The shift-left mindset and shared responsibility across Dev, Ops and Security
An overview of each kind of check: secrets, SAST, SCA, images, IaC and DAST
The OWASP Top 10 and the software supply chain risks you need to know
Assess the team's readiness and plan a step-by-step DevSecOps rollout
Section 2: Workshop: Threat Modelling Basics
What threat modelling is and when to do it in the development cycle
Draw a data flow diagram of the system and identify trust boundaries
Identify threats with the STRIDE framework
Prioritise risks and choose the checks that address each one
Workshop: build a threat model of the sample application used throughout the course
Section 3: Lab: A Baseline GitLab CI Pipeline
The structure of .gitlab-ci.yml: stages, jobs, rules and artifacts
Set up a GitLab Runner and run a pipeline for build and test
Order the stages so each security check has a place
Handle pipeline variables and secrets safely
How to apply the same approach in Jenkins
Section 4: Lab: Detecting Leaked Secrets with Gitleaks
Secrets that commonly leak with code, such as API keys, tokens and passwords
Scan the whole Git history with Gitleaks and read the results
Install a pre-commit hook to stop secrets before they are committed
Add a secret detection job to the pipeline and handle false positives
What to do when a secret leaks: revoke it, rotate it and clean the history
Section 5: Lab: SAST with SonarQube
How SAST works, its strengths and its limits
Install SonarQube with Docker and connect it to the project
Read vulnerabilities, security hotspots and code smells
Set a quality gate and show the results in merge requests
Lab: fix the SQL injection and XSS flaws that SonarQube finds
Section 6: Lab: Dependencies and SCA
The risks of open source libraries and transitive dependencies
Scan the project's dependencies with Trivy in filesystem mode
Read CVE and CVSS data and prioritise fixes by real risk
Check library licences that may conflict with company policy
Use lock files and automated dependency updates
Section 7: Lab: Scanning Container Images with Trivy
Vulnerabilities that come with base images and operating system packages
Scan images in the pipeline before pushing them to the registry
Write secure Dockerfiles: minimal base images, a non-root user and multi-stage builds
Handle vulnerabilities that have no patch yet with a justified ignore file
Lab: reduce the vulnerabilities in the sample app's image and compare before and after
Section 8: Lab: IaC Scanning
Common mistakes in Terraform, Kubernetes manifests and Dockerfiles
Scan for misconfigurations with Trivy in config mode
Read the findings and fix them following each rule's guidance
Add an IaC check job to merge requests before deployment
Lab: fix a Kubernetes manifest that runs with far more privilege than it needs
Section 9: Lab: SBOMs and Signing Container Images
What an SBOM is, and the SPDX and CycloneDX formats
Generate an image SBOM with Syft and use it to check for new vulnerabilities later
Sign images with cosign and attach the SBOM as an attestation
Verify signatures before deployment to confirm where an image came from
An overview of SLSA for raising trust in the build process
Section 10: Lab: DAST with OWASP ZAP
How DAST differs from SAST and where it belongs in the pipeline
Run a ZAP baseline scan against the app deployed to a test environment
Scan an API from its OpenAPI specification
Tune ZAP rules and handle false positives
Lab: find and fix insecure security headers and cookie settings
Section 11: Lab: Security Gates and Managing Scan Results
Decide when the pipeline should stop and when it should only warn
Bring results from several tools together and remove duplicates
Manage exceptions with a named owner and an expiry date
Give developers feedback in merge requests without slowing the team down
Lab: set up security gates for the sample app's pipeline
Section 12: Lab: Kubernetes RBAC and Pod Security
The Kubernetes attack surface and what to protect first
RBAC: roles, cluster roles, service accounts and least privilege
Pod Security Standards at the Privileged, Baseline and Restricted levels
Enforce them per namespace with Pod Security Admission
Lab: adjust a deployment so it passes the Restricted level
Section 13: Lab: Network Policies and Admission Control
Default-deny network policies that open only the connections that are needed
Managing secrets on Kubernetes and using an external secret store
What admission control is and how to write policies with Kyverno
Allow only signed images from approved registries to be deployed
Lab: block pods that break the organisation's policies
Section 14: Runtime Security and Monitoring
Why scanning before deployment is not enough
An overview of runtime detection with Falco and example rules
Collect Kubernetes audit logs and send them to the monitoring system
Metrics for a DevSecOps programme and reporting to management
Lab: detect a shell being opened inside a running container
Section 15: Workshop: Secure Pipeline Capstone
Design a secure pipeline for the sample app based on its threat model
Combine secret detection, SAST, SCA, image scanning, IaC scanning, SBOM and DAST
Deploy to Kubernetes with Pod Security and admission policies enforced
Present the results, review them together and draw up a roadmap for your own team
Wrap up with a DevSecOps checklist to use in your organisation
No public rounds are open right now. Join the waiting list and we will contact you first when the next round opens, or ask us on LINE. Or call 02-570-8449 or 088-807-9770
Built for DevOps and platform engineers who look after their organisation's CI/CD pipelines · Software developers who want to write and ship secure code from the start · Application security teams who want to bring security checks into the pipeline Background you should have: Working knowledge of Git and the merge request or pull request workflow · Able to build and run containers with Docker and understand Dockerfiles Not sure the fit is right? Talk to our team on LINE @itgenius or call 02-570-8449.
THB 9,900 (currently THB 8,910 on promotion). The course runs 18 hours. The price excludes 7% VAT (for payment in a company's name). Pay by bank transfer to the company account, confirm it on our payment page, and we can issue the receipt or tax invoice in your company's name.
Yes. Everyone who completes the course receives a Certificate of Completion from IT Genius Institute. Each certificate carries its own number, and anyone holding that number can verify it online on our certificate page, so you can add it to your portfolio or pass it to HR as evidence of training.
You can attend onsite at IT Genius Institute or arrange to join online, and we also run it as a private in-house session for your team. Ask about dates and venues on LINE @itgenius or call 02-570-8449.
Yes. You may retake the same course free of charge in a later round, under the institute's conditions. Tell our team which course and round you attended, and we will check it and offer you the rounds that still have seats. Ask us on LINE @itgenius or call 02-570-8449.
Enrol online with the registration form on this page. You can register several attendees at once and enter your tax ID and billing address for the tax invoice. Or request a company quotation straight from the quote button. For anything else call 02-570-8449 or reach us on LINE @itgenius.
Many organisations already have firewalls and antivirus, yet they still cannot see what is happening on their own machines and servers from day to day. Logs are scattered in many places and nobody looks at them until something breaks, so when a real incident…
Building and changing infrastructure by hand through a web console creates inconsistency, leaves no audit trail and makes it hard to reproduce an environment. Terraform solves this by expressing infrastructure as code that lives in Git, is reviewed through…
Once an organization runs dozens of servers, configuring each one by hand wastes time, creates inconsistency between machines and leaves no audit trail. Ansible solves this by describing the desired state of machines in YAML and bringing every server into…
