Who Actually Owns Security in the SDLC?

It’s Friday afternoon. A SaaS company is preparing to release a new customer data export feature.

During final testing, someone discovers that a particular API request can retrieve records belonging to another customer organization.

The issue is potentially serious. The application is multi-tenant, and authorization boundaries are supposed to prevent one customer from accessing another customer’s data.

The security team recommends blocking the release.

Engineering agrees that the issue needs to be fixed but explains that implementing and testing the correction will delay delivery.

Product management points out that the feature has already been promised to an important customer.

The release manager asks whether Security can approve an exception.

Security responds that accepting business risk is not its responsibility.

The engineering manager asks who is authorized to make the decision.

Nobody has a clear answer.

This is a hypothetical scenario, but it exposes a fundamental weakness in how many organizations approach application security.

The company may have security policies, vulnerability-management procedures, automated scanning, and defined development workflows.

But when an important security decision must be made, accountability becomes unclear.

Everyone participates in security.

Nobody knows who owns the decision.

Security cannot become everyone’s responsibility unless the organization defines what that responsibility actually means.

And assigning responsibility is only useful when people have the authority, resources, and information required to act on it.

“Security is everyone’s responsibility” is not an operating model

There is nothing inherently wrong with saying that security is everyone’s responsibility.

Developers make security-relevant implementation decisions. Architects establish system boundaries. Product managers influence requirements and priorities. Platform engineers control deployment infrastructure. Security specialists identify risks and help establish appropriate controls.

All of these roles contribute to the security of the software.

The problem is that the phrase is frequently used as a substitute for defining accountability.

Consider a few practical questions.

Who ensures that a new feature has appropriate security requirements?

Who decides whether an architectural change needs threat modeling?

Who must implement a vulnerability fix?

Who decides whether the fix can be postponed?

Who determines whether the evidence is sufficient to release a high-risk change?

Who is responsible for improving the development process when the same vulnerability appears repeatedly?

If the answers depend on which individuals happen to be involved, the organization doesn’t have a reliable responsibility model.

It has informal coordination.

That arrangement might work reasonably well when a company has ten engineers who know each other and understand the entire application.

It becomes increasingly fragile as the company grows, responsibilities become specialized, and development spans multiple teams.

Informal ownership creates gaps between roles.

Security assumes Engineering will implement a control. Engineering assumes Security will specify it. Product assumes both teams have included the work in their estimates.

The control never gets implemented.

Not necessarily because anyone is negligent.

Because nobody was clearly accountable for ensuring that the work happened.

What OWASP SAMM tells us about governance

OWASP SAMM treats Governance as one of its five core business functions.

It contains three security practices:

Strategy & Metrics establishes how an organization plans, prioritizes, and evaluates its application security activities.

Policy & Compliance addresses the definition and implementation of internal security standards and applicable external obligations.

Education & Guidance focuses on providing people involved in software development with the knowledge, resources, and organizational support needed to build secure software.

These practices are closely related.

A security strategy without accountable implementation becomes a document.

A policy without engineering guidance becomes an obligation that developers must interpret independently.

Training without an environment that supports secure implementation has limited value.

Governance connects these elements and makes security expectations operational.

NIST SP 800-218, the Secure Software Development Framework, addresses responsibility even more explicitly.

Practice PO.2 — Implement Roles and Responsibilities recommends ensuring that people involved in the development lifecycle are prepared to perform their security-related responsibilities.

Task PO.2.1 covers defining roles, adjusting existing responsibilities, and periodically reviewing them.

This applies beyond the security department. The framework considers developers, project and product roles, senior management, testers, platform and operations engineers, and security personnel.

That is an important distinction.

Neither a policy document nor the appointment of a security officer automatically establishes an effective SSDLC governance model.

The organization must translate responsibilities into actual development activities and decision-making authority.

Four different responsibilities that companies frequently confuse

To make ownership practical, it helps to distinguish four types of decisions.

1. Who defines security expectations?

Someone must establish the minimum security requirements applicable across the organization.

These might include source-code protection, secure coding standards, secrets management, vulnerability handling, authentication expectations, and rules for accepting security exceptions.

This work typically involves AppSec or Security leadership together with Engineering, and sometimes Legal, Privacy, Compliance, and relevant business stakeholders.

The security function may own drafting and maintaining the standards. The appropriate leadership must approve them, ensure they are adopted, and provide sufficient support for implementation.

The crucial point is that expectations must be clear enough for engineering teams to act on.

A policy stating that “all applications must be developed securely” provides almost no practical guidance.

A standard requiring that authorization be enforced for every protected resource access, supported by approved implementation patterns and relevant verification procedures, is significantly more actionable.

2. Who implements security?

Engineering teams must own the security behavior of the software they deliver.

That includes implementing authorization correctly, handling sensitive information appropriately, following secure architectural patterns, and fixing security defects in their services.

However, this responsibility extends beyond individual developers.

Engineering managers must account for security work when planning capacity. Technical leads must make sound design decisions. Platform teams must provide reliable development and deployment infrastructure.

A developer cannot independently resolve an architectural weakness if the correction requires changing a shared service, redesigning an API, and obtaining time from several engineering teams.

Making developers responsible for security without giving engineering leadership responsibility for enabling secure development is an incomplete approach.

3. Who verifies security?

The person implementing a control should not always be the only person deciding whether it works.

Engineering teams can own automated security tests and provide evidence that expected behaviors are enforced.

QA engineers can incorporate negative security scenarios into test design.

AppSec specialists can define assurance requirements, review high-risk designs, evaluate testing approaches, and independently assess important controls where appropriate.

For particularly sensitive systems, independent penetration testing or specialist reviews may provide additional assurance.

These responsibilities can overlap, but their purpose should be clear.

Security verification must establish whether the implemented behavior satisfies the relevant requirements—not simply whether a tool completed successfully.

4. Who accepts residual risk?

This is often the most poorly defined responsibility.

Security teams may identify and assess risks, but that does not automatically give them authority to accept the business consequences of those risks.

Likewise, a product manager’s responsibility for delivery dates does not automatically grant permission to override security requirements.

The organization needs a documented risk-acceptance authority appropriate to the nature and severity of the decision.

Depending on the organization, this might be a designated business owner, engineering executive, risk committee, or another formally authorized role.

Security provides an assessment and recommendation. Engineering explains available remediation options and their implications. Product and business stakeholders explain delivery consequences.

The authorized decision-maker determines the response within the organization’s established risk appetite, policies, contracts, and legal obligations.

Not every risk is eligible for acceptance.

Where an obligation is mandatory, a risk exception cannot make noncompliance permissible. Some security conditions should prohibit release until the issue is remediated, the affected functionality is disabled, or an effective alternative control is established.

Risk acceptance is a controlled management decision, not a convenient way to bypass security requirements.

A practical responsibility model for a SaaS engineering organization

A responsibility matrix does not need to describe every possible development activity.

It should establish clear ownership for the decisions that matter most.

For example:

Security decision or activity	Primary accountable role	Supporting roles
Define organization-wide secure development standards	Authorized security/policy owner	Engineering, Legal, Privacy, Compliance
Define feature-specific security requirements	Product engineering owner	Product, AppSec, QA
Approve security architecture for a significant change	Designated technical authority	Architects, AppSec, Platform
Implement and maintain security controls	Application or platform engineering owner	AppSec, QA
Prioritize security remediation within policy limits	Engineering delivery owner	Product, AppSec
Accept material residual risk	Formally delegated risk-acceptance authority	Business owner, Engineering, Security, Legal as needed
Authorize release	Designated release authority, subject to mandatory gates	Engineering, Product, Security, Operations

This is an illustrative operating model, not an official SAMM responsibility matrix.

The same person may fill multiple roles in a small organization. A larger company may distribute responsibilities across several management layers.

What matters is that each important decision has a designated authority, supporting participants, and a record of the outcome when necessary.

A RACI matrix can help document those relationships.

But producing a RACI diagram is not the objective.

The useful test is whether people can answer who makes a decision when time is limited, information is incomplete, and priorities conflict.

If the diagram looks clear but the organization still argues about who can approve a release exception, the governance model has not been operationalized.

The responsibility gap between Product, Engineering, and Security

One of the most consequential SSDLC problems occurs where these three functions intersect.

Product management controls feature priorities and often influences delivery commitments.

Engineering owns implementation and technical quality.

Security establishes requirements, evaluates risks, and provides assurance.

Each function has legitimate responsibilities, but they do not always have aligned incentives.

Imagine that an authorization redesign requires two weeks of engineering effort.

Security identifies the weakness and recommends a correction.

Engineering agrees that the work is necessary but has no unallocated capacity.

Product management has already committed the team to several customer-facing features.

The vulnerability remains unresolved.

Technically, the problem is understood.

Organizationally, nobody has resolved the resource conflict.

This illustrates why simply assigning a vulnerability to a developer does not establish meaningful ownership.

The engineer may own the remediation implementation, while the decision to allocate capacity belongs to engineering and product leadership, within established security obligations.

If security work is consistently deferred, the problem may not be insufficient developer awareness.

It may be inadequate prioritization and leadership accountability.

Security must become part of delivery planning

When a feature creates meaningful security requirements, those requirements should be represented in the same planning process as functional work.

Security acceptance criteria should be included before development begins where feasible.

Significant design risks should be identified early enough to influence estimates and implementation decisions.

Security remediation should compete for engineering capacity through clear risk-based priorities, rather than relying on last-minute escalation.

This does not mean every security recommendation automatically receives maximum priority.

It means the trade-off becomes visible and is decided by people with appropriate authority.

The security function should also be accountable for the quality and usefulness of its recommendations.

Engineering teams need actionable requirements, not generic instructions to “make the feature secure.”

Good governance requires responsibilities on both sides.

Let’s revisit the multi-tenant SaaS example

In the previous articles, we examined an invoice API in a fictional multi-tenant SaaS platform.

Now suppose the team is adding a bulk invoice export feature.

Customers should be able to export invoices for their own organization, subject to their assigned permissions.

The feature crosses several engineering concerns: API authorization, background processing, temporary file storage, and potentially signed download URLs.

It is a useful example of how SSDLC responsibilities should operate in practice.

During planning

The product owner describes the feature and its expected business behavior.

The engineering lead identifies that the feature introduces new access paths to customer financial data and a background export process.

Because the application has a high-risk classification and the change affects authorization and data access, the team’s defined security-review trigger applies.

The security review is not happening because AppSec manually inspected every upcoming ticket.

It happens because the development process recognizes the relevant risk characteristics.

During design

The engineering team defines how tenant ownership and user permissions will be enforced.

The team considers whether an export job created by one user could be accessed by another, whether stored files could be retrieved across tenants, how authorization is handled by background workers, and how exported information is deleted after its retention period.

AppSec helps identify credible abuse scenarios and reviews significant assumptions.

The technical owner remains responsible for the resulting design.

If the change requires modifying a shared authorization component, the relevant platform or component owner participates.

A useful outcome would be an architecture decision, a set of security requirements, and agreed verification scenarios.

During implementation

Developers implement the feature using the organization’s approved patterns.

The implementation must not rely on a tenant identifier supplied by the caller without validating it against trusted identity and authorization context.

The background worker must preserve the correct authorization scope.

Download tokens, where used, must be appropriately protected, scoped, and time-limited.

Engineering owns the implementation. Platform teams own any shared infrastructure or identity services they provide.

Security can advise and review, but it should not become an alternative development team responsible for correcting every design problem.

During verification

The application team adds tests covering unauthorized cross-tenant access, permission boundaries, export-job ownership, and protected file retrieval.

For example, a test creates an export for a user in Tenant A and verifies that a user from Tenant B cannot retrieve the job or resulting file.

The test should cover the exposed access path, including the relevant API and storage authorization mechanisms, rather than only testing a helper method in isolation.

QA and AppSec may review the test scenarios or perform additional risk-based assessment.

The application team remains responsible for maintaining the tests as the feature changes.

When something goes wrong

Suppose a negative authorization test fails before release.

The engineering owner investigates and determines the correction required.

Product and engineering leadership address the delivery impact.

Security evaluates the risk, including potential exposure and available mitigations.

If the issue violates a mandatory release requirement, the release authority follows that requirement. A possible response is to withhold or disable the affected feature until the authorization boundary is correctly enforced and verified.

If a genuinely acceptable residual risk remains, the designated authority can evaluate it through the established exception process.

The issue does not disappear into an informal conversation.

The decision is recorded with its rationale, owner, evidence, and any required remediation deadline.

The SSDLC succeeds not because everyone participated in the discussion, but because every necessary decision had a clear owner and an actionable outcome.

Security Champions: a useful model that is often implemented badly

Security Champions programs are frequently proposed as the solution to limited AppSec capacity.

The logic is attractive.

Instead of having a small central security team responsible for every engineering group, organizations identify people within development teams who can help promote secure practices.

OWASP SAMM includes Security Champions in the Education & Guidance — Organization & Culture stream.

At its initial maturity level, SAMM describes identifying a Security Champion within development teams.

At higher levels, the model progresses toward a secure software center of excellence and a broader community that shares secure development knowledge.

This is a sensible progression.

But appointing champions does not automatically create an effective program.

A title is not a capability

Imagine appointing one developer in each team as its Security Champion.

The person receives additional security training and becomes the contact point for vulnerability reports and security questions.

So far, so good.

But their existing development commitments remain unchanged.

They are expected to attend security meetings, review findings, support threat modeling, and help colleagues without allocated capacity.

The role eventually becomes an extra obligation performed whenever other work permits.

The organization has distributed responsibility without providing the means to fulfill it.

The OWASP Security Champions guidance explicitly emphasizes management support, additional training, investment, and allocated time for security activities.

That is a crucial detail.

A Champion needs more than enthusiasm.

They need a defined scope of responsibility, support from their engineering manager, access to appropriate expertise, and time to contribute.

What should a Champion actually own?

A Security Champion can help the team recognize security-review triggers, facilitate lightweight threat-modeling discussions, improve developer guidance, and translate security findings into engineering work.

They can help teammates understand recurring weaknesses and identify opportunities for better implementation patterns.

They may also act as a connection between the central security function and the development team.

But they should not automatically become the person accountable for all vulnerabilities in their team’s software.

They should not be expected to approve every architectural risk, make business risk-acceptance decisions, or replace the engineering manager’s responsibility for prioritizing security work.

A Champion is an enablement role, not a convenient transfer of accountability.

This distinction matters even more in companies without a dedicated AppSec team.

A senior engineer may provide security leadership within a small organization, but the corresponding authority, capacity, and escalation process still need to exist.

A Security Champions program should distribute security capability, not distribute blame.

Who owns vulnerabilities discovered by security tools?

This is another area where responsibilities often become confused.

Suppose SAST identifies a potentially dangerous code pattern in a pull request.

The security team might own the scanner configuration, severity guidance, and rules for interpreting findings.

The repository owner is responsible for evaluating the finding in the context of the application.

If it represents a genuine defect, the application team normally owns the correction.

If the scanner produces repeated false positives, the owner of the scanning control should investigate how to improve its configuration and usefulness.

Now consider a vulnerable third-party dependency used across 20 services.

AppSec or a dedicated vulnerability-management function may coordinate triage, provide prioritization guidance, and identify patterns.

A platform team might own a shared dependency or base image.

Individual service teams may need to update affected applications and verify compatibility.

No single generic assignment of “Security owns vulnerabilities” captures this situation accurately.

The remediation responsibility should follow technical ownership and the organization’s remediation policy.

The coordination responsibility may be centralized.

The risk decision may sit with a formally designated authority.

Keeping these responsibilities distinct makes vulnerability handling more predictable.

It also creates an opportunity for systemic fixes.

If the same dependency problem affects many teams, addressing the shared build template or dependency-management process may be more effective than assigning identical tickets to every repository.

Who has the authority to stop a release?

This question deserves an explicit answer before an important security issue appears.

Many organizations have informal expectations that Security can block risky deployments.

Others consider release approval entirely an engineering responsibility.

Neither position is inherently sufficient.

What matters is defining release conditions and the authority associated with them.

For example, an organization may prohibit releasing newly introduced, demonstrably exploitable cross-tenant authorization failures.

It may require additional approval for certain high-impact vulnerabilities, while allowing lower-risk issues to proceed under defined remediation timelines.

These expectations should be documented, communicated, and reflected in release workflows wherever practical.

Security gates can enforce clearly defined conditions automatically.

Human review remains important where the risk cannot be reliably determined by an automated rule.

The key is that Security should not need to negotiate the organization’s risk appetite from scratch during every release.

And Engineering should not be forced to guess when a security finding must stop delivery.

A well-defined process distinguishes between a technical recommendation, a mandatory control, and a decision that can legitimately be made by an authorized risk owner.

It also includes an escalation path when participants disagree.

Good governance reduces recurring conflicts by clarifying the decision before the pressure arrives.

The minimum governance model doesn’t need to be complicated

For a small or medium-sized engineering organization, introducing a large governance structure may create more overhead than value.

A practical starting point can be relatively lightweight.

The organization needs a named person responsible for coordinating its application security program, even if this is not a full-time role.

It needs a documented secure development baseline that defines the expectations teams must meet.

It needs a way to identify high-risk applications and significant changes that require additional assurance.

It needs named technical owners for applications and shared components.

And it needs a clear process for remediation decisions, release exceptions, and risk acceptance.

These elements should connect to existing workflows.

A security standard should be accessible to developers and expressed through implementation guidance where possible.

A feature requiring security review should trigger that review during planning rather than immediately before release.

Vulnerabilities should be assigned to actual engineering owners, not a generic security backlog with no delivery accountability.

Significant exceptions should identify a risk owner, justification, compensating controls where relevant, and an expiration or reassessment condition.

That is already a meaningful improvement over relying on informal coordination.

The organization can introduce additional maturity as its application portfolio, engineering structure, and risk exposure justify it.

A practical first month

If an engineering organization wants to improve SSDLC accountability, the first month should focus on a small number of high-value decisions.

During the first week, select one or two important applications and identify the people currently involved in security requirements, design reviews, remediation, and release decisions.

Ask how those decisions work today—not how the official policy says they should work.

In the following weeks, examine a few real examples: a feature that required security review, a vulnerability that needed prioritization, and a release that involved a security exception.

For each example, establish who made the decision, whether they had the authority and information to make it, and whether the outcome was properly recorded.

Use those findings to define a lightweight responsibility and escalation model.

Then apply that model to an upcoming high-risk change.

Do not declare the governance initiative successful simply because a responsibility matrix has been published.

Validate whether the people involved understand their responsibilities and whether the process produces timely, defensible decisions.

Only then expand it to more teams.

This approach is usually more informative than starting with a lengthy policy document disconnected from engineering reality.

Measuring accountability without creating more security theater

Governance is often measured through document completion.

How many policies have been approved? How many developers have completed training? How many teams have appointed Security Champions?

These measures can indicate program coverage, but they say relatively little about whether responsibility works.

A stronger assessment looks at the actual outcomes of security decisions.

For example, can high-risk applications be linked to accountable engineering owners?

Do significant security findings reach the correct delivery team without repeated reassignment?

Are important release exceptions supported by documented decisions from authorized people?

Do approved exceptions expire, get remediated, or undergo reassessment rather than remaining open indefinitely?

Are security requirements and review obligations considered before engineering commitments become difficult to change?

These questions reveal the functioning of the governance model, not merely its existence.

However, metrics should not create incentives for superficial compliance.

Measuring the percentage of high-risk changes reviewed is useful only if those reviews identify meaningful risks and result in actionable outcomes.

Counting Security Champions is useful only if the people in those roles are supported and contribute to the teams’ security capabilities.

The objective should be to improve decision quality, consistency, and accountability.

The reporting should support that objective.

Security leadership is about enabling engineering, not controlling every decision

There is a legitimate concern that stronger security governance can slow development.

It can.

If every change requires central approval, AppSec becomes a bottleneck.

If security standards are written without engineering involvement, they may impose unrealistic requirements.

If vulnerability prioritization ignores delivery constraints, teams may stop treating security recommendations as credible.

But the answer is not to eliminate governance.

It is to design governance that scales.

Standardize decisions that can be made consistently. Provide secure defaults and reusable components. Define clear triggers for additional review. Let engineering teams make decisions within agreed boundaries.

Reserve specialist involvement for situations where it provides meaningful additional value.

Security teams should be accountable for clear requirements, relevant expertise, effective controls, and timely advice.

Engineering leadership should be accountable for making secure delivery achievable.

Product leadership should include meaningful security requirements when making scope and delivery decisions.

And the organization’s designated risk owners should be accountable for decisions involving material residual risk.

These responsibilities complement each other.

They should not become competing sources of authority.

The real test of SSDLC ownership

Imagine asking five people in an engineering organization the same question:

“Who is responsible for ensuring that a critical authorization vulnerability is resolved before release?”

The developer says the engineering manager.

The engineering manager says Security.

Security says Product owns the release decision.

Product says Engineering owns technical quality.

The release manager says the pipeline is green.

That organization does not have a functioning responsibility model for the decision.

Now imagine a different response.

The application team owns the correction and verification.

The engineering manager ensures that the work has the capacity and priority required.

Security assesses the risk and provides independent guidance.

The release authority applies the organization’s mandatory release requirements.

Any permissible residual risk decision is made by the formally authorized owner and recorded.

There can still be disagreement about technical solutions, delivery timing, or the appropriate response.

But disagreement no longer means uncertainty about who must decide.

That is what useful SSDLC governance should accomplish.

Security is a shared responsibility. Accountability for a specific decision should never be ambiguous.

An effective Secure Software Development Lifecycle does not require security specialists to control every engineering activity.

It requires a clear operating model in which security expectations are understood, engineering responsibilities are supported, important decisions have defined authority, and the outcomes can be demonstrated.

Without that foundation, even well-designed security controls depend too heavily on individual initiative.

With it, security becomes a normal and accountable part of building software.

And once those responsibilities are clear, the next challenge is translating security expectations into requirements that development teams can actually implement and test.

---

Is security ownership unclear in your development process?

Security policies, CI/CD controls, and vulnerability-management procedures provide limited assurance when accountability breaks down between Engineering, Product, and Security.

TheOnlySecurity’s SSDLC assessment and consulting approach helps organizations evaluate governance maturity, clarify security responsibilities, establish practical review and escalation processes, and turn security expectations into engineering activities.

The focus is on building security practices that teams can consistently follow—not introducing additional approval layers for their own sake.

Explore SSDLC Assessment & Consulting →