DevSecOps titles extravaganza: AppSec, Security Engineering, Product Security and more! – SecAdvent Day 20

 Application simply aren’t what they used to be.

Before cloud and DevOps arrived, apps were made up of packaged code and libraries, shipped off to be deployed and operated by a crew of sysadmins. The responsibility split was clear – developers should write secure code and keep dependencies updated, and IT/Ops will ensure the servers are patched and the infrastructure is securely configured.

With containers, infrastructure as code, and heavy use of SaaS, the lines are much more blurry in the cloud native world. Infrastructure decisions around OS patching, network ports and much more are made as part of the app – and by the dev teams. Developers also expanded their ops responsibilities, handling on-call duties and outages, and hence getting more access to running systems and customer data.

We often discuss what this change means for developers, who need to take on more security responsibility – but what does it mean for the security team scope? What should an Application Security team cover, now that apps manage infra? Does it now also include Cloud Security? And where does Product Security fit in?

In this post, I’ll enumerate a few options for the scopes and names of security teams in the cloud native era. It’s important to note none of these are perfect, my description of them is generalized, and in practice you can blend them in different ways. That said, I believe they are a useful model to compare your security organization against.

Core application security team

Let’s start from the status quo – keeping the same scope for the Application Security team. Since this is the default state, most organizations use this team scope – at least as a starting point.

The mandate of the Core App Sec team is securing the custom application code and business logic, as well as the open source libraries being used. They typically own the classic AST suite (SAST, DAST, IAST and SCA), developer security education & training, and potentially vulnerability management or bug bounty. In some cases, they may own runtime application protection too, using RASP or WAF tools.

Core App Sec team members typically need to be subject matter experts in secure coding, and have some experience running audits and security code reviews. They need good developer empathy to collaborate with dev, which in turn requires some ability to understand or relate to code – but don’t require full software development credentials.

The main advantage of sticking to a core App Sec team is the tenure it has in the industry. It’s easier to hire professionals with experience across the team domain, tools and practices are well documented, and most of the industry will assume an App Sec team looks like this.

While the scope of a Core AppSec team is the status quo, their methodologies have often become more dev-empowering. Companies like Invision and other partner each App Sec person to several dev teams, to foster better collaboration. Many others run security champions programs, helping them get scale & embed more security expertise within the dev team.

Security engineering team

Automating security steps is key in a modern development environment, for two main reasons:

1. Fast CI/CD pipelines leave no room for manual review, requiring any security controls to be fully automated, likely as a test built into the pipeline or monitoring post deployment
2. While developers need to build security into their regular practices, they are not security experts. Automated tools need to have embedded security expertise, to help make secure decisions at scale.

However, building and operating security tools is not easy, especially in large organizations where different dev teams have vastly different requirements. To help boost automation, some organizations created dedicated security engineering teams, who focus on building internal tools to bolster security.

Security engineering teams are made up of software engineers with a slight bias for security, and operate like a complete DevOps engineering team. They typically build, deploy and operate the services they build, and use the same methodologies other engineering teams use to run their agile processes and manage product backlog.

If the volume of work isn’t big enough to warrant its own team, this same activity is typically embedded into the Core App Sec team. However, while teams titled “Security Engineering” are pretty consistent in their charter, individuals with the (increasingly common) “Security Engineer” title vary greatly in their responsibilities. Some are software engineers as described, while for others the “Engineer” part of the title refers to the security realm instead.

Security engineering teams are a great way to truly level up the amount of automation, and are a great parallel team to Platform or SRE teams. In fact, in quite a few cases the platform team’s scope has been expanded to include building and operating such security tools. It’s also a great way to get software engineers into the security team, helping with both the talent shortage problem and with building more dev empathy in the security team.

WITH CONTAINERS, IAC, AND HEAVY USE OF SAAS, THE LINES ARE MUCH MORE BLURRY IN THE CLOUD NATIVE WORLD. INFRASTRUCTURE DECISIONS…ARE MADE AS PART OF THE APP – AND BY THE DEV TEAMS.

PRODUCT SECURITY / CLOUD NATIVE APP SEC TEAM

The most recent addition to the title parade is the Product Security team. These teams have a bigger scope, that includes not only the application code itself, but everything to do with the product. Most notably, two key additions are Cloud Native Application Security (CNAS) scope and security features.

CNAS scope includes the cloud-native infrastructure components that are now managed by developers. The most common example is containers, where choosing and patching the Operating System (OS) is handled by dev (via Dockefiles and builds), unlike VMs which were handled by central IT/Ops. A close second is Infrastructure-as-Code components, such as ensuring Terraform plans, Kubernetes configurations and Helm charts are properly secured.

This expanded CNAS scope means Product Security teams work across a bigger portion of the SDLC. It includes more engagement with production deployments and even operations, leading to overlap with the more ops-focused Cloud Security team. In practice, cloud-native development means cloud security is affected by both dev & ops teams, and Product Security teams cover the former.

The other new realm of responsibility, security features, is a bit more business oriented. As awareness of the importance of security grows, many products aim to differentiate on their security capabilities, or even build dedicated security-oriented features and products. Deciding what security capabilities are of value requires security understanding that dev teams may not have – but security teams do. Product Security teams often embrace an explicit role here, collaborating with product management more than ever before

Product Security is a new title and scope, and is still being defined. Given its broader scope, it’s often a parent title or group, which encompasses the other mentioned teams. Adrian Ludwig, Atlassian’s CISO, phrased it best saying “Product security’s goal is to improve the security posture of products and represent customers’ security expectations internally to the development team”. The title is used by other companies such as Twilio, Deliveroo and others, and is my personal favourite.

WHAT ABOUT THE DEVSECOPS TEAM?

You may have noticed I didn’t name a DevSecOps team, and that wasn’t by chance. Like DevOps, DevSecOps isn’t a team, it’s a movement, meant to embed security into the core dev & operations work. In my opinion, it shouldn’t be the title of a team.

Want to learn more about what is DevSecOps? make sure to check out this video by Kyle Suero, a Senior Security Advocate from Snyk.

However, just like DevOps teams exist, so do DevSecOps teams… and their mandates vary greatly. At times, they’re really a cloud security team, focusing on operations and runtime security. Other times, they’re more platform-like, with scopes similar to Security Engineering teams. Since the title doesn’t imply a specific set of responsibilities, the scope of a DevSecOps team isn’t something that can really be defined.

However, what all those teams have in common is forward thinking. DevSecOps aims to change how we do security, and DevSecOps teams, wherever their scope, consistently see themselves as change agents. They embrace automation and cloud, favour engineering security solutions over running audits, and aim to empower dev and ops teams to secure their work on their own.

So pick the title that suits your team best, and while it shouldn’t be about the name – make sure every security team is a DevSecOps team.