Who is accountable for reducing attack surface across code, pipelines, and cloud assets?

Accountability should sit with a shared security and engineering model, because attack surface is created across multiple teams. Security sets policy, telemetry, and guardrails, while engineering owns secure implementation in code and automation. Governance should define clear ownership for repositories, secrets, infrastructure templates, and CI/CD controls so gaps do not fall between teams.

Why This Matters for Security Teams

Attack surface reduction across code, pipelines, and cloud assets fails when ownership is split by technology layer instead of by risk. Repository controls, secret handling, build automation, and cloud permissions are often managed by different teams, yet attackers move across all of them with a single foothold. That is why accountability has to be shared, with security defining guardrails and engineering owning secure implementation and remediation.

This is not theoretical. Recent NHIMG research on the CI/CD pipeline exploitation case study and the Guide to the Secret Sprawl Challenge shows how small control gaps in one layer can expose credentials, artifacts, and infrastructure across the stack. External guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access control, configuration management, and monitoring must be coordinated, not siloed.

In practice, many security teams discover the ownership gap only after a pipeline secret, misconfigured role, or exposed template has already been used to expand access.

How It Works in Practice

A workable model assigns accountability by asset type and control plane, while keeping one shared governance layer for policy, telemetry, and exceptions. Security usually owns standards for repository protection, secret storage, branch controls, build attestation, cloud posture, and detection. Engineering owns the secure-by-default implementation in application code, pipeline definitions, infrastructure as code, and runtime configuration.

The operational goal is to make the same ownership logic visible from commit to deployment. That means code owners for repositories, named approvers for pipeline changes, and clear cloud asset owners for accounts, subscriptions, clusters, and key management. In agentic or automated environments, this also means tightening the rules around identities that can act on behalf of workloads, including short-lived credentials and workload identities rather than long-lived secrets.

• Map every repository, pipeline, secret store, and cloud account to a named business and technical owner.
• Set minimum controls for secrets scanning, IaC review, least privilege, and build integrity checks.
• Instrument logs so security can verify who changed what, when, and from where.
• Use policy-as-code to prevent drift across CI/CD and cloud platforms.

NHIMG’s 2024 Non-Human Identity Security Report notes that only 19.6% of security professionals express strong confidence in securely managing non-human workload identities, which is a strong signal that ownership and technical control still diverge. External research such as the Anthropic report and MITRE ATT&CK Enterprise Matrix also underscores how attackers chain initial access, credential access, and lateral movement across build and cloud layers.

These controls tend to break down in fast-moving platform teams with shared admin access and no single owner for pipeline changes because accountability becomes procedural instead of enforceable.

Common Variations and Edge Cases

Tighter ownership models often increase review overhead, so organisations have to balance velocity against assurance. That tradeoff is real in monorepos, multi-cloud estates, and highly automated delivery environments where one team may maintain the platform and another may own the product workload.

There is no universal standard for exactly how to split accountability, but current guidance suggests separating policy ownership from execution ownership. Security should define required controls and evidence, while product and platform engineering should be accountable for implementation, exceptions, and remediation timelines. In mature programs, shared responsibility is written into RACI matrices and control catalogs so the handoff is explicit.

Edge cases appear when external contractors, ephemeral environments, or machine-generated infrastructure complicate the normal ownership chain. In those settings, the safest pattern is to tie responsibility to the system of record: the repository for code, the pipeline definition for automation, and the cloud account or subscription for runtime assets. NHIMG’s 52 NHI Breaches Analysis and OWASP NHI Top 10 both reflect the same operational lesson: unclear identity and control ownership creates the conditions for fast privilege expansion.

For this reason, accountability should be measured by whether a team can prove control over its own attack surface, not by whether it claims general oversight.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• Who is accountable when JIT access is used across cloud services, pipelines, and admins?
• Who is accountable when cloud AI tools widen the attack surface?
• How should security teams implement attack surface discovery across cloud and development environments?