Configuration management is the practice of knowing what every system in your estate is supposed to look like, and keeping it that way. It covers the inventory of assets and their dependencies, the approved settings each one runs with, and the process that governs how those settings change.
On August 1, 2012, Knight Capital deployed new code incorrectly. In the first 45 minutes of trading, its router sent more than 4 million orders to fill 212 customer orders. The firm lost more than $460 million, and the SEC later fined it $12 million. No attacker was involved. A change reached production in a state nobody had approved.
This page covers what configuration management is, how it differs from change management and from security configuration management, the six steps of the cycle, the tools that automate it, and what our 2025 data says about where configuration flaws actually surface.
What is configuration management?
Configuration management is an IT process that tracks, controls and documents changes to a system’s configuration, resources and services. It records every component, setting and dependency, and how they relate. Good configuration management answers one question at any moment: is this system running what we approved?
The discipline is older than software. The U.S. Department of Defense formalized it for military systems in its 480 series of standards, version control brought it into software development, and DevOps made it a daily practice once teams began shipping infrastructure as often as code.
Security adds a second layer. NIST calls it security-focused configuration management, or SecCM, and sets its goal as managing and monitoring system configurations to “achieve adequate security and minimize organizational risk while supporting the desired business functionality” (NIST SP 800-128, updated in 2019). The distinction is worth keeping: ordinary configuration management asks whether a system matches its approved state, while security-focused configuration management asks whether that approved state is safe in the first place. A fleet can be perfectly consistent and uniformly insecure.
Why is configuration management important?
Configuration management matters because settings now carry as much risk as code. A permission, a firewall rule or a storage policy decides what an attacker reaches once inside, and those decisions live in files that change far more often than application logic. That is what turned configuration management from an operations concern into a security control.
Security misconfiguration is now the second most common weakness class
Fluid Attacks’ analysis of the 2025 OWASP Top 10 found that security misconfiguration climbed from fifth place in 2021 to second in 2025, now covering 16 CWEs and present in 3% of the applications tested. Over the same period, more application behavior moved out of compiled code and into configuration files, cloud permissions and infrastructure templates.
Most configuration flaws are cheap, and a few are not
Of the 1,119,396 vulnerabilities we reported across client systems in 2025, insecure service configuration on EC2 alone accounted for 44,667 findings carrying 149,840.91 CVSSF units of risk exposure (State of Attacks 2026). Unauthorized access to files in cloud storage services added 13,499 findings and 500,832.48 CVSSF.
Then the other kind. Non-encrypted confidential information in Azure appeared in just 4.8% of systems and 1,789 findings, yet carried 809,671.94 CVSSF — more risk than the EC2 and storage findings combined, from 3% of their volume. Volume and risk are not the same thing, and a configuration management program that treats every drifted setting as equally urgent will spend its time on the wrong ones.
It is what makes an environment reproducible
Without a recorded desired state, no environment can be rebuilt with confidence, no incident can be traced to the change that caused it, and no auditor can be shown what the system looked like last quarter. Reproducibility is the quiet benefit of configuration management, noticed only when it is gone.
A team with a versioned desired state restores from it; a team without one rebuilds from memory.
Configuration management, change management and security configuration management are not the same
The three terms overlap and are routinely swapped. They answer different questions, and conflating them is how a team ends up with a clean change log over an insecure estate.
Practice | Question it answers | What it controls | What fails without it |
|---|---|---|---|
Configuration management | What is this system supposed to look like, and does it? | Inventory, dependencies, approved settings, drift | Environments stop being reproducible; incidents cannot be traced |
Change control | Who approved this change, and when? | The request, review, approval and rollback path | Unreviewed changes reach production, as at Knight Capital |
Security configuration management | Is the approved state itself safe? | Hardened baselines, least privilege, encryption | The estate is consistent and uniformly exposed |
A practical rule: change control tells you a setting moved, configuration management tells you where it moved from and to, and only security configuration management tells you whether the destination was somewhere you wanted to go.
Configuration management at Fluid Attacks
We do not sell a configuration management platform. We test the configurations that one produces — in the templates before they deploy, in the cloud account after they do, and in the running application, with DAST and manual testing, where their consequences show up. Our role in a configuration management program is narrow: we tell you which approved settings are not safe.
What we assess, and under what rules
Every assessment runs against a defined scope and a written criterion. For configuration management findings, the governing requirement is number 062 in our open catalog, which states that “the system must follow the industry’s standard configurations that prevent all known vulnerabilities.” That requirement maps to CIS Controls 4.1 and 4.2, ISO/IEC 27001 control 8.9, PCI DSS 2.2.6 and NIST SP 800-171 3.4.2, so a finding against it is already expressed in the language an auditor uses.
What it looks like in practice
Where the configuration lives | How we test it | Example criteria |
|---|---|---|
IaC and configuration files: Terraform, CloudFormation, Kubernetes, Helm, Docker Compose, ARM | SAST over the repository | Terraform excessive attach privileges; Terraform publicly accessible true |
The deployed AWS account | AWS permissive role policies; AWS admin policy attached; AWS unrestricted security groups | |
Identities and roles, wherever they are defined | SAST, CSPM and manual review | Excessive privileges - AWS: “the application, a user or a role have more privileges than they require” |
What the configuration enables in production | PTaaS and manual testing | Unrestricted access between network segments - AWS; Insecure service configuration - ELB; Improper authorization control for web services - RDS |
The change, before it merges | CI Gate in the pipeline | Policy on unremediated findings by severity |
Our requirement 062 and the controls it maps to, as published in our open criteria catalog.
What manual testing finds that scanners do not
A scanner reads a setting. A pentester works out what the setting lets them do. The gap between those two shows up clearly in our own numbers.
Measure | Automated tools | Pentesters |
|---|---|---|
Share of vulnerabilities reported in 2025 | 88.4% | 11.6% |
Share of risk exposure reported in 2025 | 55.8% | 44.2% |
Share of critical vulnerabilities | 13% | 87% |
Mean risk exposure per finding (CVSSF) | 15.5 | 93.2 |
Automated tools report most findings; pentesters report most of the risk. Source: State of Attacks 2026.
The same split appears under controlled conditions. In Fluid Attacks’ benchmark of 36 third-party AppSec tools against an application seeded with 1,201 vulnerabilities across 105 CWE categories, a pentester reached 89.6% recall at 100% precision, covering 86.8% of the total risk exposure. The best-performing automated scanner was our own, at 99% precision but 22.7% recall and 8.8% of the risk exposure. Those manual assessments are run by certified offensive security professionals.
What our CSPM covers
Our cloud security posture management scanner analyzes AWS environments for vulnerable configurations. That is a deliberate scope, and it is worth stating plainly rather than implying wider coverage.
It is also not where every cloud configuration finding comes from. The costliest configuration weakness in our 2025 data — non-encrypted confidential information, at 809,671.94 CVSSF — was in Azure. Azure and GCP configurations reach us through IaC templates read by SAST and through manual pentesting, which is why the templates in your repository matter as much as the account they deploy into. For most teams, configuration management coverage starts in the repository and not in the console.
Review infrastructure pull requests like payment code
The practice that decides how well the rest works is simple and almost always skipped. Our review of the 2026 Binance incident makes the point directly: when a repository defines infrastructure in Terraform, Kubernetes manifests or Docker Compose files, a configuration flaw is a code flaw, and a pull request that changes a role binding or a firewall rule deserves the same review as a change to payment logic.
The data backs the habit. Among the systems we assessed in 2025, those running our CI Gate in the pipeline reached a 72.2% remediation rate against 58% without it, and a median remediation time of 22 days against 30 — 26.7% faster. Putting the gate in the pipeline is what makes configuration management enforceable instead of advisory.
How configuration management works
Configuration management runs as a six-step loop, not a project with an end date. Each step produces an artifact the next one depends on.
1. Identify assets
Inventory every system, service, dependency and owner. An asset nobody owns is an asset nobody patches. Many teams hold this inventory in a configuration management database, which stores those components and their relationships.
2. Define secure baselines
A configuration baseline is the approved state: the settings a system is expected to run with, written down and versioned. CIS Control 4 (Controls v8.1) asks organizations to “establish and maintain the secure configuration of enterprise assets” — end-user devices, network devices, IoT and servers — “and software.” Vendor defaults are tuned for installation, not for safety, so the baseline is where hardening gets specified, not assumed. Fluid Attacks’ writing on secure-by-default products argues that manufacturers should ship sufficiently secure configurations so customers are not left doing this work alone.
3. Control changes
Every deviation from the baseline goes through review, approval and a recorded rollback path. Permissions deserve the strictest version of this. The principle of least privilege is the one baseline setting that limits damage from every other mistake, and our security analyst Jonathan Armas put the cost of ignoring it bluntly in Secure cloud as code:
“An open port is a window to your infrastructure increasing the attack surface that we as pentesters can exploit, so why open it to the world?”
In the same post he notes that most of the AWS keys he has compromised were configured with excessive permissions.
4. Automate with infrastructure as code
Terraform and AWS CloudFormation let teams write infrastructure definitions as code, store them in a repository and deploy them through a pipeline. That turns a configuration into a reviewable, versioned, reproducible artifact — and into something a scanner can read before it ever reaches a cloud account. This is also where DevSecOps earns its keep: our writing on securing cloud deployments identifies misconfiguration of cloud services as a leading cause of disaster, and argues for detecting it in IaC files and container images, not in production. Implementing DevSecOps is easiest to start here, because the artifacts are already in version control.
5. Monitor configuration drift
Drift is the gap between the approved baseline and what is actually running: a rule widened during an incident, a flag flipped for a test, a resource created outside the pipeline. Drift is normal; undetected drift is the problem, because it accumulates until something uses it. Detection means continuously comparing deployed resources against the configuration baseline and alerting on the difference.
6. Remediate and document
Close the deviation, record what was changed and why, and update the baseline if the new state is the one you actually want. Skipping the last part is how teams end up re-detecting the same accepted exception every month, and how a configuration management program loses the trust of the engineers acting on its alerts.
Configuration management tools
Configuration management tools automate the enforcement of a desired state. They differ in how they get there, and none of them judges whether that state is secure.
Tool | Model | What it does |
|---|---|---|
Ansible | Agentless, YAML playbooks | Applies configurations over SSH without installing agents |
Puppet | Agent-based, declarative | Enforces a declared state across large, complex estates |
Chef | Agent-based, Ruby DSL | Defines configurations in code with wide third-party integration |
SaltStack | Event-driven, Python DSL | Handles large-scale deployments with fast remote execution |
CFEngine | Agent-based, declarative | Automates configuration across heterogeneous systems |
Terraform, CloudFormation | Declarative IaC | Provisions and versions cloud infrastructure from code |
Configuration management database (CMDB) | Repository | Stores assets, configurations and their relationships for reference and audit |
The gap is consistent across the category: configuration management tools make a state reproducible, not safe. Security testing on the same templates closes it.
What goes wrong without configuration management
Three failure modes account for most of what we see when configuration management is absent or informal. Outages come from uncontrolled changes, as the 45 minutes that ended Knight Capital show. Audit failures come from the absence of records, not from the absence of controls; the work was often done, but nobody can prove it. And breaches come from settings that were never reviewed: the permissive network segment, the load balancer left on a default policy, the RDS instance reachable from the internet. Those three are live entries in our weakness catalog because we keep finding them.
Troubleshooting degrades too: without a known-good state, every incident starts by reconstructing what the system was supposed to be. The cost of skipping configuration management is rarely one dramatic event. It is the compounding of small unrecorded decisions until nobody can say what the environment is.
Conclusions
Configuration management is no longer an operations concern that security inherits late. Settings moved into the repository, and with them the decisions that determine blast radius: who can assume which role, what a security group accepts, whether storage is encrypted. Treating those files as code — reviewed, versioned, scanned before merge — is the whole practice in one sentence.
Two numbers are worth carrying out of this page. Automated tools found 88.4% of the vulnerabilities we reported in 2025 but only 55.8% of the risk, and 87% of critical findings came from pentesters. Tooling tells you a setting drifted. Someone still has to work out what that drift allows. That is the line where configuration management stops being an inventory exercise and starts being security work.
Frequently asked questions
What is the difference between configuration management and security configuration management?
Configuration management keeps systems matching their approved state; security configuration management asks whether that approved state is safe. The first is about consistency and reproducibility, the second about hardening and exposure. NIST SP 800-128 calls the second SecCM and treats it as a layer on top of the first. An estate can pass a configuration audit and still be uniformly insecure.
What is configuration drift, and how do you detect it?
Configuration drift is the gap between the approved baseline and what is actually running. It appears when a rule is widened during an incident, a flag is flipped for a test, or a resource is created outside the pipeline. Detecting it means continuously comparing deployed resources against the recorded baseline and alerting on the difference, rather than relying on anyone to report the change.
Is infrastructure as code enough to keep configurations secure?
No. Infrastructure as code makes a configuration reproducible, not safe. A template with an over-permissive role or an open security group deploys that flaw identically every time, reliably. What it adds to a configuration management program is a place to catch the problem: the template is a file in a repository, reviewable and scannable before anything is provisioned.
How much configuration risk do automated scanners miss?
More than most teams assume. In Fluid Attacks’ benchmark of 36 third-party AppSec tools against an application seeded with 1,201 vulnerabilities across 105 CWE categories, a pentester reached 89.6% recall at 100% precision, covering 86.8% of the total risk exposure. The best automated scanner, our own, reached 22.7% recall and 8.8% of the risk exposure.
Does Fluid Attacks test configurations?
Yes, at three points. SAST reads IaC templates in the repository, cloud security posture management analyzes AWS environments for vulnerable configurations, and pentesters test what those configurations enable in the running application. Findings are reported against our open criteria, including requirement 062 on standard configurations, which maps to CIS Controls, ISO/IEC 27001 and PCI DSS.
Test your configurations before they reach production
Our scanners read your infrastructure templates and our pentesters test what those settings actually allow, so your configuration management program catches a misconfiguration in review instead of in an incident. Scanning is in the Essential plan; pentesting is in Advanced. Start free trial · Contact us.
Get started with Fluid Attacks' ASPM solution right now
