Working with Developers

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Every technical practice in Track B — secure coding standards, code review, automated testing, threat modeling — succeeds or fails on one thing: whether developers actually adopt it. An Application Security engineer who is technically brilliant but cannot work effectively with developers will fail; one with solid skills and excellent collaboration will succeed. AppSec is, at its core, a people discipline wearing technical clothing. This final page of Track B is the human skill that makes all the rest work.

Part 1: The Problem

Look back across Track B. Secure development lifecycle (5B.1) — done by developers. Secure code (5B.1) — written by developers. Code review findings (5B.2) — fixed by developers. Automated testing findings (5B.3) — acted on by developers. Threat modeling (5B.4) — a collaborative session with developers.

The pattern is unmistakable: every single thing in Application Security ultimately depends on developers. The AppSec engineer does not, and cannot, secure the software alone (the 5B.1 principle). They succeed through developers — by making developers able and willing to build securely.

This means a hard truth: the AppSec engineer’s effectiveness is limited not by their technical skill but by their ability to work with developers. A brilliant AppSec engineer whom developers experience as an obstacle — a gatekeeper, a source of friction, a critic — will be routed around, ignored, and ultimately ineffective. The same skills, delivered by someone developers experience as a helpful ally, transform an organization. This page is that ability — and it is the page that determines whether all the others actually matter.

Part 2: The Concept — Why the Relationship Is Hard (and How to Reframe It)

It helps to honestly understand why the AppSec/developer relationship can be difficult — and then to reframe it correctly.

Why friction arises:

• Competing pressures. Developers are under pressure to ship features, fast. Security can be experienced as something that slows that down — more work, more steps, more blockers.
• The gatekeeper trap. If security shows up mainly to block things — failing builds, rejecting code, saying “no” — developers come to see the AppSec engineer as an adversary, an obstacle between them and shipping.
• Findings feel like criticism. A list of “vulnerabilities in your code” can land as a personal critique of the developer’s work, triggering defensiveness rather than collaboration.
• Knowledge gaps. Developers are not usually security experts; security findings can feel like being judged against a standard they were never taught.

The reframe — the single most important mental shift in this page:

   ❌ WRONG framing:  AppSec vs Developers
      security as gatekeeper, blocker, critic, adversary
      → developers route around security; AppSec fails

   ✅ RIGHT framing:  AppSec WITH Developers, same side
      AppSec as enabler, ally, resource, teammate —
      everyone shares the goal of good software
      → developers engage with security; AppSec succeeds

The AppSec engineer and the developers are on the same team, with a shared goal: good software. Insecure software is not good software — so security is not opposed to the developers’ goal, it is part of it. The AppSec engineer’s job is not to impose security on developers; it is to help developers achieve something they also want — software that is not just functional but sound. Everything else in this page flows from getting this framing right.

Part 3: The Concept — Communicating Findings Well

A great deal of AppSec/developer interaction is the AppSec engineer bringing findings to developers — from code review (5B.2), automated tools (5B.3), threat modeling (5B.4), assessments. How those findings are communicated very largely determines whether they get fixed and whether the relationship stays healthy.

Principles for communicating findings well:

Frame it as the work, not the person. A finding is about the code and the system — never about the developer’s competence. “This query is built in a way that allows injection” — about the code. Tone and framing make the difference between a developer who engages and one who gets defensive.

Make findings genuinely actionable (the 2.11 / 5A.4 reporting discipline). A developer should receive: clearly what the issue is, where it is, why it matters (the real impact — 1.1), and how to fix it. A finding without a clear path to a fix is a burden; a finding with one is help.

Explain the “why.” Developers fix things better, and learn, when they understand why something is a vulnerability — not just “the tool flagged it.” Explaining the real risk turns a finding into education, and a developer who understands the why will avoid the whole class of issue next time.

Prioritize honestly. Do not present every finding as a five-alarm fire. Use real risk (likelihood × impact, 1.1) — be clear about what genuinely matters urgently and what is lower priority. Developers trust an AppSec engineer who prioritizes honestly; they tune out one who treats everything as critical (the same false-positive-fatigue problem from 5B.3, applied to human communication).

Be a resource, not just a reporter. The best AppSec engineers do not only deliver findings — they help fix them. Being available to discuss, to pair on a fix, to answer questions, positions security as help rather than homework.

Acknowledge constraints. Developers work under real constraints — deadlines, legacy code, competing priorities. An AppSec engineer who acknowledges those constraints and works within them, helping find practical paths forward, earns far more cooperation than one who issues demands divorced from reality.

Part 4: The Concept — Enabling Developers, Not Just Checking Them

The deepest shift in effective AppSec work: moving from checking developers’ work to enabling developers to do secure work themselves. This is the 5B.1 principle — secure development as the whole organization’s property — made personal.

A purely checking-based AppSec model (review everything, test everything, find and report all the bugs) does not scale and does not improve the organization — the AppSec engineer becomes a bottleneck, and developers stay dependent. An enabling model multiplies the AppSec engineer’s effect by raising the whole development organization’s security capability.

What enabling looks like in practice:

• Education and training. Helping developers learn security — the vulnerability classes, the secure patterns (Phase 4.1/4.2), why things matter. A developer who understands SQL injection writes parameterized queries by habit, forever. Education is the highest-leverage thing an AppSec engineer can do — it prevents whole classes of issue at the source.
• Guidance and standards. Providing clear, usable secure coding standards, guidelines, and patterns — so “the secure way” is known and easy.
• Good tooling, well-integrated. Automated security testing (5B.3) that is well-tuned and woven into the developers’ existing workflow enables secure development — developers get fast, actionable security feedback as part of their normal work, without depending on the AppSec engineer.
• Being approachable. Being the person developers feel they can ask — “is this approach secure?” — before they build something, not just the person who tells them afterward that it was not. An AppSec engineer developers consult early has shifted security genuinely “left.”
• Making the secure path the easy path. The most powerful enabling move of all: arranging things — tooling, frameworks, defaults, patterns — so that the secure way of doing something is also the easiest way. When secure is easy, developers are secure by default, without friction. (This connects to “secure defaults” from 4.3 — applied to the developer experience itself.)
• Building security champions. Cultivating interested developers within teams who take on a security-aware role — extending security capability into the teams themselves.

The shift from checker to enabler is what turns an AppSec engineer from a bottleneck into a multiplier.

Part 5: The Concept — Influence Without Authority, and Handling Disagreement

An AppSec engineer usually does not have authority over developers — they cannot simply order secure development. Their effectiveness comes from influence: trust, credibility, relationships, and the ability to persuade. Two practical aspects.

Building credibility and influence:

• Competence earns credibility. Developers respect an AppSec engineer who genuinely knows their stuff — the security knowledge and an understanding of how software is really built. Here your developer background is a direct asset (5B.1, Part 6): you can speak as a peer, understand their world, and not be dismissed as someone who “doesn’t code.”
• Consistency and honesty build trust. An AppSec engineer who prioritizes honestly, does not cry wolf, acknowledges constraints, and follows through becomes trusted — and trusted advice gets followed.
• Helpfulness builds relationships. An AppSec engineer who is genuinely helpful — a resource, an ally — builds the relationships that influence runs on.
• Small wins compound. Influence is built over time, through many positive interactions. There is no shortcut; there is consistent, helpful, credible conduct.

Handling disagreement and risk decisions: Sometimes a developer or team will disagree — about whether something is a real issue, about priority, about whether to fix something now. Handle this well:

• Disagreement is normal and often legitimate. A developer may have context the AppSec engineer lacks; the AppSec engineer may see risk the developer does not. Engage with it as a genuine question, not a battle.
• Make the risk clear, then respect the decision process. The AppSec engineer’s job is to ensure the risk is clearly understood — the real likelihood and impact (1.1). Sometimes, with the risk understood, an organization will make a conscious decision to accept a risk or defer a fix (recall risk acceptance from 1.1). That can be a legitimate business decision. The AppSec engineer ensures the decision is informed; they do not always get to make it.
• Escalate appropriately, rarely. For genuinely serious risks that are not being addressed, there are escalation paths. But escalation is a last resort — an AppSec engineer who escalates constantly has failed at influence. Most things should be resolved through collaboration and credibility, not authority.
• Stay professional always. Exactly as in 5A.4’s triage-disagreement lesson — disagreement handled with professionalism, evidence, and respect strengthens relationships; disagreement handled with hostility destroys them.

Part 6: The Concept — The Human Core of AppSec, and Track B Complete

This final page closes Track B by naming what it has been building toward.

Application Security is a people discipline. Yes, it is deeply technical — it requires everything in Phases 1–4 and all of Track B’s technical pages. But its effectiveness is fundamentally about people: about making a development organization want to and be able to build secure software. The technical knowledge is necessary; the ability to work with developers is what converts that knowledge into actual security. An AppSec engineer is, in the end, a change agent — someone who improves how an organization builds software, which is a fundamentally human and organizational task.

This is good news for a developer switching in. The two things that make an AppSec engineer effective are deep understanding of how software is built, and the ability to work well with developers. As a developer:

• You understand how software is built — from the inside.
• You can talk to developers as a peer — you have been the developer receiving a security finding; you know how it feels and what would have helped.
• You have empathy for the constraints — deadlines, legacy code, competing pressures — because you have lived them.

Your background is not just a technical asset for AppSec (5B.1, Part 6) — it is a relational asset. You are positioned to be the kind of AppSec engineer developers see as “one of us, helping us” rather than “an outsider judging us.” That is the most effective kind there is.

🔑 The deep lesson — and the close of Track B: Application Security is a people discipline. Every technical practice in this track — secure coding, code review, automated testing, threat modeling — only produces real security if developers adopt it, and that depends on the AppSec engineer working with developers, not against them: same team, shared goal, communicating findings as help not criticism, enabling developers rather than just checking them, and earning influence through credibility and helpfulness. Get the technical knowledge from the whole curriculum; get the collaboration right from this page; and a developer-turned-AppSec-engineer becomes exactly what the field most needs — someone who makes the people building software build it securely.

📓 Key Terms

🧪 Hands-On Lab

This page’s labs are about communication, framing, and reflection — practiced in writing and, where possible, in real interaction.

Task 1 — Rewrite a finding two ways. Take a real vulnerability finding (from a Track B lab). Write it up two ways: once in a blaming, jargon-heavy, everything-is-critical style; once framed as same-team help — clear, actionable, honestly prioritized, with the “why” explained. Compare. This is the core communication skill.

Task 2 — Write actionable findings. Take three findings from your 5B.2 code-review lab. For each, write a developer-facing finding with clear what / where / why-it-matters / how-to-fix. Practice making findings help, not homework.

Task 3 — Reflect from the developer’s side. You have been a developer. Write an honest reflection: when you received feedback or criticism on your code, what made it land well vs badly? What would have made a security finding feel like help rather than judgment? Use your own experience as a guide to how to treat developers.

Task 4 — Design an enabling approach. For an imagined development team, write how you would shift from checking to enabling: what education, what guidance/standards, what tooling integration, how you would be approachable, how you would make the secure path the easy path. This is the Part 4 lesson made concrete.

Task 5 — Work through a disagreement. Write out a scenario: a developer disagrees that a finding needs fixing now. Script how you would handle it well — engaging genuinely, making the risk clear, respecting the decision process, staying professional. Then script how to handle it badly, and note the difference.

Task 6 — Plan your influence. Write how you would build credibility and influence as a new AppSec engineer on a team with no authority over developers — using competence, consistency, honesty, helpfulness, and small wins.

Task 7 — Write a working-with-developers note. In Notion, create a “Working With Developers” page — the same-team reframe, communicating findings well, enabling vs checking, influence without authority, handling disagreement. The reference for the human core of AppSec.

Task 8 — Reflect on the fit. Close Track B with an honest reflection: given Track B as a whole, is Application Security a direction you want to pursue? How do your developer background and your own experience position you for it? This feeds your Phase 7 career thinking.

⚠️ Common Mistakes

• Being a gatekeeper. Security experienced as a blocker and critic gets routed around and ignored. Same team, shared goal — AppSec with developers.
• Communicating findings as criticism. Findings framed as personal critique trigger defensiveness. Frame about the code and the work; explain the why; be a resource.
• Treating everything as critical. Crying wolf destroys trust. Prioritize honestly by real risk — or developers tune you out (the human version of false-positive fatigue).
• Only checking, never enabling. A pure checking model makes the AppSec engineer a bottleneck and keeps developers dependent. Educate, guide, give good tooling, make secure easy — enable.
• Forgetting developers’ real constraints. Demands divorced from deadlines and legacy reality get ignored. Acknowledge constraints; help find practical paths.
• Trying to use authority you do not have. AppSec runs on influence — trust, credibility, helpfulness — not orders. Escalation is a rare last resort, not a tool.
• Handling disagreement as a battle. Disagreement is normal and often legitimate. Make the risk clear, respect the decision process, stay professional always.
• Treating AppSec as purely technical. It is a people discipline. Technical knowledge is necessary; working well with developers is what converts it into real security.

✅ Recap & What’s Next

• Every technical practice in Track B depends on developers adopting it — so the AppSec engineer’s effectiveness is determined by their ability to work with developers.
• The core reframe: AppSec and developers are on the same team with a shared goal — communicate findings as help, not criticism (actionable, “why” explained, honestly prioritized); shift from checking developers to enabling them; earn influence through credibility and helpfulness, not authority.
• Application Security is a people discipline — and a developer’s background is a relational asset as much as a technical one, positioning you to be the AppSec engineer developers see as a helpful peer.

Track B complete. You can now operate as an Application Security engineer — weaving security into the Secure Development Lifecycle and “shifting left” (5B.1), reviewing code for vulnerabilities (5B.2), building security testing automation into pipelines (5B.3), running threat modeling as a practice (5B.4), and — the human core that makes it all work — collaborating effectively with developers (5B.5). This is the employment path that builds most directly on what you already are: a developer.

Where to go from here:

• Track A — Bug Bounty Hunter is the freelancing specialization (offensive, independent).
• Track C — Cloud & DevSecOps Security is the highest-demand specialization, connecting to your On-Prem/DevOps module — and it overlaps with this track’s 5B.3 (security in CI/CD pipelines).
• Phase 6 — AI Security is the emerging frontier — and AppSec engineers are increasingly expected to secure AI-powered software.
• Phase 7 — Career & Freelancing turns all of this into a career — and for an AppSec engineer, page 7.3 (breaking into a security job) is the most directly relevant.

You may do the other tracks now or return to them later — the skills compound.

📋 Phase 5, Track B — Page Checklist

Tick each page when its reading and its hands-on lab are done.

• [ ] 5B.1 — The Secure Development Lifecycle
• [ ] 5B.2 — Code Review for Security
• [ ] 5B.3 — Security Testing Automation
• [ ] 5B.4 — Threat Modeling in Practice
• [ ] 5B.5 — Working with Developers

Keep growing your living pages:

• [ ] Master Glossary — append every 📓 Key Terms box above.
• [ ] Tools & Reference Cheatsheet — SAST/DAST/SCA tools, secrets scanners.
• [ ] Application Security note (5B.1), Security Code Review note (5B.2), Security Testing Automation note (5B.3), Threat Modeling in Practice note (5B.4), Working With Developers note (5B.5).

🔑 The Track B throughline: Application Security weaves security into every stage of how software is built (“shift left”); it applies everything from Phases 1–4 as a professional practice; and it succeeds only by making secure development the whole organization’s property — which is, in the end, a people discipline. It is the security specialization that builds most directly on being a developer.