How should DevSecOps teams handle exposures that sit outside IaC coverage?

Why exposures outside IaC still count as part of delivery

Anything deployed, configured, or left reachable outside infrastructure as code is still part of the production attack surface. The practical question is not whether IaC touched it, but whether the asset can create exposure, drift, or privilege pathways today. That is why teams should treat it as live operational state, with the same seriousness they apply to managed infrastructure.

Once an exposure sits outside IaC, it no longer benefits from the same reviewability, repeatability, and rollback discipline as codified resources. A good mental model is to treat it as a change-management problem first and a tooling problem second. If it is real enough to be exploitable, it is real enough to be inventoried, owned, and remediated.

Practitioners often miss that iac coverage is not the same thing as environment coverage. Many teams discover that the highest-risk gaps are not in the template itself, but in manual exceptions, emergency fixes, inherited cloud objects, forgotten access paths, and one-off configuration changes. Managing those exposures requires a separate control path, not a hope that the next IaC refactor will absorb them.

How to handle the gap without creating permanent exceptions

The best approach is to split the world into two states: governed-by-IaC and governed-directly. Items outside IaC should enter a tracked backlog as security debt, with an owner, a remediation target, and a reason they are still outside codification. That avoids the common failure mode where temporary exceptions quietly become the real baseline.

Direct remediation should use normal change control, not informal cleanup. If the asset can be safely codified, move it into IaC as part of the fix. If it cannot yet be codified, remediate the exposure in place and record why the coverage gap remains. This keeps the issue visible while preserving the ability to move toward a more complete desired state.

For devsecops teams, the key operational distinction is between future-state governance and present-state control. IaC is excellent for preventing recurrence, but it is not a substitute for removing an existing exposure. The team needs both: a direct path for current risk and a codification path for preventing the same class of drift from reappearing.

What good remediation looks like in practice

Start with a separate inventory of unmanaged assets and exposures, then rank them by blast radius, internet reachability, privilege, and business criticality. An exposure that can reach sensitive data or production systems deserves immediate attention, even if it is small or “temporary.” Ownership should be explicit, because ambiguous ownership is what allows these items to persist.

Remediation should be tied to the specific failure mode. For example, harden the exposed service, rotate or revoke the credential, remove the public endpoint, correct the permission, or decommission the asset if it is no longer needed. Then decide whether the control should be moved into IaC so the fix becomes durable. The point is to close the exposure first and only then improve the delivery pattern.

Teams handling this well usually maintain a clean handoff between platform engineering, application owners, and security. IaC authors own the codified estate. Asset owners own the unmanaged remainder until it is either removed or brought under the same control plane. That ownership model is what prevents “out of scope” from becoming “out of sight.”

Risk and Threat Considerations

Exposures outside IaC are attractive because they often escape the normal review, detection, and approval loop. Attackers and insiders alike benefit from inconsistent state, especially when a manual object holds credentials, a public endpoint, or a privileged exception that no longer appears in code review.

Failure mechanism: Manual or legacy assets drift away from the intended baseline, leaving an untracked path for access, misconfiguration, or secret exposure. Because the asset is not governed by the same declarative source, teams may fail to notice when it becomes overprivileged, internet-facing, or difficult to rotate.

Impact: The result can be persistent attack surface, slower incident response, and remediation that depends on tribal knowledge rather than authoritative configuration. At scale, these gaps can become systemic, especially when many “small” exceptions accumulate across cloud, CI/CD, and application environments.

Practitioner Guidance

What to prioritise: Remediate exposures that combine reachability with privilege first, especially anything that can authenticate to production systems or expose sensitive data. Do not wait for an IaC migration plan if the current state is already unsafe.

What to verify: Confirm each unmanaged item has a named owner, a documented reason it is still outside IaC, and a recorded disposition, either codify, remediate directly, or retire. If none of those exist, you do not have a controlled exception, you have unmanaged security debt.

Common mistake: Treating “not in IaC” as a procedural detail instead of an exposure class. That mindset delays remediation and encourages teams to normalize drift as a feature of delivery.

Practitioner takeaway: Use IaC to prevent recurrence, but use direct change control to eliminate today’s exposure, because the asset is risky the moment it exists outside the codified boundary.

Related resources from NHI Mgmt Group

• How should security teams handle legacy applications and privileged accounts that sit outside single sign-on coverage?
• How should security teams handle risks from AI browser extensions?
• How should teams handle secrets that have no obvious owner?
• How should security teams handle disconnected applications that sit outside identity tooling?