AppSec and DevSecOps interview questions: the grid

An interview for an application security role easily drifts into reciting the OWASP Top 10 or listing scanning tools. You leave without knowing whether the candidate can read your code, tune a CI/CD pipeline or persuade a development team to fix things. Below is a set of questions organised by theme, with what a good answer contains and the signals that should worry you.

Before the interview: know which profile you are assessing

"AppSec" and "DevSecOps" cover different jobs. Before preparing your questions, pin down the main focus of the role:

• Tooling and delivery pipeline: integrating static analysis, dependency scanning, secret detection and container scanning into CI/CD.
• Review and design: threat modelling, reviewing sensitive code, architecture advice.
• Programme: security champions, developer training, driving remediation, working with pentesters and bug bounty.

Also note the languages and frameworks you use, and how many developers the person will support. If these points are still open, start with our guide to hiring an application security engineer. A grid built on a vague need compares candidates on criteria that do not matter.

Bring a developer from the team into at least part of the interview. They will tell you whether the candidate speaks the teams' language, which no technical question measures on its own.

Vulnerabilities and code reading

"Pick a vulnerability you know well. Show me what it looks like in code, then how to fix it."

A good answer starts from a concrete example in a language the candidate knows: a query built by string concatenation, an access check enforced only on the client, an object identifier never matched against the logged-in user. The fix is precise (parameterised query, server-side check, per-object authorisation) and the candidate explains why it works.

Red flag: a textbook definition with no code at all.

"How do you trace user input from its entry point to a sensitive function?"

You want a method: identify the entry points (parameters, headers, files, messages), follow the transformations, spot where the data is validated, encoded or used as is. The strongest candidates also mention indirect paths, such as data stored and read back later by another service.

"What is the difference between authentication and authorisation, and where do you see the most mistakes?"

The definition is easy; the second half is revealing. A practitioner will often mention per-object authorisation in APIs, admin functions exposed without checks, or tokens whose validity is not properly verified.

API and architecture security

"A team shows you a new public API. What do you ask them before it goes live?"

Expected: who can call what, how identity is passed and checked, what data comes back (and whether all of it is needed), what rate limiting, what logging, which old versions are still reachable. The candidate should ask questions before giving answers.

"How would you run a threat modelling session with a team that has never done one?"

You are looking for pragmatism: a simple diagram of the application, the trust boundaries, a few realistic scenarios, a short list of actions with owners. Red flag: a multi-day workshop with heavy formalism, presented as a prerequisite for every project.

"How do you spot cryptography being misused in an application?"

No maths needed. You want concrete examples: passwords stored without a suitable hashing function, an outdated algorithm, a hard-coded key or secret, weak randomness, home-made encryption.

Delivery pipeline and DevSecOps

This section carries more weight if the role is tooling-focused.

"You need to add static analysis to the CI/CD of twenty teams. How do you go about it?"

A good answer starts small: one or two pilot projects, rules limited to what has real impact, false positives tuned before a wide rollout. The candidate separates what blocks a merge from what only raises a ticket, and talks about how results reach developers (in the merge request rather than in a dashboard nobody opens).

Red flag: "I turn on every rule and block everything that comes up."

"A secret has been pushed to a Git repository. What do you do, in order?"

Expected: treat the secret as compromised, revoke and rotate it first, check the logs for any use of it, and only then clean the history if needed. The candidate adds preventive detection so it does not happen again. Deleting the commit without revoking the secret is a classic mistake.

"How do you manage the risk from third-party dependencies?"

You want an inventory of dependencies, scanning for known vulnerabilities prioritised by real exploitability, regular updates, checks on package provenance and protection of the build chain itself (pipeline permissions, runner secrets, artefact signing).

"What should genuinely block a release?"

This is a judgement question. A good candidate proposes clear criteria, known in advance, and a documented exception path. They know that a control which blocks too often ends up bypassed.

Working with developers

This is often what separates a good AppSec engineer from an excellent one.

"A team has to ship tomorrow and you find an access control flaw. What do you do?"

You want a graded answer: assess real exploitability, talk to the team directly, offer a fix or a temporary mitigation, and escalate the decision to the right level if the risk is accepted. Neither an automatic block nor silence.

"Tell me about a time a developer disagreed with your finding."

Listen to the detail and the tone. The candidate should have heard the argument out (the developer is sometimes right about the context), brought evidence and found a way forward. Push on the details; a lived story holds up under follow-up questions.

"What have you built that durably removed a class of vulnerability?"

The best profiles mention a safe library, a project template, a secure default configuration or a custom detection rule. They measure success by vulnerabilities prevented, not tickets opened.

Summary grid

Score every candidate on the same grid, straight after the interview.

Tips if you are not a specialist

You can run a useful part of the interview without being an application security expert.

1. Ask for lived examples: "Last time, what exactly did you do?"
2. Follow up with "why": a practitioner justifies their choices; someone reciting runs out quickly.
3. Ask for an explanation aimed at a non-technical audience: an AppSec engineer will have to convince product managers and leadership.
4. Watch their attitude towards developers: respect, curiosity about their constraints, a wish to equip them.
5. Do not decide on certifications alone: our article on cybersecurity certifications explains what they prove and what they do not.

Complete the interview with a hands-on exercise

An interview measures reasoning and communication. It measures poorly the ability to find a flaw in unfamiliar code or harden a real pipeline. A short exercise fills that gap: a deliberately vulnerable code excerpt to review, a small test application, or a pipeline configuration to fix. Never your production code without prior agreement.

The discussion that follows, ideally with a developer present, is often richer than the interview itself: "why this finding first? How would you get it fixed?" Our guide to assessing cybersecurity skills explains how to design a fair exercise, and our pentester interview questions will help if your need leans more towards testing than prevention.

In short

A good AppSec and DevSecOps interview grid covers vulnerabilities as they appear in code, code reading, API and architecture security, the delivery pipeline and, above all, working with developers. Weight each theme to the focus of the role, favour lived examples, score everyone the same way and add a hands-on exercise.

Hiring an AppSec or DevSecOps engineer? At Cyber Recrut, a recruiter and a security practitioner run every search together, and our shortlisted candidates prove their skills on hands-on labs close to your technology stack. See how we work or share your hiring need.