Legacy systems, feature flags, and secrets governance at /dev/mtl

At a glance

What this is: This is GitGuardian's recap of /dev/mtl 2025, focused on how feature-flag sprawl, tracing gaps, legacy code, and secrets governance all point to the same operational problem: complexity without lifecycle discipline.

Why it matters: It matters because IAM, NHI, and platform teams face the same pattern in production systems: if access, flags, and test conditions are not observable and retired on time, governance becomes guesswork.

👉 Read GitGuardian's recap of feature flags, testing drift, and secrets governance at /dev/mtl

Context

Feature flags, tracing, and secrets governance all fail in the same way when teams add complexity faster than they can observe and retire it. In identity programmes, that maps directly to access that outlives its purpose, test conditions that drift from reality, and credentials that remain active long after the system around them has changed.

GitGuardian's recap of /dev/mtl 2025 draws together developer sessions on testing, performance, legacy code, and secrets security. The common thread is not any single tool, but the governance gap that appears when temporary controls become permanent, feedback loops weaken, and teams lose confidence in what is still active.

Key questions

Q: What breaks when feature flags start controlling access decisions?

A: Auditability breaks first, because reviewers can no longer tell whether a user was blocked by release logic or by entitlement policy. Over time, this also weakens separation of duties and creates inconsistent behaviour across environments. The application becomes harder to certify because the same toggle now carries both product and security meaning.

Q: Why do observability gaps create so much operational risk in legacy systems?

A: Because teams cannot distinguish a real defect from hidden state, repeated database calls, or stale configuration behaviour. Without visibility into how a request actually moves through the system, governance becomes guesswork and troubleshooting becomes slow and expensive. Observability turns invisible complexity into something that can be reviewed, challenged, and controlled.

Q: What are the signs that secret governance is failing?

A: Common signs include secrets that never expire, weak rotation discipline, and inconsistent lifecycle management across vaults and applications. Another warning signal is when security teams cannot quickly identify where a secret is used or who owns it. If those controls are missing, the organisation is likely relying on fragile manual processes instead of enforceable policy and continuous oversight.

Q: How should teams handle feature flag drift in production and test environments?

A: They should treat flags as governed runtime dependencies, not as temporary developer conveniences. That means tracking ownership, restricting who can change them, testing the combinations that matter, and archiving flags when the feature is stable. If the environment cannot show which flags are active, it cannot support reliable release decisions.

Technical breakdown

Why feature flags make test state explode

Feature flags multiply the number of runtime states a system can occupy. Every new binary flag doubles the combinations that end-to-end tests must account for, which is why teams quickly move from a manageable test matrix to an opaque one. The technical issue is not flags themselves, but the interaction between rollout percentage, environment mismatch, and stale assumptions about what the application should be doing. When test execution becomes dependent on hidden flag state, failures stop being deterministic and start looking random, even when the code has not changed.

Practical implication: model flags as part of the tested state space, not as a hidden implementation detail.

Why tracing exposes the N+1 query pattern

The N+1 problem appears when a single request triggers one query to fetch a list and then many more queries to hydrate each item or relationship. Object relational mappers often make this easy to miss because lazy loading hides the true number of round trips until performance degrades. Tracing reveals the full request path, including the middleware behaviour between the application and the database. That matters because the issue is architectural, not just a slow query. Join fetches and batch-size tuning can reduce the pain, but they do not remove the underlying coupling between data shape and access pattern.

Practical implication: use tracing to find hidden query fan-out before it turns into a production incident.

Why secrets governance depends on lifecycle discipline

Secrets governance is not only about storing credentials securely. It is about giving every secret a clear purpose, owner, and end-of-life path so that plaintext credentials, stale values, and unmanaged system secrets do not accumulate as silent risk. In production systems, the hardest failures usually come from things that were meant to be temporary but were never retired. That is the same pattern seen in feature flags and testing drift: the control stays in place after the original reason for it has gone. The security consequence is excess exposure with no clear operational justification.

Practical implication: treat every secret as a lifecycle object and retire it as deliberately as you create it.

NHI Mgmt Group analysis

Temporary controls become governance debt when teams do not retire them. Feature flags, test toggles, and secrets all begin as bounded exceptions, but they become part of the control surface once teams stop tracking their purpose and expiry. The article's strongest theme is that complexity is not the problem by itself. The problem is unmanaged persistence, which turns a helper mechanism into an access and operations liability.

Observability is the difference between controlled change and blind drift. If you cannot see which flag state, query path, or secret is active, you cannot govern the system with confidence. That is why tracing, explicit defaults, and reviewable lifecycle states matter more than heroic debugging. Practitioners should treat invisibility as a governance failure, not just a developer inconvenience.

Lifecycle discipline is the named concept this event keeps pointing toward. The article shows that temporary implementation choices need explicit retirement, especially where access, configuration, or security behaviour can linger beyond the original use case. That discipline is the practical boundary between experimentation and operational sprawl. Teams that do not enforce it end up carrying yesterday's exceptions as today's risk.

Security and delivery teams are solving the same complexity problem from different angles. Testing drift, database fan-out, and secrets sprawl all reward the same control pattern: narrow scope, observable behaviour, and deliberate end-of-life planning. That cross-functional overlap matters because identity and access governance breaks in exactly these environments when no one owns the cleanup. Practitioners should align engineering hygiene with governance ownership.

The article reinforces that normal teams need guardrails, not heroics. The most durable systems are the ones where safe behaviour is the default and exceptions are visible. That is as true for feature flags and query design as it is for NHI secrets and privileged access. The takeaway for the field is simple: design for routine control, not exceptional memory.

What this signals

Lifecycle discipline is becoming the common control language across release engineering, observability, and identity security. The teams that keep flags, traces, and credentials visible are the ones most likely to avoid operational sprawl turning into governance debt.

Lifecycle discipline: temporary controls only remain safe when they have an owner, an expiry, and a visible retirement path. That concept now applies just as much to feature flags and test fixtures as it does to secrets and access exceptions.

For practitioners

• Audit temporary controls for retirement Inventory feature flags, test toggles, and security exceptions that were meant to be short-lived. Assign an owner and a retirement date to each one, then remove anything that no longer has an active business reason to exist.
• Make flag state explicit in testing Build end-to-end tests around known flag combinations and keep flag state visible in fixtures or targeted user contexts. Do not rely on implicit environment defaults if the purpose is to prove a deterministic path.
• Use tracing to find hidden fan-out Trace request paths that touch the database, especially where lazy loading or ORM behaviour may hide repeated lookups. Focus remediation on the query patterns that create the most unseen operational load.
• Treat secrets as lifecycle-managed assets Track where secrets are created, how long they remain valid, and who is responsible for revocation. Plaintext credentials, orphaned values, and undocumented exceptions should be removed through the same governance process as other stale access paths.

Key takeaways

• The event's core lesson is that complexity becomes risk when systems keep temporary controls after their original purpose has passed.
• Tracing, testing discipline, and deliberate retirement of flags or secrets are the practical controls that reduce hidden operational drift.
• For identity and security teams, the best defence is to treat access, configuration, and secrets as lifecycle-managed assets rather than permanent fixtures.

Key terms

• Feature Flag Drift: Feature flag drift is the condition where flags remain active, misaligned, or poorly understood after the original release use case has passed. In practice, this creates hidden runtime states that make testing, troubleshooting, and governance harder because the system behaves differently depending on stale configuration.
• Lifecycle discipline: Lifecycle discipline is the practice of managing identities through joiner, mover, and leaver states so access stays appropriate as roles change. In regulated environments, it is what keeps access, approvals, and evidence aligned with the organisation’s actual operating state.
• Observability: Observability is the ability to understand the internal state of a system from the data it produces. In security and operations, that means combining logs, metrics, and traces so teams can explain why something happened, not just confirm that something changed.
• Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.

What's in the full article

GitGuardian's full recap covers the operational detail this post intentionally leaves for the source:

• Speaker-by-speaker context from the /dev/mtl developer tracks
• The specific examples used to explain feature-flag testing drift
• The talk-level framing behind the database tracing discussion
• The secrets security session context shared from the event floor

👉 GitGuardian's full recap adds speaker context, session detail, and the event's cross-community security themes.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.