In a world where security needs to move as fast as software delivery, how we structure our AppSec (Application Security) teams is more critical than ever. The right team topology can make the difference between a well-secured application and a bottlenecked security process.
Before looking in detail into these structures, let’s break down some essential team types that shape how organizations work, especially in DevOps environments.
Key Team Types in Modern DevOps-Oriented Organisations
“Team Topologies“, a foundational book on team design, identifies four main team types. Each serves a different function in modern organizations and plays a role in structuring AppSec and Security Engineering effectively:
1. Complicated-Subsystem Team
This team focuses on complex areas that require deep expertise. In security, the AppSec team often falls into this category when they focus on tasks like vulnerability analysis, threat modelling, or penetration testing – tasks that require specific, in-depth security skills.
2. Enabling Team
An enabling team’s goal is to help other teams be successful. In the security context, this is often a Security Engineering (SecEng) team, which may work with product engineers to embed security practices or set up automated security tools. They don’t own the product, but they enable other teams to build securely.
3. Stream-Aligned Team
A stream-aligned team is focused on delivering value to the end user. For example, the Product Engineering Team is aligned to a product stream or a specific feature set, working continuously to meet customer needs. They rely on other teams – like SecEng and AppSec – to support security while they focus on delivering product features.
4. Platform Team
The platform team provides and maintains the infrastructure that other teams depend on. For instance, CloudOps is often the platform team, providing cloud resources, CI/CD pipelines, and deployment tools that help the product and security teams work efficiently.
With these team types in mind, let’s examine two ways of structuring AppSec in matrix organizations and explore how different Security Engineering scopes affect team dynamics.
AppSec Structure 1: Separate AppSec and Security Engineering Teams
In this structure, the AppSec team and the SecEng team operate independently, each with a specific focus and scope of responsibilities. Here’s what it looks like:
- AppSec Team (Complicated-Subsystem): Focuses on high-complexity security tasks such as vulnerability assessments, penetration testing, or cryptographic implementations. They dive deep into securing specific parts of the application that require specialized expertise.
- SecEng Team (Enabling): This team works to enable other teams to operate securely, but the scope of SecEng teams can vary widely across organizations. In some companies, SecEng focuses primarily on tooling – providing automated security scans, setting up CI/CD security pipelines, and managing tools like static code analyzers. In other companies, SecEng might include developer enablement, such as secure coding training, threat modeling, and custom tooling that integrates directly with developer workflows.
- SecEng as Tooling-Centric: When SecEng’s primary role is tooling, they may manage automated security checks, vulnerability scanning, and integrations within CI/CD pipelines. This scope works well in highly automated DevOps settings where security tooling needs to keep up with rapid deployment.
- SecEng as Developer Enablement: In organizations where SecEng acts as a security enabler, they might collaborate closely with Product Engineering on secure coding practices, helping developers understand and adopt security practices directly in their code. This is often achieved by providing secure frameworks and libraries to do security by default by providing secure APIs.
| Pros | Cons |
| AppSec can dive deeply into high-impact, complex security work. | Siloed approach may slow down coordination and integration. |
| SecEng can focus on specialized tasks, whether tooling or developer enablement. | Redundant responsibilities between AppSec and SecEng can create inefficiencies. |
| Clear distinction of roles allows each team to specialize in their focus area. | Security may take longer to integrate as each team works independently. |
| Workload can be distributed effectively between two teams. | Risk of unclear ownership, where tasks fall between teams and remain unaddressed. |
This structure can be ideal in large organizations or those with mature security practices, where specialized focus is necessary. However, the potential for silos can be a drawback in fast-paced environments.
AppSec Structure 2: Unified DevOps Security Team
In this alternative, AppSec and SecEng functions are combined into a single DevOps Security Team that performs both specialized security tasks and enablement activities. Here’s what that structure looks like:
In this structure:
- DevOps Security Team: This team combines both high-complexity security tasks (traditional AppSec responsibilities) and enablement activities (traditional SecEng responsibilities). It works closely with Product Engineering to embed security practices and interacts with CloudOps to secure the platform.
- Deep Security and Enablement: The DevOps Security Team here may take on both tooling and developer enablement, which makes them adaptable. They could provide tooling for automated security checks and CI/CD integration while also offering secure coding guidance and building a security-conscious culture.
| Pros | Cons |
| Enables faster integration of security into DevOps workflows. | Broad responsibilities may dilute focus on specialized security needs. |
| Unified team improves communication and reduces silos. | Balancing deep security analysis with enablement tasks can be challenging. |
| Security becomes embedded directly into the SDLC. | High scope may lead to team overload without clear boundaries. |
| Risk of “Everybody’s Job Is Nobody’s Job” |
This structure is a good fit for dynamic, DevOps-heavy environments where security needs to be continuously integrated into development and operations. However, it requires team members who can balance deep security expertise with enablement skills.