Role: The Gatekeeper
For project leaders: Enable secure development without slowing your team down.
Security has a bad reputation for slowing teams down. Sometimes that’s deserved. We call it security theater. This deep dive on the Gatekeeper role is about using your power to make room for security that matters and cut the bullshit.
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.
The Gatekeeper is one of six roles within the AppSec Ownership Model, which defines clear accountability for everyone involved in developing secure software.