Hiring an application security (AppSec) engineer

Hiring an application security engineer is often the first step for a company that wants to secure what it builds, not just its infrastructure. The role sits on the border between security and development, which makes it hard to scope and hard to assess. This guide helps you define the role, know what to check and recognise a strong AppSec profile in interview.

Why the role is hard to fill

An AppSec engineer has to be credible with two audiences that do not always speak the same language. Developers expect someone who understands their code, their delivery pressure and their tools. The security team expects someone who knows vulnerabilities, can assess risk and report to leadership.

Candidates who tick both boxes are rare. Many come from development and learned security along the way. Others come from pentesting and learned to read and fix code. Both paths can produce excellent engineers, as long as you know what your role really requires.

Define the role before you search

"Application security" covers several realities. Before writing the ad, settle the main focus of the role.

The tooling and pipeline profile. They build automated checks into CI/CD: static analysis, dependency scanning, secret detection, container image scanning. They tune the tools to limit false positives and make sure results reach the right teams. This is often called DevSecOps.

The review and design profile. They take part in threat modelling for new projects, review sensitive code (authentication, permissions, payments), advise teams on architecture choices and write secure development standards.

The programme profile. They structure the effort across the company: security champions in product teams, developer training, application vulnerability management, remediation tracking, and the relationship with external pentesters and bug bounty programmes.

A company that is just starting often expects a mix of all three. That is realistic if you say so and state what matters most in the first year.

Three more questions complete the scoping:

Which technologies? Languages, frameworks, type of application (web, mobile, API, embedded software). An engineer at ease with an enterprise Java stack will not be immediately effective on embedded code.
How many developers? One AppSec engineer for a few dozen or a few hundred developers changes the nature of the job: you move from case-by-case review to industrialisation.
Where does the role sit? Under the CISO, the CTO or a platform team. That choice decides how much legitimacy the role has with product teams.

The technical skills to check

A common core appears in almost every AppSec role.

Application vulnerabilities. Injection, broken access control, authentication and session flaws, deserialisation, server-side request forgery. The OWASP Top 10 is a floor, not a ceiling.
Code reading. Reading at least one or two of the languages you use, following data from user input to a sensitive function, spotting a logic error.
API security. Authentication, object-level authorisation, rate limiting, excessive data exposure.
Delivery pipeline. How CI/CD works, integrating analysis tools, secrets management, dependency and software supply chain security.
Threat modelling. Breaking down an application, identifying trust boundaries, prioritising realistic scenarios.
Applied cryptography. No maths required, but the ability to spot misuse: outdated algorithms, unsuitable password storage, hard-coded keys.

The table below helps you focus the assessment on the role's main focus.

Main focus	Check first	Warning sign
Tooling and CI/CD	Tool integration and tuning, false positive handling, automation	Turns on every default rule and leaves teams to sort it out
Review and design	Code reading, threat modelling, concrete architecture advice	Lists vulnerability categories without tying them to code
Programme	Prioritisation, remediation tracking, training, team relationships	Measures success by vulnerabilities found rather than fixed

The skills people forget to check

Talking to developers

This is probably the most decisive skill. An AppSec engineer who opens tickets without context, blocks releases without offering a fix or looks down on other people's code loses influence very quickly. Look for someone who explains risk in concrete terms and proposes a fix that can actually be applied.

Prioritising instead of flagging everything

Analysis tools produce a lot of output, and part of it has no real impact. A good candidate can tell a vulnerability that is exploitable in your context from a theoretical alert. Ask them how they decide what blocks a release.

Making the right way the easy way

The best AppSec engineers do more than find flaws: they provide safe libraries, project templates and secure defaults that prevent mistakes. Ask the candidate what they have built, not just what they have found.

Understanding the regulatory context

Depending on your sector, the NIS2 directive or the EU Cyber Resilience Act may affect your development practices. The candidate does not need to be a lawyer, but they should be able to turn a requirement into development practices you can verify. Our article on the profiles to hire for NIS2 covers these needs.

Assess through practice

Application security certifications show genuine interest in the field, but they do not tell you whether the candidate can review your code or win over your teams. Our article on certifications in hiring explains how to read them. To measure practice, a hands-on exercise remains the most reliable method.

An effective process fits in four steps:

A first conversation about background, languages used, the size of the teams supported and the preferred focus.
A time-boxed hands-on exercise: a deliberately vulnerable code extract to review, a small test application to analyse, or a pipeline configuration to harden. Never your production code without prior agreement.
A review with a developer and a security peer: the candidate presents their findings, prioritises them and explains how they would get them fixed. Having a developer in the room lets you judge the quality of the exchange.
A final conversation with the manager about the organisation, scope and prospects.

A few useful questions for the review:

"An analysis tool reports several hundred alerts on a project. Where do you start?"
"A team has to ship tomorrow and you find an access control flaw. What do you do?"
"How would you introduce threat modelling to a team that has never done it?"
"What have you put in place that durably reduced a class of vulnerability?"

To build a fair scoring grid, see our guide to assessing cybersecurity skills.

Costly mistakes

Hiring a pentester while thinking you are hiring AppSec. The two jobs overlap, but a pentester finds and reports, while an AppSec engineer has to get things fixed and prevent them over time. Our guide to hiring a pentester helps tell them apart.
Demanding every language. Look for real mastery of a language close to your stack and the ability to read the others.
Isolating the role inside the security team. Without access to repositories, pipelines and product team rituals, the engineer only sees problems once they reach production.
Measuring by number of flaws. A metric based on vulnerabilities found encourages reporting rather than improving.
Ruling out developers without a security title. An experienced developer with a genuine interest in security can become an excellent AppSec engineer. Our guide to hiring career changers explains how to assess that potential.
Letting the process drag. These profiles are sought after by both security and engineering teams. A long process sends them elsewhere.

What attracts a strong AppSec engineer

Beyond pay, several things weigh on the decision:

a clear mandate and backing from engineering leadership, not just the CISO;
real access to code, repositories and pipelines;
time to build tools and standards, not just to triage alerts;
a budget for training, conferences and tooling;
a culture where developers are involved in security rather than policed.

Present these points from the first conversation, as precisely as your technical requirements. If your platform runs largely in the cloud, our guide to hiring a cloud security engineer will help you split responsibilities between the two roles.

In short

To hire an application security engineer, first choose the role's main focus (tooling, review and design, or programme), the technologies involved and the reporting line. Check code reading, knowledge of vulnerabilities, command of the delivery pipeline and above all the ability to work with developers. Assess with a hands-on exercise followed by a review with a developer, and keep the process short.

Looking for an AppSec engineer who can earn the trust of your development teams? At Cyber Recrut, a recruiter and a security practitioner scope the need with you, then our shortlisted candidates prove their skills on hands-on labs close to your technologies. See how we work or share your hiring need.