Software teams are measured on shipping. Security skill tends to lag behind delivery speed, because the pressure that shapes an engineer's day is the release, rather than the vulnerability that ships inside it. For anyone planning capability across a software or platform engineering team, that lag shows up as a recurring problem rather than a one-time deficit: the moment a team learns to handle one class of risk, the dependencies, pipelines and attack techniques underneath it are likely to have already moved.
DevSecOps training can help software and engineering teams address that lag-time.. DevSecOps (development, security, and operations) embeds security practice into the way software is designed, built and deployed, rather than adding a separate review stage at the end, making cybersecurity considerations an ongoing part of building products.
But the gap that strong DevSecOps training addresses does not stay closed on its own as development progresses. That’s why it’s so crucial that tech leaders focus on current and engaging training that keeps pace, and treats ‘being trained’ as a moving target.
In short:
- The DevSecOps skills gap is the distance between what engineers are trained to do, ship working software, and what secure delivery requires across the software development lifecycle (SDLC). It reopens continuously as dependencies, pipelines and attack techniques change.
- Locating the gap means checking capability against each stage of the pipeline: secure design, source code and build security, dependency and testing discipline, container security, and infrastructure as code (IaC).
- Closing a gap that keeps reopening takes repeatable, hands-on practice against realistic scenarios rather than a single annual training push. TryHackMe's DevSecOps learning path is built around that kind of applied practice.
- Whether the gap is closing across a whole team, rather than in one or two individuals, is something a manager can measure directly through completion and skills data in the TryHackMe for Business Management Dashboard.
What is the DevSecOps skills gap, and why doesn't it stay closed?
The DevSecOps skills gap is the distance between what software engineers are trained and paid to do, ship working features, and the additional skills secure delivery requires: recognizing an insecure design before it is built, catching a vulnerable dependency before it merges, and reading the output of a security test rather than routing it to someone else. It is a capability gap inside the engineering team, distinct from the resourcing gap that leaves a central security team unable to review everything as delivery speeds up.
The gap reopens continuously for a specific reason. The attack surface a software team defends does not hold still. New dependencies enter the codebase regularly, pipeline tooling changes, container base images pick up fresh vulnerabilities, and attackers develop new techniques against all of it. A developer trained thoroughly on last year's risks may still be behind this year's. TryHackMe's own framing of the DevSecOps path points to a clear gap in practical, hands-on training on the topic, and TryHackMe positions its content as continuously updated to keep pace with new attack variants. Skill built once against a moving target tends to decay, which is why capability here is better understood as something maintained than something finished.
Whether a team treats the gap as finished or as maintained shapes how it plans. Treating the gap as a one-time fix, a course everyone takes once, tends to leave a team current only until the next shift in the stack. Treating it as an ongoing practice, with periodic realistic exercises, tends to hold capability closer to the threat the team actually faces.
Where does the DevSecOps skills gap show up for an engineering or software development team?
The gap tends to show up unevenly across the pipeline, so locating it means checking capability stage by stage rather than assuming a single weak spot. Each stage below is a place a gap commonly hides, paired with where that stage is practiced hands-on. The rooms named are drawn from TryHackMe's DevSecOps learning path, a five-module, intermediate path of roughly 27 hours, and each is a browser-based environment a team can return to as the stage's risks change rather than a one-pass lesson.
- Secure design and the secure SDLC. Whether engineers can build security into a design before code exists, which is the cheapest point to catch a flaw. Covered in the free Introduction to DevSecOps room, SDLC and SSDLC, where SSDLC is the secure software development lifecycle.
- Source code and build security. Whether the pipeline itself is trusted, covering the automation, the source code repository and the build process that moves code toward production. Covered in Intro to Pipeline Automation, Source Code Security and CI/CD and Build Security, where CI/CD is continuous integration and continuous delivery.
- Dependency management and testing discipline. Whether engineers can vet third-party components and act on the output of automated testing, including software composition analysis (SCA), static application security testing (SAST) and dynamic application security testing (DAST). Covered in Dependency Management, SAST, DAST and the no-walkthrough challenge Mother's Secret.
- Container security. Whether containerized workloads are built and run safely, from base images through orchestration. Covered across containerization fundamentals, Intro to Docker, Intro to Kubernetes, Container Vulnerabilities and Container Hardening.
- Infrastructure as code (IaC). Whether infrastructure defined and deployed as code is secured before it is provisioned, on-premises and in the cloud. Covered in Intro to IaC, On-Premises IaC and Cloud-based IaC.
Mapping a team against these five stages tends to turn a vague sense that "we should do security training" into a specific picture of which stages are covered and which are thin.
How do you close a DevSecOps skills gap that keeps reopening?
You close a gap that keeps reopening with repeatable, hands-on practice against realistic scenarios, refreshed as the stack and the threats change, rather than a single training event that a team completes once and files away. The difference between the two approaches is the difference between capability that tracks the threat and capability that subtly goes stale.
| Dimension | One-time training push | Repeatable, hands-on practice |
|---|---|---|
| What it assumes | The skills gap is a fixed deficit that can be filled once | The gap reopens as dependencies, pipelines and techniques change |
| Format | A course completed once, often slide-based | Applied exercises in a sandboxed environment, repeated on a cadence |
| Evidence produced | An attendance or completion record | Work-sample results, including challenges solved without a walkthrough |
| As the stack moves | Capability falls behind until the next scheduled course | Content refreshed against new attack surfaces keeps skill current |
Applied practice tends to build the pattern recognition that reading about a vulnerability class does not. Working in a sandboxed environment lets an engineer find, exploit and then remediate a flaw safely, which is closer to the work than a lecture on the same flaw. A challenge solved without a walkthrough, such as the Mother's Secret code-analysis room in the DevSecOps path, produces evidence of applied skill that an attendance record does not. The part that keeps the gap from widening again is cadence plus currency: rerunning practice on a schedule, against content TryHackMe updates as new attack surfaces appear, so the exercises track the threat rather than a fixed snapshot of it. A team newer to the topic can start for free with the Introduction to DevSecOps room before committing to the full path.
How do you measure whether the gap is closing across a whole team?
You measure it with completion and skills data that shows capability at the group level as well as per individual, because a team's real exposure depends on whether skill is consistent across the group rather than concentrated in one or two engineers. A single strong developer does not close a team's gap.
The TryHackMe for Business Management Dashboard is built for that view. Admins can see a team's skills matrix from the Reports page, toggle between users and groups, and overlay results to compare performance, alongside assignment and completion tracking. Framed against the five pipeline stages above, that turns "who has done some security training" into "which stages the team can demonstrably handle and which still need work," which is the picture a manager needs to plan the next cycle of practice. Because the underlying content is continuously updated against emerging threats, the same dashboard shows whether a team stays current as those threats move, rather than whether it cleared a bar at a single point in time.
How does closing the DevSecOps skills gap support compliance such as the Cyber Resilience Act?
Closing the gap produces the trained-workforce evidence that regulations like the EU Cyber Resilience Act (CRA) expect from organizations placing products with digital elements on the EU market. The CRA requires manufacturers to follow secure development practices, and demonstrable developer capability is one of the clearer ways to evidence that obligation, with reporting obligations starting in September 2026 and full enforcement from December 2027. TryHackMe covers the compliance angle in depth for product teams in its guide to building hands-on cyber capability under the CRA, so the point here is narrower: the same repeatable, hands-on practice that keeps a team's skills current also generates the per-person records an assessor can map to a control.
How does a DevSecOps skills gap fit hiring, onboarding and progression?
A skills gap is easier to manage when the same practice that closes it also produces evidence a manager can use at each stage of a team member's tenure. At hiring, a validated hands-on result gives a signal of applied ability that a knowledge exam does not, which tends to shorten the technical interview. During onboarding, working through a path in the same kind of browser-based environment the team uses day to day brings a new engineer to a shared baseline faster than reading documentation. For progression, a visible ladder from foundational content into specialist areas gives an engineer a route to grow inside the team, which tends to help retention. The through-line is that capability, evidence and a growth path come from the same practice rather than from three separate programs.
FAQ
What is the DevSecOps skills gap?
The DevSecOps skills gap is the distance between what software engineers are typically trained to do, build and ship working features, and the additional skills secure delivery requires across the software development lifecycle: secure design, secure coding and code review, dependency vetting, security testing, and securing the pipeline and infrastructure. It is a capability gap inside the engineering team rather than a shortage of dedicated security staff, and it tends to reopen as the tools and threats change.
What does DevSecOps training for a team cover?
DevSecOps training covers securing software across the whole pipeline rather than at a single stage. TryHackMe's DevSecOps learning path is organized into five areas: secure software development and the secure SDLC; security of the pipeline, meaning source code and build security; security in the pipeline, meaning dependency management, static application security testing (SAST) and dynamic application security testing (DAST); container security; and infrastructure as code. It is an intermediate path of roughly 27 hours across 18 hands-on labs.
Why doesn't developer security training stay effective over time?
Developer security training loses effectiveness because the attack surface it targets keeps changing. New dependencies, updated pipeline tooling, fresh container vulnerabilities and new attacker techniques all appear continuously, so skills built against one snapshot of the threat tend to decay against the next. Training that runs once tends to leave a team current only until the next shift in the stack, which is why repeatable, hands-on practice against continuously updated scenarios tends to hold capability closer to the real threat.
How do you measure DevSecOps training across a team?
You measure it with data that shows capability at the group level, alongside individual completion. On TryHackMe, the Management Dashboard shows a team's skills matrix on the Reports page, lets an admin toggle between users and groups and overlay results to compare performance, and tracks assignment completion. Mapped against the stages of the pipeline, that shows which stages a team can demonstrably handle and which still need work, rather than who attended a course.
Does the Cyber Resilience Act require DevSecOps?
Not explicitly. The Cyber Resilience Act does not name DevSecOps or any specific methodology. It requires manufacturers of products with digital elements to follow secure development practices and handle vulnerabilities across a product's life, with reporting obligations from September 2026 and full enforcement from December 2027. DevSecOps is one practical operating model for meeting those expectations, and demonstrable developer training is a common way to evidence the secure-development obligation, but the regulation prescribes the outcome rather than the method.
Building and keeping DevSecOps capability across a software team is less a single project than a practice a team returns to as the threat moves. Details on planning role-mapped, hands-on training and tracking it across a team are available at TryHackMe for Business.
Joanna Duffy