Application security failures usually trace back to a design decision an engineer was never trained to flag. For organizations placing products on the EU market, that training gap now carries direct compliance consequences under the Cyber Resilience Act (CRA).
Application security (AppSec) training for a team isn't really a separate subject from how that team builds software. It's the security layer of the same pipeline: the code review, the dependency check, the test that runs before deployment. That combined discipline has a name, DevSecOps (short for development, security, and operations), and for many software engineering teams, it's a practical starting point for building application security capability, since it embeds security into the existing development workflow rather than adding a separate one.
TL;DR
- For many engineering teams, application security training is effectively delivered through DevSecOps: embedding security checks into the software development lifecycle (SDLC) itself, instead of bolting them on afterward.
- The Cyber Resilience Act (CRA) requires manufacturers placing products on the EU market to implement secure development practices, and for many of them, developer training becomes one of the clearest ways to demonstrate that.
- Core AppSec testing methods, static application security testing (SAST) and dynamic application security testing (DAST), sit inside this training
- For a team, the differentiator isn't the content alone. It's whether a manager can see, in one place, which skills have actually been absorbed and understood.
What does application security training for a team actually mean?
For a team, it means building the skill to catch a vulnerability before it ships, when fixing it is still cheap. That's a different exercise from an individual developer reading about secure coding on their own time. It requires shared practices across the SDLC: secure design at the planning stage, secure coding and code review during development, and automated security checks before anything reaches production.
TryHackMe's DevSecOps learning path is built around exactly that structure, and it's a reasonable reference point for what this kind of training covers in practice.
What should DevSecOps training for a team actually cover?
A DevSecOps program worth the name touches the whole pipeline, from planning through deployment. TryHackMe's path breaks it down into five areas:
- Secure software development. The foundational layer: what a secure SDLC actually looks like, including a dedicated SSDLC room, and how DevSecOps differs from bolting security on at the end.
- Security of the pipeline. Source code security and CI/CD build security, the practices that catch problems as code moves toward production.
- Security in the pipeline. Dependency management, plus dedicated SAST and DAST rooms covering the two core testing methods that check code for flaws both before and while it runs. Alongside SAST and DAST, this is also where software composition analysis (SCA), checking third-party dependencies for known vulnerabilities, fits into a modern DevSecOps program.
- Container security. Containerization, Docker, and Kubernetes fundamentals, along with the vulnerabilities and hardening steps specific to containerized environments.
- Infrastructure as Code (IaC). Securing infrastructure that's defined and deployed as code, on-premises and in the cloud.
This provides a good picture of where application-level risk gets introduced and where it needs to be caught, well beyond a single testing tool added to a workflow. A mature application security program typically extends further still, into threat modeling, security architecture reviews, and API security among other practices; DevSecOps is the operational framework that brings a substantial part of that discipline into day-to-day software delivery.
Where should a team start if they're newer to security overall?
No particular background is required for professionals already working in security engineering, software engineering, or DevOps, but team members newer to these domains are pointed toward the Security Engineer learning path first, before the DevSecOps path itself.
That path is a broader, six-module foundation, network and system security, threats and risk management, and a dedicated Software Security module covering secure SDLC, SAST, DAST, and an introduction to DevSecOps, alongside a full OWASP Top 10 (2025) module on the vulnerability classes that actually show up in production applications. For a mixed team, that sequencing matters: it gives anyone newer to security context the same grounding in how applications actually get attacked before they move into the pipeline-specific depth of the DevSecOps path.
Why does application security training matter more now, under the Cyber Resilience Act?
For organizations placing products on the EU market, the CRA turns "we should probably train developers on security" into a legal expectation with a deadline attached.
- Who it covers: organizations placing a product with a digital element on the EU market, whether that's software, a connected or IoT device, or hardware with embedded connectivity.
- What it requires: security by design and secure development practices, among other obligations. Training itself isn't what the law mandates, but for many organizations it's one of the clearest ways to demonstrate that engineers are actually equipped to meet that obligation.
- Timeline: reporting obligations start September 2026, with full enforcement from December 2027.
Security expertise often sits inside a dedicated security team, while the developers and DevOps engineers actually writing code get comparatively little formal training. This disconnect can show up in product outputs: vulnerabilities baked in early are the most expensive to fix and the hardest to defend at audit once a product has already shipped. Training that reaches engineers directly, instead of funnelling every issue through a security team's review queue, puts security knowledge where the risk actually starts. Depending on the product and organization, meeting the CRA's broader secure development expectations may also involve practices like software bill of materials (SBOM) generation and coordinated vulnerability disclosure, alongside the training itself.
How do you know DevSecOps training is actually working across a team?
Managers need visibility into where the actual gaps are, which a completion percentage alone doesn't show. Individual course completion tells you someone finished a module. It doesn't tell you whether the skills are spread evenly across a team, whether a new hire is catching up, or where the gaps sit before an audit finds them.
This is where the team layer matters as much as the content. TryHackMe's Management Dashboard gives managers a skills matrix that can be toggled between individual users and groups, alongside assignment completion rates and real-time tracking of hands-on progress, so a gap shows up as a specific, visible pattern rather than a vague sense that "more training" is needed. That closed feedback loop, assign, measure, adjust, is arguably the difference between AppSec training as a one-off course and AppSec training as an ongoing team capability.
FAQ
What is application security (AppSec) training? Application security training builds the skills needed to identify, prevent, and fix security vulnerabilities in software, spanning secure design, secure coding, and testing methods like static and dynamic analysis. For a team, it typically means training that's coordinated across the software development lifecycle rather than left to individual initiative.
What's the difference between AppSec and DevSecOps? Application security is the broader discipline of identifying and reducing vulnerabilities throughout the software development lifecycle, and it includes practices like threat modeling and security architecture review as well as testing. DevSecOps is one operating model for delivering application security: it embeds those practices directly into the development pipeline, so security checks happen continuously alongside coding and deployment rather than as a separate, later review stage.
What are SAST and DAST? Static application security testing (SAST) analyzes source code for vulnerabilities without running the program, catching issues early in development. Dynamic application security testing (DAST) tests a running application from the outside, the way an attacker would, to catch issues that only appear at runtime. Most mature application security programs use both.
How does the Cyber Resilience Act affect application security training? The CRA requires organizations placing digital products on the EU market to implement secure development practices, with reporting obligations starting September 2026 and full enforcement from December 2027. Training itself isn't what the law mandates, but for many organizations, developer training becomes one of the clearest ways to demonstrate that engineers can actually meet that obligation.
Is DevSecOps required under the Cyber Resilience Act? No. The CRA doesn't specify DevSecOps or any other particular methodology. It requires secure development practices in general terms, and DevSecOps is simply one widely adopted way for an engineering organization to meet that expectation in practice.
Does application security training need to start with DevSecOps specifically? Not necessarily. DevSecOps training assumes some existing background in security engineering, software engineering, or DevOps. Team members newer to security overall typically benefit from a broader foundational path first, one that covers general security engineering alongside core application vulnerability classes, before moving into pipeline-specific DevSecOps training.
Does application security training work if it's only aimed at individual developers? It can build individual skill, but a team's actual exposure depends on whether that skill is consistent across the whole group, not concentrated in one or two people. Visibility into team-wide progress is what turns training into a defensible, auditable capability.
Ready to see what go from theoretical training to proven capability? Visit TryHackMe for Business to get started.
Joanna Duffy