Who the Hell Owns This Thing Anyway?

Early Release: The following content is an early preview and should be considered a work in progress. Information may be missing or incomplete until the final release

Up till this point we’ve been focusing extensively on how applications are built, deployed, and described, but we’ve left out one absolutely critical piece of information: the people. And honestly? That’s been one of the biggest, most persistent mistakes in application security for way too long.

Here’s the thing that keeps security teams up at night: when something breaks, gets compromised, or needs urgent fixing, there’s this frantic scramble to figure out who’s supposed to deal with it. A shocking amount of remediation time in application security is completely wasted on detective work—figuring out who owns a problem and providing the necessary context to actually address it. That’s not just inefficient—it’s downright dangerous when you’re dealing with active security incidents or compliance violations.

From engineers to product owners to security champions and sponsors, everyone and their team should be clearly identified and updated regularly. When something goes sideways, everyone should know exactly who to call, what their responsibilities are, and how to escalate appropriately. The problem is that security is increasingly becoming a shared responsibility across multiple teams and disciplines—it’s not just the job of a centralized security team anymore. But if nobody knows who’s responsible for what, that shared responsibility quickly becomes nobody’s responsibility.

The Human Element That Everyone Forgets

AI is getting incredibly sophisticated these days, and there’s no shortage of enthusiasm about its potential to transform how we build and secure software. But here’s the reality check that cuts through all the hype: AI isn’t planning, building, securing, and maintaining applications on its own just yet. People are still the missing piece to the puzzle, and that’s not changing anytime soon.

The challenge isn’t just having smart, capable people on your teams—it’s knowing who those people are, what they’re responsible for, how to reach them when you need them, and what context they can provide when problems arise. Think about it: when a critical vulnerability gets discovered at 2 AM, who gets the call? When a compliance audit comes knocking with specific questions about your application architecture, who has the answers? When developers need security guidance for a new feature, who do they turn to? When a production incident requires deep knowledge of how a particular component works, who understands it well enough to help troubleshoot?

This isn’t just about organizational charts gathering dust in HR systems or outdated contact lists that haven’t been updated in months. This is about creating a living, breathing system where ownership is crystal clear, responsibilities are explicitly defined, and accountability flows both ways—up to leadership and down to individual contributors.

The Cast of Characters You Actually Need

Let’s break down the key players every application needs in its corner, along with why each role matters for security and operational success:

The Application Owner

This is typically your product owner—the person who actually cares about whether the app succeeds or fails and has the business context to make informed decisions. They’re not necessarily the one writing code or configuring infrastructure, but they’re the one who understands what the application is supposed to do, why it matters to the business, and how it fits into broader organizational goals. When priorities need to be set, trade-offs need to be made, or resources need to be allocated, this person makes the calls.

From a security perspective, the application owner is crucial because they can authorize downtime for security updates, prioritize vulnerability fixes based on business impact, and make decisions about acceptable risk levels. They’re also the person who can speak to compliance requirements, data sensitivity, and business continuity needs.

The Development Team

These are the folks actually building and maintaining the application—the people who understand the code, the architecture decisions, and the technical debt. The software development team typically consists of specialists like product owners, project managers, business analysts, software designers, software engineers, and QA specialists. But here’s what matters most for security and operational purposes: we need to know who the contributing developers have been over the last 90 days.

Why 90 days? Because code changes constantly, and the person who wrote that critical authentication module six months ago might not be the same person who’s working on it today. They might have moved to a different team, left the company, or shifted focus to other projects. Recent contributors are the ones most likely to understand the current state of the application, recent changes that might have introduced security issues, and the context behind important architectural decisions.

Platform Engineering/Operations Team

These are the people responsible for getting your application from development into production and keeping it running reliably. They might not write the application code, but they control the infrastructure, deployment pipelines, monitoring systems, and runtime environment where security controls actually get tested and where attacks actually happen.

Platform and operations teams are critical for security because they understand the infrastructure dependencies, network configurations, access controls, and operational procedures that determine how secure your application actually is in practice. They’re also the ones who get called when things break, so they need to understand not just how to restore service, but how to do it securely.

The Security Lead

While responsibility for security is shifting from centralized teams to developers and product groups, there should always be a named security resource aligned to each application. This isn’t about creating bottlenecks or gatekeepers—it’s about having someone who can provide security expertise when needed, ensure that security considerations don’t get lost in the shuffle of feature development and deadline pressure, and serve as a bridge between application teams and broader organizational security initiatives.

The security lead understands the specific threat landscape for the application, knows what security controls are in place and how they work, and can provide guidance on everything from secure coding practices to incident response procedures.

The Security Team

Beyond just having a security lead, each application should have a clearly defined security team or at least know which security team they’re aligned with. This team provides the broader security context, threat intelligence, policy guidance, and organizational security standards that individual applications need to follow.

This team is responsible for things like vulnerability management processes, security testing and assessment, incident response coordination, and ensuring that security practices scale consistently across the organization.

Compliance and Regulatory Support

Not every application needs this, but when you’re dealing with healthcare data, financial information, personally identifiable information, or other regulated domains, someone needs to ensure the application meets all the necessary requirements. This person or team understands the specific regulatory landscape, compliance frameworks, audit requirements, and documentation standards that apply to your application.

Having clearly identified compliance support is essential because regulatory requirements often have specific timelines, documentation needs, and remediation procedures that differ from standard security practices.

Why This Matters More Than Ever

If you’re holding your DevSecOps teams accountable for fixing problems that only another department can actually address, your incentive structure is fundamentally out of alignment. This hits at the heart of why application ownership matters so much in modern software development.

When security issues are discovered, the clock starts ticking immediately. High-priority vulnerabilities need rapid response and remediation, but if nobody knows who’s supposed to fix them, those critical minutes and hours get wasted on organizational detective work instead of actual problem-solving. A lack of clear ownership for vulnerability management tasks often leads to unresolved risks that persist far longer than they should.

The problem gets exponentially worse as applications become more complex and distributed. As companies add more features to meet evolving user expectations, integrate with more external services, and adopt new technologies, the complexity of systems grows dramatically. More complexity means more potential failure points, more integration challenges, more specialized knowledge requirements, and more opportunities for things to slip through the cracks between teams.

Modern applications often span multiple teams, use dozens of different technologies, integrate with numerous external services, and deploy across complex infrastructure. Without clear ownership and responsibility mapping, it becomes nearly impossible to ensure that security considerations are properly addressed across all these different components and integration points.

The AppGraph Gets Personal

Just like we capture technical details in our AppGraph—the dependencies, APIs, data flows, and architecture—we need to capture the human elements too. Think of it as the “People Graph” that sits alongside your technical documentation and provides the human context necessary to actually manage and secure your applications effectively.

This isn’t just about having an organization chart or contact list. It’s about understanding the relationships between people and applications, the flow of responsibility and accountability, and the expertise and context that different individuals bring to the table.

At a bare minimum, your application’s people documentation should include:

The Application Owner: The single person (or clearly defined team) who has ultimate responsibility for the application’s success and can make decisions about priorities, trade-offs, and resource allocation. This person should be empowered to make decisions and held accountable for outcomes.

Contributing Developers (Last 90 Days): This isn’t just about current team members. Code written three months ago might have security implications today, and you need to know who to talk to about it. This rolling 90-day window captures the recent contributors who are most likely to understand the current state of the application, recent changes, and the reasoning behind important technical decisions.

Security Team Alignment: Which security team or individual is responsible for this application? This should include both the day-to-day security contact for routine questions and guidance, and the escalation path for serious incidents or urgent security issues.

This information needs to be living documentation—updated regularly, easily accessible, and integrated into your normal operational processes. When your vulnerability scanner flags a critical issue, when an incident response is triggered, or when an auditor asks questions, this information should be immediately available without requiring additional research or investigation.

Making It Stick

The biggest challenge isn’t creating this documentation—it’s keeping it current and making sure it actually gets used when it matters. Ownership means taking the initiative to solve problems in the way you, as a team, believe is best. That means ownership information needs to be part of your regular processes, not an afterthought that gets updated when someone remembers.

Consider integrating people information into your existing workflows and making it part of how teams naturally work. When code gets committed, when deployments happen, when security reviews are conducted, when team members change—these are all natural opportunities to verify and update ownership information.

Some teams tie this to their sprint planning or release processes, making ownership verification a standard part of their definition of done. Others integrate it with their ticketing systems so that when security issues are created, they’re automatically assigned to the right people with the right context. Still others make it part of their onboarding and offboarding processes, ensuring that ownership information gets updated whenever team composition changes.

The key is making sure that maintaining this information isn’t seen as bureaucratic overhead or compliance theater, but as an essential part of building and maintaining secure, reliable applications. Because at the end of the day, applications don’t secure themselves—people do.

When everyone knows who owns what, when responsibilities are clearly defined and communicated, and when accountability flows in both directions, security stops being something that happens to your applications and starts being something that’s built into them from the ground up. And honestly? That’s exactly where it should be.

Clear ownership also enables faster decision-making, more effective incident response, better knowledge sharing, and more sustainable long-term maintenance of both applications and security practices. It transforms security from a reactive scramble to a proactive, integrated part of how your organization builds and operates software.