Role: The Executor
For software developers and architects: here's what you own in application security and what you support.
Implicit and unrealistic expectations are the main reasons why software developers struggle to meet security requirements. This deep dive on the Executor role aims to clarify accountability and set realistic expectations to bridge the gap between development and security folks.
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.
Honestly ask yourself: Do you meet all of them? Where can you or your team improve?
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.
The Executor is one of six roles within the AppSec Ownership Model, which defines clear accountability for everyone involved in developing secure software.