Hire Application Security Engineers: Rates, Vetting and Engagement Models

What an application security engineer actually does, and where this hire goes wrong

A Series A fintech asked us to look at their code after they had already spent four months and a hundred thousand dollars on security. They had hired someone with "security engineer" on the CV. He was excellent at what he actually knew: he rolled out endpoint protection, tightened the VPN, ran Nessus across the VPC, and produced a 62 page report full of TLS cipher suite findings and a jQuery version bump. Meanwhile the endpoint at /api/v2/accounts/{id}/statements read the account ID straight from the URL and never checked it against the tenant on the session. Any customer could pull any other customer's bank statements by changing one integer. No scanner in the world was going to find that, because to a scanner it is a 200 response with valid JSON.

That endpoint is the job. An application security engineer finds and fixes the bugs that only make sense if you understand what your code is supposed to do. Broken object level authorization. A JWT verification path that trusts the alg header. A tenant filter missing from one of nine Prisma queries. A signed URL that never expires. A webhook handler that trusts the payload because it came over HTTPS. A password reset token generated with Math.random().

The day to day is more engineering than hacking. Threat modeling a new payments flow before it gets built. Reviewing pull requests that touch auth, file upload, or anything that takes a user supplied URL. Writing custom Semgrep rules so the vulnerability class you keep reintroducing gets caught in CI instead of in a pentest six months later. Wiring dependency scanning and secret scanning into the pipeline without the team disabling it in week two. Building a request level test suite that fires every endpoint with two different tenants' tokens and fails the build when the wrong one gets a 200. Triaging bug bounty reports so your engineers only see the real ones.

The hiring mistake is almost always a category error. "Security" covers four different jobs that share a word and share nothing else. Infrastructure and cloud security engineers care about IAM policies, S3 buckets, Kubernetes admission control. SOC and detection engineers care about logs and alerts. GRC people care about SOC 2 controls, policies and evidence. Application security engineers care about your code, in your language, in your framework. Hire the wrong one of the four and you get competent work on a problem you did not have.

Engagement models: in-house, freelancer, agency, staff augmentation

In-house full-time. Right when you have roughly fifteen or more engineers merging every day, you handle money or health data, and someone needs to own the secure development lifecycle permanently. The honest trade-offs: the candidate pool is thin and slow, good ones get bored inside a year if the work is all questionnaires, and one person cannot cover application security, cloud posture and compliance no matter what the job description says. A solo application security hire in a team that does not want to be reviewed becomes an expensive ticket filer.

Freelancer or independent consultant. Right for point in time work with a hard edge: a pentest before an enterprise contract, a threat model for a new architecture, a focused review of the payments service. The best independents are genuinely better than most firms because they are usually specialists who found real CVEs. The trade-off is continuity and output shape. You get a report. Reports do not merge. Unless you scope remediation explicitly, you are buying a list of problems, and your team still has to fix them while shipping the roadmap.

Agency or boutique security firm. Right when procurement wants a letterheaded report and an attestation you can hand a customer, and right when you want findings plus fixes rather than findings alone. Trade-offs are cost per hour and people rotation. The senior who scoped the engagement is not always the one testing. Ask who is on the keyboard and ask to meet them.

Staff augmentation. Right for a three to twelve month need where the work is continuous but does not justify a permanent headcount: hardening before a Series B diligence, an authorization rewrite, standing up a security review process that survives after they leave. Trade-off: an embedded engineer without merge rights and without an internal owner turns into a very expensive commenter. Give them a repo, a CI account and a named counterpart on your team, or do not bother.

Rates and what this actually costs

These are the ranges we see in Digital Heroes delivery work and in the offers our own candidates accept and turn down. Application security rates move sharply with region, seniority and whether the person can code or only test.

• Contract, senior, code level. India and South or Southeast Asia: roughly $30 to $65 per hour. Eastern Europe and Latin America: roughly $50 to $95. Western Europe and the UK: roughly $90 to $160. US and Canada: roughly $110 to $200 for an independent, $200 to $350 through a boutique firm.
• Fixed scope penetration test of one web application plus its API usually lands between $10,000 and $35,000 depending on endpoint count, roles and whether they get source access. Anyone quoting $3,000 is running a scanner and reformatting the output.
• In-house base salary in the US: the offers we watch candidates accept sit around $130,000 to $170,000 at mid level and $170,000 to $230,000 at senior, higher in the Bay Area and New York, materially lower elsewhere.

Base salary is the smallest honest number in that list. Payroll taxes, health cover, equipment, paid time off and tooling reliably push the real cost well above base. In our own budgeting we plan 1.25x to 1.4x base as the loaded figure before anyone writes a line of code. If you use a contingency recruiter, expect to hand over a fifth to a quarter of first year base on top. Add time: two to four months to fill an application security role properly, because the good ones are not on job boards, and then four to eight weeks of ramp before they know your codebase well enough to tell a real finding from a theoretical one. Add tooling: a Burp Suite Professional seat is a rounding error, but static analysis and software composition platforms priced per developer are a real recurring line item, and cloud posture tools are another.

The practical read: a full-time application security hire is a six figure annual commitment that starts producing value in month three. A scoped engagement produces value in week two. Most companies under fifty engineers should do the second, twice, before considering the first.

How to vet an application security engineer

Skip the trivia. Anyone can define cross-site scripting. You are testing whether they can read code in your stack and reason about your business.

The signals that matter. Can they read your language fluently, not just recognize it. Do they go to the trust boundary first or to the TLS config first. Do they know what the fix is, not just what the bug is. Can they say "this is a low, ignore it" without ego. Have they ever shipped code.

Questions worth asking, with what a good answer sounds like.

• "We verify JWTs with a shared library. Walk me through what happens if an attacker sends alg: none, and separately if they sign an HS256 token using our RS256 public key." A good answer covers algorithm confusion, pinning the expected algorithm, and validating iss, aud and key ID rather than trusting the header.
• "We have a feature that fetches a user supplied URL for link previews. How do you stop server-side request forgery?" A weak answer is a regex blocklist of 169.254.169.254. A good answer is an allowlist, resolving the host yourself, checking the resolved IP against private ranges, pinning that IP for the actual request to survive DNS rebinding, and no redirects.
• "Our React app keeps the session token in localStorage. Argue both sides against httpOnly cookies plus a CSRF defense." You want nuance and awareness of SameSite behavior, not a memorized rule.
• Name your framework and make them answer inside it. On Django: where does the tenant check belong, and what does get_object_or_404 quietly let through. On Rails: what breaks when someone reaches for permit! on strong parameters. On Express with Prisma: how do you stop the ninth query from forgetting the tenant filter, and would you enforce it in middleware, in a repository layer, or with Postgres row-level security. On Spring: what does a misordered filter chain do to your method security annotations.
• "There are 400 open dependency alerts on Monday morning. What do you do?" Good: reachability analysis, separate runtime from dev dependencies, fix the handful that are actually called, set a policy so the number stops growing. Bad: "triage all of them."
• "Our API has about 200 endpoints and three roles. How do you test for broken object level authorization at that scale?" Good: automate it. Two tenants, two token sets, replay every request and diff the responses, assert 403. Bad: describing clicking through Burp Repeater by hand.
• "Tell me about a finding you downgraded or got wrong." Silence here is a red flag on its own.

What a good take-home looks like for this stack. Not a capture-the-flag box. Give them a small real repository, 400 to 800 lines in the framework you actually run, Express or Django or Rails or Spring, with three planted bugs across different classes: an authorization check missing from one route handler, a SQL injection through a raw ORM query, and one of server-side request forgery or unsafe deserialization. Time box it to three hours and pay for it. Ask for four things: a pull request that fixes all three, a test that proves exploitability before the fix, one Semgrep or CodeQL rule that catches the class going forward, and a severity ranking with a business justification.

What separates the good ones is where they put the fix. A weak candidate adds three if statements. A strong one notices the authorization check does not belong in the handler at all and moves it into shared middleware, a Rails before_action, a Django permission class or a Spring method security rule, then explains why the other route is now covered too. Their exploit test hits the HTTP layer with two tenant tokens, not a unit test of a helper function. Their severity ranking talks about who can see whose money, not CVSS vectors.

Portfolio review. Ask for disclosed HackerOne or Bugcrowd reports, CVEs with real writeups, published Semgrep rules, contributions to OWASP ASVS or the cheat sheets, conference talks, or pull requests to security libraries. Then have them walk you through their best finding and ask one question: what was the fix, and did it ship. Someone who only knows the finding is a finder. You are hiring an engineer.

Red flags

• Every story starts with a tool. Burp Active Scan found it, Acunetix flagged it, Nessus reported it. Their value is proportional to a license you could buy yourself. Ask instead: "Find me a bug in this diff that no scanner would ever catch, and explain why the scanner misses it."
• CVSS as the entire argument. They rank a 9.8 in a build-time dev dependency above a broken tenant check because the number is bigger. Ask instead: "Here are three findings. Rank them for our business and defend the order to our CEO."
• Compliance wearing an engineering title. Fluent in SOC 2 controls, vendor questionnaires, policy templates and evidence collection. That is GRC and it is valuable, but it is not this role. Ask instead: "When did you last open a pull request that fixed a vulnerability, and what did it change?"
• The report factory. Every engagement they describe ends in a document and nothing ends in a merge. Ask instead: "Roughly what share of your findings actually got fixed, and what did you do to raise that number?"
• Pipeline maximalism. They want to fail every build on any medium severity finding, day one, with no baseline. Your team turns it off in two weeks and now you have less security than before. Ask instead: "How do you introduce Semgrep into a repo with 900 existing findings without the team disabling it?"

When to hire this role at all, and how we staff it

If you are under ten engineers with no regulated data, you do not need an application security engineer. You need a senior backend engineer who defaults to parameterized queries and centralized authorization, plus one scoped external review before the enterprise deal. If your actual problem is a customer security questionnaire and a SOC 2 audit, hire GRC or use a compliance platform. If your problem is public S3 buckets, over-permissive IAM roles and unrestricted security groups, hire a cloud security engineer. If your problem is that you ship weekly, you hold customer money or health records, and your team keeps reintroducing the same authorization bug in new endpoints, that is when this role earns its cost.

At Digital Heroes we start with a two to three week scoped engagement on the highest risk service: threat model, code review of the auth and money paths, and a prioritized backlog written as issues an engineer can pick up, not as a PDF. From there clients go one of two ways. Either our engineers implement the fixes alongside your team, or we embed an application security engineer into your sprints with merge rights and a named counterpart on your side, usually paired with a backend engineer from the same pod so the fixes actually ship. Everything lives in your repository and your CI from the first day: the rules, the tests, the report, the code. You own all of it, including after we leave, which is the only way any of it still works a year later.