What do security teams get wrong about replacing scripts with configuration?

Why This Matters for Security Teams

Security teams often treat configuration as a cleaner replacement for scripts, but that framing misses the real risk. Configuration is best at expressing stable, repeatable settings. Scripts still matter when the logic is conditional, stateful, or tied to exception handling. The security problem is not code versus config. It is whether the sensitive behaviour is easy to audit, tightly scoped, and resistant to drift. NHI governance failures often start the same way, with secrets or access logic hidden where teams assume “simple automation” is harmless, as seen in the patterns discussed in the Ultimate Guide to NHIs and the Twitter Source Code Breach. The danger is that configuration can become a control plane for privilege without the same scrutiny applied to software. That is why baseline hardening should still align with control discipline such as NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams discover over-permissioned configs only after the automation has already been copied, reused, and trusted across environments.

How It Works in Practice

The practical answer is to classify automation by complexity and risk. Use configuration for standardised, low-variance behaviour such as environment variables, policy thresholds, allowlists, and deployment settings. Keep scripts for logic that requires branching, parsing, exception handling, or secure sequencing. That division reduces custom code without pretending all automation can be flattened into declarative settings.

For NHI-heavy environments, the same principle applies to secrets and service identities. Configuration should not contain long-lived credentials if a secrets manager or short-lived token can be used instead. Current guidance suggests treating configuration as a pointer to controlled material, not the material itself. A secure pattern is to combine declarative policy with operational guardrails:

• Store only non-sensitive parameters in config, and reference secrets from a vault or workload identity system.
• Use scripts for task-specific logic, but limit execution scope and review them like production code.
• Prefer short-lived tokens and ephemeral access over static keys embedded in pipelines or config files.
• Log who changed the config, what changed, and whether the change altered privilege or secret handling.

This is consistent with the NHI security findings in the State of Non-Human Identity Security, where visibility and rotation gaps remain common. It also maps cleanly to the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasise controlled access, change management, and accountability. These controls tend to break down in fast-moving CI/CD environments because config is copied faster than reviewers can validate whether it now contains implicit privilege.

Common Variations and Edge Cases

Tighter configuration governance often increases operational overhead, requiring organisations to balance speed against traceability. That tradeoff becomes visible in edge cases where “just use config” is not enough. For example, dynamic routing, content transformation, or cross-system reconciliation often needs scripts because the business logic changes too often for clean declarative policy. In those cases, best practice is evolving toward a layered model: config defines the approved boundaries, while scripts implement the minimum necessary logic inside them.

Another common mistake is assuming all scripts are equally dangerous. They are not. A small, version-controlled script with clear ownership is usually safer than a sprawling configuration file that silently grants access or stores secrets. The same caution applies when teams use config to enforce privilege. If the configuration is the policy engine, then every change can become an access-control event. That is why teams should separate static settings from security decisions wherever possible and review both through the lens of privilege, not convenience.

For teams handling NHIs, the lesson is simple: do not move risk from code into config and call it an improvement. Use configuration to reduce variance, but keep the exception paths explicit, documented, and reviewable. Where there is no universal standard for a pattern yet, such as how much logic is acceptable in declarative pipelines, the safest approach is to minimise hidden behaviour and require independent approval for anything that changes identity, secrets, or execution authority.

Related resources from NHI Mgmt Group

• What do security teams get wrong about using APIs to manage user roles and application licences?
• What do security teams get wrong about scaling identity controls across regions and channels?
• What do security teams get wrong about access control when they focus only on login authentication?
• What do security teams get wrong about authorizing AI workflows?