Who is the Catalyst?

The Catalyst is one of six roles within the AppSec Ownership Model and refers to:

Someone who brings external expertise in building AppSec ownership within your company.

This includes:

• AppSec consultants or guides

• AppSec trainers

This is, of course, not an exhaustive list and you may find these boundaries useful in other contexts outside of AppSec as well.

What AppSec domains can the Catalyst support?

The Catalyst can’t own AppSec domains, they can only support. So here’s what they can focus on:

Security Tooling | Provide current market insights on what solutions are available and how to select and integrate tools to support your team.

A good guide is independent. That means they don’t work with just one vendor, but help you choose something that fits your needs individually.

Security Strategy | Provide guidance in navigating the complexity of AppSec.

This includes setting up processes for Vulnerability Management and Incident Readiness, and providing resources to customize for every AppSec domain.

Security Culture | Provide guidance for building a strong security culture and a company-wide security champions program.

A good guide knows how important culture is and will help you build an AppSec program that is centered around your developers, not your security team.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Catalyst accountable for?

Here’s what you can hold your Catalyst accountable for:

• Coaching the AppSec lead and acting as a strategic sparring partner.

• Reviewing and advising on tooling, processes, and structural decisions.

• Spotting blind spots, challenging assumptions, and providing external validation.

• Supporting the setup of a scalable AppSec strategy and guidance for developing a strong security culture.

• Providing best practices, templates, and playbooks to accelerate internal decision-making.

• Maintaining external perspective and bringing in relevant market, tooling, or ecosystem insights.

What accountability must stay internally?

Here’s what you must strictly own internally:

• Delivering or owning policies, findings, or operational outcomes.

• Acting as a direct contact for developers or security champions.

• Taking over operational responsibilities within product or security teams.

• Creating dependencies or acting as a “shadow AppSec lead”.

If you let a consultant take ownership of these areas, you’ll become dependent on them in the long run. They can support you, but you must be careful not to externalize accountability.

Who does the Catalyst work with?

There is only one role the Catalyst should work with:

Owner (e.g., AppSec lead) | Only with a clear mandate and by invitation.

They may work with interim stakeholders (e.g., CTO or an architect) during the initial phase to facilitate alignment and prepare for the takeover of an internal owner. If there is no internal owner, appointing one should be the highest priority.

They can work with other roles initially, e.g., as a trainer for software developers, but this should not turn into a long-term dependency and shouldn’t happen without the Owner’s explicit approval.

Who is the Advocate?

The Advocate is one of six roles within the AppSec Ownership Model and refers to:

A developer who’s interested in security and has deepened their security knowledge.

A security champions program is a decentralized approach to extend your central AppSec team with people embedded in development teams that advocate for security and act as a bridge between teams. Anyway, we should never forget that they are mainly developers, not security staff.

What AppSec domains does the Advocate own?

As the Advocate, you focus on the two AppSec domains you already own as an Executor, plus one additional domain:

Secure Design | Drive threat modeling exercises and ask security-related questions.

This domain is already one of your main focus areas as developer, but as Advocate you are expected to wear the security head in every design-related action and support your team with your security expertise.

Secure Coding | Spread security knowledge within the team and pay special attention to code reviews and the security-related test cases.

I can’t stress enough that you don’t need to do everybody’s security work. Don’t write everyone’s tests, but point out if security-related test cases are missing. As the Advocate, your main task is awareness and support, not compensation for other people’s bad habits.

Security Culture | Drive secure behavior within the team by being a role model and advocating for security.

Everyone can shape culture, but as the Advocate, your passion for security naturally serves this purpose. Cultural change is all about behavior and with you being a role model, you can inspire your peers to improve for themselves.

What AppSec domains does the Advocate support?

Being the Advocate for security comes with additional responsibilities and opportunities to shape your company’s AppSec program. While you don’t own every single domain, you can contribute to all of them.

Security Tooling | Provide valuable feedback on usability and raise recurring needs.

Security Strategy | Provide feedback and insights from day-to-day development to guide improvements based on real-world needs.

Your AppSec lead needs your feedback to shape the AppSec program in a direction that actually serves the developers. As you are still part of the development team, you’re best positioned to ensure they have the right context to decide which tools to provide and which strategy to follow.

Incident Readiness | Act as a point of contact for incident triage within the team and help identify the right people to support technical analysis.

When things go south, you are maybe best suited as support for the AppSec team to figure out what is going on and make sure your product is safe again soon. That doesn’t mean you’re meant to lead the process.

Vulnerability Management | Support your project leader and highlight recurring patterns for proactive improvement.

You can support your project leaders when they don’t know how risky certain issues are or how much effort it will take to remediate them. You are invited to look for patterns and suggest improvements in and across teams.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Advocate accountable for?

Here’s what you can hold yourself accountable for:

• Supporting developers in applying secure practices and improving their skills.

• Bringing security topics into daily work and team discussions.

• Facilitating basic threat modeling and secure design thinking.

• Identifying security gaps that need central guidance or structural fixes.

• Providing input on the usability of tools and effectiveness of guidance.

• Sharing team-level insights on recurring needs and repeated issues with the AppSec lead.

View this list as an all-you-can-eat menu. These are areas where you can do more. You can start small with improving your own security-related skills and build a strong security community together with other Advocates. Nobody expects you to know and solve it all on your first day.

What is the Advocate NOT accountable for?

Here’s what you are explicitly not expected to do:

• Taking over security responsibilities from other team members.

• Replacing the project leader in planning or prioritization.

• Implementing or enforcing central security measures.

• Making policy decisions or setting global standards.

• Leading incident response independently without coordination.

• Acting as permanent substitutes for the AppSec lead.

While the first list was the tasty menu you could choose from, this list is the ‘don’t eat that shit’ list. Eating toxic mushrooms won’t serve you well. If your security champions program expects those things, push back hard. That’s the path to an unhealthy security champion role you don’t want to carry.

Who does the Advocate escalate to?

As the Advocate, there are two roles you can escalate to:

Gatekeeper (e.g., project leader) | For team-internal issues that block secure development, e.g. missing capacity, unclear ownership, or lack of priority.

This is your main escalation path as a developer anyway, so you can still use it to escalate security-related issues within your daily work and team.

Owner (e.g., AppSec lead) | For issues that require structural support, central guidance, or cannot be resolved within the team, as well as any conflicts, they may not solve locally.

The Owner should have your back and is your central point of contact when things can’t be solved locally. They should be in contact with the executive leadership, so they are can further escalate things if necessary.

In emergency cases, you as the Advocate may help coordinate local response efforts or step in when the Owner is unavailable, based on predefined rules. However, this is not your primary responsibility and should be clearly scoped.

Finally, you can always escalate to your security champion community. You are not fighting and advocating alone. You hopefully have your community and network to support your local efforts, learn from each other and have fun.

Who is the Backbone?

The Backbone is one of six roles within the AppSec Ownership Model and refers to:

Everyone steering the company at the highest level.

This includes:

• Any C-suite roles

• CISOs

This is of course not an exhaustive list. Anyway, within the model, they are all grouped together because from an AppSec point of view, their contribution and accountability is pretty similar.

What AppSec domains does the Backbone own?

As the Backbone, you need to focus on two AppSec domains:

Security Strategy | Own strategic direction, ensure alignment with business goals, and make final decisions on investment and risk.

Security Culture | Lead by example and embed security into organizational values.

You will need to find an AppSec lead to own your AppSec initiative at an operational level. They should be enabled and trusted to come up with a solid security strategy, but the final decision is yours.

In addition, you must be serious about AppSec yourself, otherwise your AppSec lead has no chance to shape and nurture a good security culture.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Backbone accountable for?

Here’s what you can hold yourself accountable for:

• Approving the overall security strategy and investment decisions.

• Supporting the AppSec lead with clear mandate and organizational backing.

• Ensuring that security priorities are reflected in business planning and governance.

• Leading by example and reinforcing security culture through visible commitment.

• Taking responsibility for accepted risk at organizational level.

What should the Backbone delegate?

Here’s what you should delegate:

• Defining technical security standards or tooling.

• Managing day-to-day application security execution.

• Performing reviews, risk ratings, or technical assessments.

• Communicating directly with product teams on implementation details.

Who does the Backbone work with?

As the Backbone, there are only two roles you need to work with regularly:

Owner (e.g., AppSec lead) | For strategic alignment and decision preparation.

Gatekeeper (e.g., project leaders) | For prioritization and risk visibility within projects.

You may also work with your security champions (Advocate) indirectly by enabling a culture that values their contributions.

Who is the Owner?

The Owner is one of six roles within the AppSec Ownership Model and refers to:

The person who takes ownership of AppSec and mainly drives the initiative.

This includes:

• AppSec lead (operational owner)

• AppSec teams (shared responsibility)

• CISO / C-suite (strategic fallback if no dedicated owner exists)

One could argue that ownership ultimately lives within the executive leadership, but for the sake of this model, we refer to the person who mainly drives and represents AppSec within the company.

What AppSec domains does the Owner own?

As the Owner, you mainly focus on four AppSec domains:

Security Strategy | Define the overall strategy with long-term goals and KPIs to measure progress.

The strategy needs to be aligned with business goals and approved by the executive leadership (Backbone). Close collaboration between both roles is absolutely necessary.

Security Tooling | Select and configure security tools in alignment with the overall strategy.

This includes anything from scanners to vulnerability management platforms or runtime protection. The requirements for each tool should be derived from the base in collaboration with the development teams.

Incident Readiness | Define and train processes for incident response and zero-day vulnerabilities.

As the Owner you should provide process definitions, templates and checklists, as well as detection mechanisms. Everything that saves time and reduces error under pressure. Of course these structures need to be built and derived from the operational reality.

Security Culture | Detect cultural threats and actively shape cultural change.

A strong security culture will make every other effort you take more efficient and sustainable. Nobody can change culture alone, but someone must attempt to shape it with intention and a plan, one step at a time.

What AppSec domains does the Owner support?

As the Owner, you’re involved in all domains. These are the remaining domains, you only support:

Secure Design & Secure Coding | Define standards and provide best practices for secure design and coding.

Vulnerability Management | Define the process and prioritization rules based on risk.

All these domains must be mainly driven by the development teams, as you won’t have capacity or know all the details to own them. They are the main trap where AppSec leads burn themselves out when they take on too much in those areas. Make sure you strictly separate between operational details and defining structure.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Owner accountable for?

Here’s what you can hold yourself accountable for:

• Designing and evolving the AppSec strategy, including roles, responsibilities, policies, and processes.

• Making structural decisions on security tooling, training programs, and cross-team standards.

• Prioritizing global security efforts based on input from teams, risk exposure, and business impact.

• Defining how threat modeling, vulnerability management, and risk acceptance are handled across teams.

• Defining roles and responsibilities within the incident response process and ensuring readiness across involved teams.

• Enabling security champions through clear guidance, training resources, and structured feedback.

• Ensuring continuity of strategic AppSec leadership, including defined delegation in case of absence.

• Supporting awareness and compliance activities in alignment with strategic goals.

• Defining relevant KPIs for application security and regularly reporting them to the executive leadership.

• Actively aligning AppSec goals with business priorities, customer value, and delivery strategy through regular collaboration with the management.

• Temporarily owning unstructured security gaps to prevent risk blind spots with the explicit goal of transitioning them into stable ownership based on field experience.

I know the list is long. If possible, these accountability should be shared by an AppSec team. If you’re alone, make sure you are extra strict in what to prioritize and what to reject at least for the moment. Nobody wins when you ignore your limits and eventually need to give up.

What is the Owner NOT accountable for?

There are certain operational things you need to delegate because you just can’t handle them.

Here’s what you are explicitly NOT accountable for:

• Fixing vulnerabilities, reviewing code, or directly supporting delivery teams operationally.

• Leading operational incident response unless specifically defined as part of the process.

• Making final decisions on budget, procurement, or staffing (that belong to executive leadership).

• Taking over prioritization decisions that belong to product or project management.

• Owning team-level backlogs or covering missing security champions in delivery teams.

• Acting as a full-time trainer or one-on-one coach for teams.

There are other roles accountable for those tasks. If you notice they don’t own their part, help them understand why they must and ask the Backbone to support you up if necessary.

Who does the Owner escalate to?

If you find yourself confronted with tasks, that should not be on your desk, you have two options for escalation:

Gatekeeper (e.g., project leaders) | When security goals are blocked by planning constraints or business pressure.

Use this path when KPIs are not met to figure out why they failed and how they can be supported, to get back on track. Don’t take over for them, just ask and lead them back on track.

Backbone (e.g., executive leadership) | For structural conflicts and priority trade-offs.

Use this path when you run into conflicts with the project leaders and their teams. When you can’t find solutions locally, call your Backbone for support. They ultimately decide if security is their first business priority in that specific case or if there are reasons to prioritize output. In that case, ask them to address the security requirements in their plan, with a clear near-term deadline.

Who does the Owner work with?

Apart from escalation, there are three roles that the Owner can work with:

Backbone (e.g., executive leadership) | For budget and strategy decisions related to AppSec capabilities.

The Owner should report at least quarterly directly to management to keep them informed. There should be a quick way to get their feedback or smaller decisions in between to reduce friction. This collaboration is the necessary foundation.

Advocate (e.g., security champions) | They lead the security champions program, which provides direct feedback from the base.

The Owner will usually lead the security champions program at least in the beginning. Later the security champions might be able to sustain the program themselves, but the Owner still needs to stay in touch with them. They are probably their best connection to the development teams to get honest feedback, needs and requirements to support development teams best.

Catalyst (external/optional) | Whenever they need access to deeper expertise, external validation or strategic sparring partner support.

The Catalyst can be any external coach or consultant that usually works exclusively with the Owner without taking ownership away from them.

Who is the Gatekeeper?

The Gatekeeper is one of six roles within the AppSec Ownership Model and refers to:

The person who sets product direction and protects the team’s ability to execute.

This includes:

• Project leaders

• Product owners

• Scrum masters

This is of course not an exhaustive list. Anyway, within the model, they are all grouped together because from an AppSec point of view, their task is to ensure the product gets developed. This can naturally create conflict with security requirements and that’s expected. The Gatekeeper should be critical and observant if those requirements actually improve the overall security of their product or if they just slow down their team without meaningful impact.

What AppSec domains does the Gatekeeper own?

As the Gatekeeper, you need to focus on only one AppSec domain:

Vulnerability Management | Prioritize remediation of vulnerabilities while balancing other demands.

Vulnerability remediation, bug fixes, or new feature requests? All of them need time and focus from your team to improve the product. As the Gatekeeper, it’s your job to make sure priorities are chosen well. As with bugs, some vulnerabilities might be something you can ignore while others need immediate attention. You are not expected to do the assessment and decide, which vulnerabilities need to get fixed on your own. There should be standards, rules, and tools in place to support you. Anyway, finding the right balance between bug fixes, remediation and feature requests is your game.

What AppSec domains does the Gatekeeper support?

If you cut security work entirely, you can sabotage the effectiveness of the AppSec initiative. Killing security theater is good. Killing useful security work isn’t.

Your team needs time and resources to handle their security duties in a meaningful way. Therefore they need you to actively support them in their domains:

Secure Design & Secure Coding | Provide time and space for secure design and coding activities.

Listen to your team when they initiate security-related activities. When they need to talk about design instead of jumping right into implementation, this will benefit your product and save time in the long run. Trust them.

Incident Readiness | Coordinate delivery-side impact and communication.

In addition, you play an important role when incidents hit, as you are the one who can see the impact on your timelines and communicate accordingly with impacted stakeholders.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Gatekeeper accountable for?

Here’s how you ensure meaningful security takes place in your project:

• Ensuring that security requirements are clearly defined for every delivery.

• Ensuring that security-related tasks are properly included in planning and delivery.

• Prioritizing vulnerability remediation against feature and bug requests.

• Making security trade-offs visible and discussing them openly.

• Escalating when security is deprioritized without conscious risk acceptance.

• Supporting incident coordination and communication if the situation affects delivery or customers.

What is the Gatekeeper NOT accountable for?

You don’t need to become the security expert. Vulnerabilities should be pre-assessed or at least you should have rules and standards at hand that help you sort quickly through them without guessing risk.

Here’s what you are not accountable for:

• Defining detailed security requirements or implementation details.

• Deciding on technical severity or exploitability of findings.

• Defining risk based standards or deadlines for vulnerability remediation prioritization.

That information should be presented by either your development team or the AppSec team. If it’s missing, ask for it.

Who does the Gatekeeper escalate to?

If you struggle to decide whether certain security activities are meaningful or if certain vulnerabilities should be remediated in the next delivery period, you have two roles to support your decision-making.

Advocate (e.g., security champions) | For technical input, missing context, or when support is needed to understand the impact of a security issue.

For the small details, security champions are the perfect partner to discuss details with. They are developers with security expertise and can help you decide on a day to day basis. If your company doesn’t run a security champions program, just ask experienced developers. You likely know best who might be able to answer your questions.

Owner (e.g., AppSec lead) | For unclear security priorities, accepting known risk or when security work falls short due to delivery deadlines.

The second point of contact is your AppSec lead or team. When general guidance or tools are missing and you think you need structural level support, the Owner is the right person to contact. If there is no dedicated owner yet, escalate it to your management, as they implicitly own what is not explicitly delegated.

If at a certain point security requirements and delivery requirements can not be balanced properly, you may need to escalate and let this decision be made on a higher level. You can escalate jointly with the AppSec lead to the executive leadership in case the risk acceptance needs to be approved. Anyway, remember that all accepted risks must be documented, made visible to all stakeholders, and scheduled for remediation.

Who is the Executor?

The Executor is one of six roles within the AppSec Ownership Model and refers to:

Everyone who actively shapes the software product by design or by writing code.

This includes:

• Software developers

• Software architects

• Dev(Sec)Ops (if we think of infrastructure as code)

This is of course not an exhaustive list. Anyway, within the model, they are all grouped together because from an AppSec point of view, their contribution and accountability are pretty similar.

In practice, their focus may shift within their field of accountability as they execute different tasks within their software development lifecycle.

What AppSec domains does the Executor own?

As the Executor, you need to focus on two AppSec domains:

Secure Coding | Write secure, maintainable code in your daily work.

Secure Design | Lead secure design decisions within your project scope.

If you are a software developer, you may focus less on secure design than an architect, but as a development team, you collectively own those two AppSec domains. You’re the only role that can truly own these domains, because you know your product best.

While you are the expert for your code, you may not be the security expert. We will figure out within the accountability section how the security team can support you within your domains.

What AppSec domains does the Executor support?

When developing secure software is the main goal of application security, it naturally fails when you are no longer able to develop software in the first place. That’s why the whole AppSec program should be built to support and enable the Executor role.

And again, this can’t be done without you, as the Executor. You know what works best for you and what slows you down. That’s why your feedback is necessary to shape the AppSec program within your company.

Here are three additional domains where you should actively support:

Security Tooling | Use tools and provide feedback on any friction.

Tell your security team or project leader, whether the tools actually serve you on a daily basis. Be concrete on what slows you down.

Vulnerability Management | Remediate vulnerabilities in daily work based on project priorities.

In a perfect world, remediation should be scheduled within your project, but in case it’s not: fix whatever comes your way whenever it is suitable.

Incident Readiness | Detect and report suspicious behavior or unexpected system states.

Detecting incidents early can reduce damage along the way. Often there won’t be automatic tools in check of they will just not cover everything. Trust your guts when something seems off and address it. It’s better to be wrong than to let an ongoing attack slip through.

All three of them are owned by other roles within your organization, but your contribution can shape and improve their work.

Now that you see the bigger picture, let’s make accountability explicit.

What is the Executor accountable for?

Here’s what you can hold yourself and your team accountable for:

• Designing secure systems right from the start, not fixing security somehow later.

• Using approved tools in the development workflow (e.g. linters, scanners).

• Asking for clarification when security requirements are missing or unclear.

• Writing secure, maintainable code based on best practices.

• Actively identifying knowledge gaps and improving your secure coding skills.

• Writing meaningful tests, including security-relevant scenarios.

• Reviewing code from a security and quality perspective.

• Selecting appropriate libraries and avoiding insecure packages.

• Keeping dependencies up to date, or flagging outdated ones until they’re fixed.

What is the Executor NOT accountable for?

If AppSec responsibility is not clearly distributed within your company, you may feel responsible to fill in the blanks that are just out of scope for you.

So, here’s what you are NOT accountable for:

• Defining tooling strategy or security policies.

• Making final decisions on risk, severity, or remediation scope.

• Coordinating security initiatives across teams.

• Coordinating incident response.

In practice, whenever you are confronted with expectations or responsibility in those areas (e.g., in an emergency), you can take over, but you should be aware that this is not what your role is expected to do and it’s nothing you should take over in the long run. If those gaps exist, they need to be addressed by your organization on a higher level.

Who does the Executor escalate to?

As the Executor, there are only two roles you are expected to escalate to:

Advocate (e.g., security champions) | For technical questions, missing guidance, tool-related issues or anything that feels security-relevant but cannot be solved locally.

Gatekeeper (e.g., project leaders) | For priorities, backlog planning, dependency updates, or efforts that need coordination within the team.

If your organization doesn’t have security champions, you may need to escalate directly to your security team or try to solve everything with your project leader.

Why control doesn’t work

The old way to do security was based on control. Someone decided who can be trusted, what behavior is acceptable and what needs to be blocked entirely. This approach has one big problem: it works on paper, but is often far from reality. It can actually harm your company’s core business if software developers are no longer able to develop software. At least not efficiently.

What actually works

Trust works. Freedom works. Collaboration works.

Don’t treat your software developers as one of the biggest threats to a secure product. In fact, they can be your biggest asset. Most developers aren’t trying to build insecure products. They are not the ultimate evil you need to protect against. Often, they just miss security knowledge, are pushed by deadlines and kept on a short leash to not think for themselves. Often security is just getting in their way instead of actually enabling them to build a secure product. That’s what we need to fix.

Who is involved in developing secure software?

The developer is building the product. The product is what brings your company money and pays for your paycheck. So I think we can agree that the main character in software development is the software developer. Without someone actually writing code, there will be no product to secure. They drive the software development lifecycle (SDLC). Within the AppSec Ownership Model, I call them the Executor.

Of course, you as the AppSec Lead want them to build secure software, thus turning their SDLC into a secure SDLC. You are the Owner. You educate them. You trust them. You help them to change their behavior. You provide them with everything they need to do their duty.

But there is one person who gets in your way. The project leader is responsible for managing time and resources. They are the Gatekeeper. It’s their job to ensure their team’s time is spent well, so you need to convince them or they will just not let you interfere with their team. They are a valuable asset to you, too. They can help you build security that serves their team, as they will tell you to your face when you expect bullshit tasks from them or their team.

You may find Gatekeepers who are open to work with you, but some may be harder to convince or just refuse to collaborate at all. To get them in line, you need a strong Backbone. Without support from the executive leadership, you will fail.

That’s the bare minimum. Four roles.

How to change behavior

The fifth role is the Advocate. When you start your AppSec initiative, you won’t have a structured security champions program, but you will for sure have some secret champions already advocating for security. It doesn’t matter if they have an official mandate yet or if they just do what they do. You need them.

Developing a strong security culture is what makes your AppSec program sustainable, but it’s hard to achieve. It’s a long journey, but it starts with one intentional step. Changing culture means changing behavior. And your security champions already are role models in what good secure behavior may look like. By building a strong security champions program, you already are on the path to that strong security culture. You just need to keep going and trust the process.

How to speed things up

No, I’m sorry. I don’t have the secret hack to speed up your culture development. But you can speed up your own learning curve as the Owner and reduce your trial-and-error cycles, which will get you moving faster.

We are talking about external expertise. Whenever you hire a coach or consultant, you leverage their experience to learn faster and avoid mistakes they already made. While this can be a big opportunity, it can also be a trap. If you externalize accountability you make yourself dependent on them. That’s why we cover the Catalyst role as the sixth role within the AppSec Ownership Model. The role is optional, but if you choose to use it, you need to know how to avoid the trap and stay independent.

How to get started

We covered all six roles involved in developing secure software. If my point of view resonates with you, feel free to explore the AppSec Ownership Model and use it to clarify accountability within your AppSec program. Accountability is the foundation that everything else is built on.

This model is grounded in my personal experience and I’m more than happy to discuss it with other practitioners who are committed to building security for the real world, not just on paper.

Overview

Within the AppSec Ownership Model we split the AppSec field into seven domains:

1. Secure Design

2. Secure Coding

3. Security Tooling

4. Vulnerability Management

5. Incident Readiness

6. Security Strategy

7. Security Culture

We will now dive into each of them to provide you with a rough idea of what they are about and where to start.

Secure Design

You probably heard about shifting left. This means adding security as early as possible in your SDLC. And the earliest phase is your design phase, so that’s where we start. You probably already learned it the hard way that any big flaws in your design are the hardest to fix later.

Here are some measures you can implement:

• Threat Modeling

• Secure Design Principles

• Security Requirements

If you are dealing with a lot of legacy, start by thinking about security requirements for every new feature and adding them to your acceptance criteria.

Secure Coding

When I studied computer science, security was barely touched upon. I hope this is going to change in the future, but for now companies need to fill the gap. Instead of treating developers as the threat that needs to be controlled, companies should train them properly in secure coding.

• Define guidelines and standards

• Offer continuous training opportunities

• Perform code reviews

It’s easy to tell developers to write secure code, but you need to make explicit what secure means to you. Whatever measures you take, make sure they match developers’ reality, and involve them in developing these standards.

Security Tooling

When I was handed responsibility for AppSec, one of the first requirements was: ‘Find us a good SAST scanner’. While this sounds good on paper, it would have filled backlogs and created a lot of noise, but it wouldn’t have really improved the products.

There are many different tools you could add:

• Scanners (SCA, SAST, DAST)

• Vulnerability Management Platforms (ASPM)

• Runtime Protection (WAF)

Whatever you include, make sure it reduces friction, is properly configured and frees up capacity for feature development. Tools should be added with intention and be included in processes where they actually improve something.

Vulnerability Management

I would go for a proper vulnerability management process first, before adding new tools. Developers are often aware of vulnerabilities or outdated dependencies, but they might have learned that fixing those issues is not a priority.

Define the process and show them that fixing vulnerabilities matters:

• Reduce the noise

• Prioritize what actually matters

• Fix it

Start small. Take the vulnerabilities they already know, establish a process, and add more vulnerability detection afterwards. It’s a never-ending story, so you’d better make it a good habit.

Incident Readiness

No matter how well you are prepared, nothing is 100% secure. You’ll end up firefighting sooner or later. So of course we need to prepare for the worst case:

• Zero-Day Response Process

• Incident Response Process

• Responsible Disclosure Process

Start by defining these processes and clarifying responsibilities. Who should be informed? Who is going to lead the process? If you at least have some plan on paper, you have something to work with when you need it. From there you can improve and train your response.

Security Strategy

With so many measures available, someone needs to have a plan. Developing your AppSec program is pretty individual to your company, but you need for sure some sort of strategy to get where you want to go:

• Set long-term goals

• Fix the current bottleneck

• Measure your progress

As an AppSec Lead, you need to build your network within the company, collect everybody’s needs, wants and struggles, sort through that data, come up with a strategy, and finally take it to your management to make sure your AppSec goals are aligned with their business goals. If they reject your strategy, ask why. Try to understand their goals and adjust.

Security Culture

Maybe the most important long-term goal you should set is to build a strong security culture. If culture works against you, even your best strategy will fail under pressure. Culture is what makes your AppSec program sustainable and resilient.

• Identify ‘bad habits’

• Shape culture with intention and involve everyone

• Build a Security Champions program

While culture change is by far the biggest challenge you can face, it doesn’t need to be painful. You will not change culture in one day, month, or year. But you can start small, build healthy security routines and reward desired behavior. And if something fails? Analyze it and adjust.

There is only one hard criterion under which I would consider this goal failed: if you can’t get the management behind you, you are fighting an already lost battle.

I came up with the AppSec Ownership Model to create a shared understanding with my client of what AppSec ownership actually means. I wanted to put something that was already clear in my head on paper to build their AppSec program on this foundation. You can’t address problems if you don’t know who is accountable for solving them.

What is Application Security?

What are we actually talking about? Developing secure software? Application Security?

Application Security includes every action you take to ensure that the software you build is and remains secure.

The simple reason I came up with this definition is that you need actions to turn an insecure software development lifecycle (SDLC) into a secure SDLC. If you don’t turn thinking into actions, you are just designing on paper, not in the real world.

What makes a SDLC secure?

Now that we know what we are talking about. What actually turns the SDLC into a secure SDLC (SSDLC)?

If you think of AppSec as a big cake, here’s how I would slice it:

1. Secure Design

2. Secure Coding

3. Security Tooling

4. Vulnerability Management

5. Incident Readiness

6. Security Strategy

7. Security Culture

Who needs to take action?

I came up with five mandatory roles and one optional role that share AppSec ownership:

1. The Executor (e.g., software developers)

2. The Owner (e.g., AppSec lead)

3. The Gatekeeper (e.g., project leaders)

4. The Backbone (e.g., executive leadership)

5. The Advocate (e.g., security champions)

6. The Catalyst (e.g., any external expertise) - optional

Every role links to its own deep dive where we:

• define and assign the role

• explore which domains they touch

• clarify accountability

• see which roles they interact with

Can you just give me the bigger picture?

We’ve got seven domains, each of which needs an owner and we’ve got six roles that could own something in theorie. In practice, only the five mandatory roles should take ownership. Externalization of accountability would create long-term dependency and we want to avoid that.

Here’s the AppSec Ownership Model at one glance: