Full-Cycle Security Engineer: Why Developers Should Learn Pentesting

March 18, 2026I was a backend developer. Then I started attacking my own code. Not out of boredom. Not because it was trendy. But because I was on a project where an external pentester dropped a 40-page report on our desk -- and nobody on the team truly understood what was critical, what was noise, and above all: how to fix it properly. The pentester wrote: "JWT signature is not validated." Our lead said: "Then let's just validate it." What happened next? The validation was added, but the key was hardcoded in the frontend. Problem solved, new problem created. A classic. That day I decided I wanted to understand both sides. Not just write code that works -- but write code that withstands attack.

The Problem: Dev and Security Don't Speak the Same Language

In most companies, there's an invisible wall between development and security. And that wall costs real money.

The Developer Side

Developers think in features, deadlines and user stories. Security is the thing that gets bolted on "at the end." Like a padlock on a door that's already been installed. The problem: if the door is made of cardboard, the lock doesn't help much. Most devs I know (myself included, in the past) make the following mistakes:

Input validation? "Oh, the frontend already validates that."
Secrets management? .env file committed to the repo because it needed to be quick.
Authorization? "The endpoint is internal only." (Spoiler: nothing is internal only.)
Error handling? Stack traces sent directly to the client because it helps with debugging.

These aren't beginner mistakes. This happens in teams with 10+ years of experience. Because security thinking isn't part of developer education. You learn algorithms, design patterns, clean code. But nobody teaches you how an attacker looks at your API.

The Pentester Side

Pentesters are good at breaking things. That's their job. But most pentesters have never written production code. They know the OWASP Top 10 by heart, can explain Burp Suite in their sleep and find an IDOR vulnerability in 20 minutes. What they can't do: tell you how to restructure your architecture so the problem doesn't come back in a different form three months later. Their report says: "Broken Access Control in /api/users/{id}." Their fix suggestion says: "Implement an authorization check." Thanks. Very helpful. What's missing: Should I do this per endpoint? Middleware? Policy-based? RBAC or ABAC? How do I integrate this into my existing architecture without touching 200 endpoints? What about edge cases with multi-tenancy?

The Result: Expensive Ping-Pong

What happens in practice is an endless cycle:

Dev team builds feature
Security team tests (weeks later)
Report with 30 findings
Dev team fixes (without security context)
Security team re-tests
10 findings are fixed, 5 new ones have appeared
Back to step 4

I've experienced this often enough. In one project, this cycle took four months. Four months during which features were stalled because the team was stuck in fix mode.

What a Full-Cycle Security Engineer Does

A Full-Cycle Security Engineer is not a hybrid of two half-roles. It's a discipline of its own. Someone who builds software AND attacks it -- and therefore knows the right lever at every point in the development process.

Secure Architecture from Day 1

Before a single line of code is written, I look at the architecture. Not as an external reviewer, but as someone who helps shape it.

Where are the trust boundaries?
Which data is sensitive and how does it flow through the system?
What attack vectors arise from the chosen architecture?
Is the auth strategy scalable or will it become a bottleneck?

This sounds like a lot of effort upfront. It is. But it's a fraction of what it costs to rebuild an insecure architecture later.

Threat Modeling in Design

Threat modeling is not "we draw a diagram and write STRIDE next to it." It's a mindset. For every feature I ask: What happens if someone intentionally misuses this? A login feature? Okay, what happens with:

Brute force? Rate limiting, account lockout, progressive delays.
Credential stuffing? Breach detection, anomaly-based alerts.
Session hijacking? Secure cookies, token rotation, device fingerprinting.
Password reset abuse? Token expiry, one-time use, no user enumeration.

If you only think about this after the pentest, you're building on a foundation that wasn't designed for it. That gets expensive, fragile and usually incomplete.

Secure Code Review (Not Just Linting)

SonarQube, Semgrep, CodeQL -- all good tools. But they don't find business logic vulnerabilities. They don't find race conditions in your payment flow. They don't find that your admin endpoint has auth but checks the wrong role. A manual code review by someone who understands both the code and how an attacker would exploit it is irreplaceable by any tool. I don't read code as a developer looking for bugs. I read code as an attacker looking for a way in. That's a fundamental difference.

Penetration Testing Your Own Code

Yes, I test my own code. "But isn't that a conflict of interest?" No. It's an advantage. I know the architecture. I know where the shortcuts are. I know which edge cases we wanted to fix "later." I know where time pressure led to compromises. And that's exactly where I start. This doesn't replace an external audit. But it ensures that an external auditor spends their time on real architectural issues -- and not on low-hanging fruit I should have found long ago.

Fix Implementation That Makes Architectural Sense

This is where the circle closes. When I find a vulnerability, I don't just suggest a patch. I implement the fix. And because I know the architecture, the fix isn't a band-aid -- it's a solution. Back to the JWT example from the beginning: A pentester would have said: "Validate the signature." Instead, I refactored the entire auth middleware:

Asymmetric signing (RS256 instead of HS256)
Key rotation via a central key store
Token validation as middleware, not per endpoint
Refresh token flow with device binding
Audit logging for all auth events

That's the difference between "vulnerability closed" and "problem solved."

The Business Case: Why This Saves Money

Now let's get pragmatic. Because in the end, it's not the technology that decides -- it's the business case.

The Cost Curve

The cost of fixing a security vulnerability increases exponentially with each phase: | Phase | Relative Cost | Example | |-------|--------------|---------| | Design | 1x | Adjust threat model | | Development | 5x | Code review + refactoring | | Testing/QA | 15x | Pentest + fix + re-test | | Production | 60x | Incident response + patch + audit | | Post-breach | 200x+ | Forensics + legal + reputation | These numbers aren't made up. IBM has published the "Cost of a Data Breach Report" for years, and the trend is clear: the later you find it, the more expensive it gets. A Full-Cycle Security Engineer works primarily in the first two phases. That doesn't mean nothing happens after that. But the big, expensive architectural issues are caught early.

No Translation Loss

When a pentester explains a finding to a developer, information gets lost. The pentester thinks in attack vectors, the developer thinks in code structures. Both are right, but they talk past each other. When one person does both, this translation layer disappears. I don't need to explain to anyone why an IDOR is dangerous. I don't need to explain to anyone how the ORM works. I see the problem, understand the context and implement the solution. One fewer communication path that can go wrong.

A Real Example

In an API project, I found a JWT configuration during code review that no automated scanner in the world would have flagged: The token was correctly signed and validated. HTTPS was active. The expiry time was set. All green, right? The problem: The aud claim (audience) was not checked. This meant: a token issued for Service A was also valid at Service B. In a microservices architecture, that's a lateral movement goldmine. No scanner checks for this because the signature is valid. A pentester only finds it if they understand the architecture. A developer only sees it if they know what to look for. I found it because I am both.

Skills You Need (And How I Got There)

I want to be honest here: this path isn't for everyone. It requires a willingness to live in two worlds simultaneously.

The Technical Side

Backend Engineering: You must be able to write production-ready code. Not "I can follow a tutorial," but "I can design and implement an API with auth, rate limiting, input validation and audit logging from the ground up."
Network & Infrastructure Understanding: You need to know how packets flow through a network. How DNS works. What a reverse proxy does. Why CORS exists.
Offensive Security: Pentesting is a craft. Tools like Burp Suite, ffuf, Nuclei are your instruments. But more important than the tools is the methodology: How do you proceed systematically?

I worked my way through the CPTS (Certified Penetration Testing Specialist) and the CWEE (Certified Web Exploitation Expert) from Hack The Box on this path. Not because certifications are everything -- but because the exams force you to attack and document real-world systems under pressure. That's a different league from multiple choice.

The Mindset Shift

The technical skills can be learned. The hard part is the perspective shift. As a developer you think: "How do I make this work?" As an attacker you think: "How do I make this break?" You need to learn to look at your own code with suspicion. To question every assumption. To see every shortcut as a potential weakness. That's uncomfortable at first because you're criticizing your own code. But in the long run, it makes you a better developer -- and a better security expert. A few questions I ask myself with every feature:

What happens if the input isn't what I expect?
What happens if the user isn't a user but an attacker?
What happens if this service is compromised -- what can the attacker reach from here?
What happens if the database is leaked -- what data is in plaintext?

When you start thinking this way, you find bugs before they exist.

My Stack, My Approach

To give you a concrete picture, here's a typical engagement for me:

Kick-off: Architecture review, threat model workshop with the team. No PowerPoints -- just a whiteboard and honest conversations about risks.
Design Phase: Define security requirements, establish auth strategy, data flow analysis.
Implementation: I build alongside the team or review code in parallel with development. Not after sprint 10, but from sprint 1.
Testing: Manual pentesting of the application, focused on business logic and auth bypass. Automated scans as a baseline, not a substitute.
Hardening: Infrastructure review, CI/CD pipeline security, secrets management, monitoring.
Handoff: Documentation, runbooks, team training. My goal is for the team to be self-sufficient after my engagement.

Closing: Code That Defends Itself

I build backends that defend themselves. Not because they're magically secure -- that doesn't exist. But because security is part of the architecture from the start. Because every component is built so that an attacker encounters resistance at every corner. Defense in depth, not as a buzzword but as an architectural principle. The world doesn't need more pentesters who write reports nobody understands. And it doesn't need more developers who treat security as "phase 2." It needs people who can do both. If you have a project that should be built securely from the start -- or an existing system that needs an honest assessment from someone who can also implement the fixes -- let's talk. You can reach me at kontakt@buengener-software.de or on LinkedIn.