Application Security Engineer Archetypes

As an application security engineer, I work in the fast-changing, highly dynamic security landscape where my primary goal is to safeguard software applications and products against the rise of threats.

My first security engineering role was at Intel, a large corporation with a medium pace of software product delivery. In that environment, I worked on a diverse array of challenging problems focused on a select subset of products. My work spanned Threat Modeling, Security Design reviews, Cryptography implementation reviews, Fuzzing, building security workflow in the CI pipeline, and onboarding various vendor security tools. This pace of product delivery allowed for a unique blend of breadth and depth in my skill set.

My next role was at AWS, a large organization known for its fast pace across the industry, and my scope of responsibilities expanded significantly. I now had to cover a multitude of services with the expectation to be strong in multiple domains. Security design reviews became my core focus and it involved collaboration with numerous stakeholders to define and implement security controls before a service went live. Product delivery milestones such as preview, beta, and general availability (GA) became critical checkpoints. I had to demonstrate a strong sense of ownership, urgency, and drive. Additionally, project management skills became indispensable for my success. On the flip side, the nature of that role often limited my involvement in implementing in-house security tools.

Now, in my current role at Plaid as a product security engineer at a mid-sized engineering heavy organization, I operate in an environment of lean security teams. Beyond performing security reviews, I find myself navigating the responsibilities of actively implementing security tools, defining security controls, handling vulnerability management and the bug bounty program, interfacing with my key stakeholders (development teams, product managers), etc. Here, I am demonstrating my skill sets that balance both the breadth and depth of product security.

Through these experiences, I've come to observe and understand the nuanced differences in application security roles across varied organizational sizes and paces.

In this article, I’ll walk you through:

• How the role varies depending on factors like company size, product delivery pace, and platform maturity
• The archetypes for application security engineers based on the patterns in the role
• The key traits for each of these archetypes

First, what exactly is application security? At its essence, application security involves implementing a wide set of measures and practices to secure software applications from vulnerabilities and cyber threats. It is a holistic approach that spans the entire software development life cycle (SDLC), ensuring applications stand resilient against potential exploits.

The AppSec engineer typically has multifaceted responsibilities primarily aimed at securing the SDLC as a defender. These responsibilities encompass risk assessment, championing secure coding practices, orchestrating security testing, integrating security into the development life cycle, assisting (and in some cases driving) incident response, and fostering a security-aware culture.

My experience and observations have led me to bucket the role into three categories based on the company size - AppSec Engineer in a Centralized Organization, Dedicated AppSec Engineer, and Security Partner Engineer.

As an AppSec Engineer in a Centralized Organization, you exhibit breadth as they manage extensive portfolios of diverse technologies, services, and products. Most organizations start with this structure. Project management skills become paramount as the responsibilities of securing multiple services/products. The challenge lies in maintaining consistency and coherence across a myriad of projects.

As the organization and its products mature, working with a centralized security organization becomes a bottleneck or adds overhead. A need for a dedicated application security engineer becomes evident. A dedicated application security engineer is a core member of the product team. With a breadth and depth of skills, they act as subject matter experts for specific services or products pertaining to a specific domain. Their role hinges on collaborative efforts within the service/product team, requiring seamless integration of security measures within the product development process.

At times, business priorities and the criticality of a product create a sense of urgency, demanding its swift and secure delivery to customers or users. In such scenarios, an AppSec engineer from the centralized organization acts as a security partner. This engineer is assigned to minimize the overhead of communication and avoid the necessity of extensive context sharing. This strategic deployment aims to drive a smooth and efficient engagement with all stakeholders during times of urgency.

Most application security engineering roles define a single, uniform set of expectations for operating within that company. Throughout my career, taking on these roles at different companies has allowed me to cluster my experience into these distinct patterns.

As we look at how each role of an application security engineer caters to specific organizational needs and priorities, we can highlight these four archetypes:

The Orchestrator

Key Traits: Strong technical breadth, navigating organizational complexity, and project management skills.

Primary Focus: Managing a diverse portfolio of services and products, ensuring security measures are applied consistently.

Strengths: Thrives in environments where coordination and oversight across multiple projects are paramount.

The Builder

Key Traits: Proficiency in development and automation, strong problem-solving skills, creative and innovative.

Primary Focus: Building scalable security tooling and automation to security practices, developing solutions to address security challenges efficiently, integrating security into the development lifecycle.

Strengths: Ability to create scalable and efficient (at times novel) solutions to security challenges, capacity to automate security processes, increase efficiency and reduce human error, and innovation in developing new tools and techniques to enhance security practices.

The Specialist

Key Traits: In-depth technical expertise within a specific domain, and excellent collaboration skills.

Primary Focus: Serving as a subject matter expert for a particular service or product, seamlessly integrating security measures into the development process.

Strengths: Excels in scenarios where specialized knowledge (ex. Authentication expertise) and close collaboration with development teams are crucial.

The Rapid Responder

Key Traits: Quick decision-making, strategic thinking, effective communication.

Primary Focus: Ensuring the secure and swift delivery of critical products or services during urgent situations.

Strengths: Well-suited for high-pressure scenarios where a balance between speed and security is imperative.

I would say, the builder archetype can be present in both the centralized application security team and the dedicated application security engineer role. A centralized application security team focuses on developing security tooling and automation to scale security practices across the organization's diverse portfolio of technologies, services, and products. The primary focus is on creating tools and automation that can be deployed across various projects to enhance security measures consistently.

In contrast, as a dedicated application security engineer, they collaborate closely with the service or product team to develop security tooling and libraries tailored to the specific needs of the domain or project. In both roles, the Builder archetype plays a critical role in advancing the organization's security posture by developing innovative solutions and automation that enhance security practices and reduce risk.

Having said that, let’s review prime traits essential for these diverse roles

Versatility:

Primarily applicable to the Orchestrator who is required to switch between managing multiple security projects simultaneously. For instance, they oversee the implementation of secure coding practices (Review IaC modules, updates to existing auth/cryptography components) in one project while conducting a security assessment of controls for another. Their ability to adapt to different tasks and contexts demonstrates versatility.

Primarily applicable to the Builder who needs to work on various security automation projects, such as developing automation for vulnerability scanning, creating custom security dashboards, or validating the implementation of security control. Their versatility allows them to tackle diverse automation tasks effectively.

Readiness to take on added responsibilities:

Primarily applicable to the Specialist who is asked to lead a new security initiative within their domain, such as developing and implementing a secure coding training program for up-leveling developer's secure coding skills or conducting a comprehensive security assessment for a critical application. Their readiness to take on these added responsibilities demonstrates their commitment to enhancing security within their area of expertise.

Ability to handle learning curves:

Primarily applicable to the Rapid Responder who needs to quickly familiarize themselves with new product initiatives, and applicable security controls/techniques during a high-pressure situation or urgent product release. Their ability to efficiently learn and apply new concepts ensures they can effectively address security challenges as they arise.

Communication skills:

Primarily applicable to the Orchestrator who needs strong communication skills to effectively coordinate security efforts across multiple teams and stakeholders. They need to convey security requirements to development teams, provide updates to management on project progress, and facilitate discussions between different security functions within the organization.

Effective context handling and context sharing:

Primarily applicable to the Dedicated App Sec Engineer who must effectively handle and share context within their product or service team to ensure that security considerations are integrated into the development process seamlessly. This includes providing relevant security guidance, implementing security control and communicating security priorities based on the context of the project.

Balancing breadth vs depth:

Primarily applicable to the Specialist who must balance deep technical expertise in their specific domain and a broad understanding of overall security principles and practices. For example, while conducting a security review for a specific application, they need to delve into its architecture, code, and best practices (ex. making sure AuthN/AuthZ is done consistently across all services/products) to consider broader security implications.

Final Thoughts

I’d argue that archetypes are not fixed roles but rather depend on the team's needs and the dynamic nature of organizational structures. Let’s review what are some of the factors that influence a role to evolve.

Flexibility Based on Team Needs: The roles carry varying responsibilities and skill sets, which evolve based on the organization's priorities. Teams prioritize certain aspects of security at different times, leading individuals to transition between archetypes as needed to address these priorities effectively.

Evolution of Roles: Individuals start in a specific archetype based on their skills and the team's immediate needs. However, as they gain experience and take on more responsibilities, their roles evolve to encompass different archetypes. For example, someone initially hired as a Specialist gradually takes on more strategic planning and coordination responsibilities, eventually transitioning into an Orchestrator role.

Stacking Archetypes: It's common for individuals to stack different archetypes over time as they gain experience and diversify their skill sets. For instance, someone begins as a Rapid Responder, focusing on quick solutions to immediate security threats. Still, as they develop expertise in various areas, they also take on responsibilities aligned with other archetypes, such as Specialists.

Adaptability and Growth: Embracing different archetypes allows individuals to remain flexible, continuously learn new skills, and contribute effectively to the organization's security objectives.

Moreover, application security roles keep evolving, and folks transition between archetypes, stack different roles, and adapt to changing priorities to effectively meet the organization's security requirements. This flexibility and adaptability are essential for success in the dynamic field of application security.

Key takeaway

I realized from writing my thoughts on this that for each archetype, there are individuals who are a great fit and find it gratifying. One way to find out is by sampling the archetype within your role as an AppSec engineer.

If you are a fellow application security engineer, I hope this article will help you think about which of these archetypes would fit you. From there, you can start by reflecting on the kinds of work that energize you, and if you need to leverage job crafting if that’s not the case in your current role.