When you think of Chicago, you likely think about deep-dish pizza or the blues. But nestled in the Village of Rosemont, just outside the city, lies another emblem of Chicago’s layered complexity. The community that built the Village of Rosemont converted a factory and warehouse into what is today one of the most successful convention and tradeshow facilities in the U.S.A. It's here, in this logistical heartland of America, that PHP TEK 2025 unfolded. 

This year marked the 17th installment of the premier event of the year for PHP enthusiasts, web development professionals, and companies. Over 150 members of the PHP community got together for three days of sessions, workshops, and a lot of honest conversations on where we are going with web application development. 

Here are just a few highlights and thoughts about the experience. 

From Reactive Fixes to Proactive Thinking

"Fortifying Your Defenses With Threat Modeling," from Eric Mann, Release Manager for PHP itself, began with a phishing story. With no more than a LinkedIn search and a well-crafted email message, his security team caught so many people willing to give over sensitive info that it led to a real audit and mandatory security training. The point wasn’t just that phishing works, but that security often arrives too late in the cycle, sweeping up after the fact.

Eric argued for an earlier insertion of security thinking through threat modeling. Not as a box to check, but as a shared language developers and security teams can use together. Define the system. Identify threats. Prioritize, mitigate, and review that STRIDE and DREAD elements were accounted for, but the deeper message was cultural.

The more developers understand their own systems, the more security becomes intrinsic. Threat modeling teaches system thinking. It exposes trust boundaries, sensitive flows, and flawed assumptions. It builds intuition. But most importantly, it makes developers the first line of defense, not because they're being policed, but because they're being empowered.

Security Choices In Architecture Choices 

The talk from Peter Meth, Principal Software Engineer at Givelify, "Breaking it Down: Microservices Architecture for PHP Developers" could have passed as pure dev architecture advice. But his commentary on autonomy, boundaries, and deployment velocity struck a chord for anyone thinking about security posture.

His vision, one service per team, JWTs for lightweight auth, Backend for Frontend (BFF) style API Gateways, was all about flexibility. Yet every design decision had a security implication. Event buses require rigorous input validation. Shared libraries mean keeping track of any deep dependencies. A database-per-service approach has fewer blast radius concerns, but more state sync challenges.

Modern development is messy by design. Architecture is fluid. Best practices are context-dependent. So instead of prescribing from a distance, security should be embedded. Understand team structures. Co-create boundaries. Suggest patterns that work within, not against, the grain.

Peter’s advice, start small, build confidence, and define rules that fit your culture, should be printed on every DevSecOps playbook. Security that enables is security that sticks.

Reclaiming Testing as Developer-Security Dialogue

Tim Lytle, Software Engineering Manager at PhoneBurner,  posed a sobering question: “If no one would miss the test, why does it exist?” It was a talk about software quality, but it doubled as a metaphor for security integrations. Too often, security requirements are cargo-culted into projects, unloved, unexplained, and ignored; Just like bad tests.

Tests should document intention, provide confidence in change, and catch unexpected regressions. The same is true for good security practices. But if the rules are arcane, the outputs are noisy, or the remediations are vague, they get bypassed.

What Tim reminded us, in a talk that was fiery at times, is that resilience comes from relevance. Developers don’t hate testing, they hate pointless work. The same goes for security.

Developer Knowledge Is Security Capital

What came into sharp focus at PHP TEK 2025 was that developers aren’t security’s problem, they’re its partners. But too often, we fail to tap that partnership.

Security teams have a bad habit of talking at developers instead of working with them. We write policies instead of pairing. We demand compliance instead of curiosity. But real security maturity isn’t about adding more gates. It’s about creating better guides.

Humanizing the Feedback Loop

Threat modeling is a perfect example. It’s not about predicting every risk, it’s about fostering conversations. When developers draw data flows and enumerate trust zones, they aren’t just checking boxes. They’re learning to see their work through a security lens.

Security teams should be in those rooms, not as gatekeepers, but as advisors. Helping refine assumptions. Suggesting mitigations. Sharing lessons learned from incidents. That’s the collaboration that builds security DNA.

Closing the Language Gap

Your author was able to give a talk about end-to-end secrets security. In my conversations around NHIs and authentication, it became clear that half the challenge is terminology. Security’s jargon-rich, standards-heavy world is intimidating. Developers don’t lack interest. They lack translations.

If security wants adoption, it needs to communicate in terms that developers understand. Show them use cases, not protocols. Start with user stories, not encryption theory. Focus on outcomes: fewer password resets, better session hygiene, less fraud.

Security doesn’t need to be easier, it needs to be clearer.

Redefining Ownership

One of the unspoken tensions in DevSecOps is the question of ownership. Who owns threat models? Who rotates keys? Who patches vulnerable libraries?

PHP TEK hinted at a new answer: shared responsibility with differentiated expertise. Developers' own implementation. Security owns facilitation. Both groups own outcomes. This model doesn’t remove accountability, it distributes it. And that’s what makes it sustainable. It’s not about shifting blame. It’s about sharing purpose.

The Security Engineer as a Developer Advocate

The most forward-looking security teams are redefining their role. They’re embedding into product teams. They’re contributing to SDKs. They’re writing documentation with code samples. They’re setting guardrails, not barriers.

At its best, security becomes another form of developer advocacy. It champions good defaults. It streamlines reviews. It builds safer tools. Developers repay that trust by asking better questions, raising flags sooner, and owning more of the risk conversation.

This is a shift we need.

Meet People Where They Are

If there’s one lesson to take from PHP TEK 2025, it’s this: the security culture we need already exists, it’s just wearing a dev badge.

Developers are already modeling systems, building boundaries, and testing assumptions. What they need isn’t another compliance checklist. They need partners who understand their world and can add value without adding drag. 

Security doesn’t win by saying “no.” It wins by making the right thing the easiest thing to do.

If you’re part of a security team, we invite you to try to find time to pair with a dev this week. Maybe review a threat model. Or refactor an auth flow. Look at the testing suite together. Find one place where your insight can unblock them.

You’ll learn a lot. So will they. And that’s how we close the cultural divide, one conversation at a time.