Security Misconfiguration Is a Runtime Fact

Debug mode on in production, a missing Content-Security-Policy header, a wildcard CORS policy, an open port — these are properties of the deployed system, not literals sitting in your source for a scan to read. BrassCoders catches the misconfiguration that’s hardcoded in code and names the rest for what it is: a runtime fact, checked by a tool that inspects the running system, not the diff.

The insecure setting you can grep for and the insecure setting that’s actually live are often different things, and only one of them has a form a source scan can match.

What a Source Scan Reads Versus What Runs

BrassCoders reads committed source, so it catches misconfiguration that’s written into the code: app.run(debug=True) hardcoded, a CORS policy set to * in a string, an insecure default baked into a config file. Those have a shape, and a rule matches them on every scan. AI assistants produce them often, reaching for the permissive setting that makes the example run.

The misconfiguration that ships to production frequently has no such shape. The source reads DEBUG = os.environ.get("DEBUG"); whether production runs with debug on is decided by an environment variable at deploy time, which the committed code doesn’t contain. Grep the whole repository and the dangerous value isn’t there — it lives in the deploy.

Why Misconfiguration Escapes the Scan

BrassCoders sees the code, and the value that matters is often set outside it. A missing security header depends on the server or reverse-proxy configuration, not the application source. An overly-permissive cloud role is an IAM setting in your provider console. An exposed admin endpoint is a network rule. Each is a property of the deployed environment, invisible in the source because it was never written there.

OWASP tracks this class as A05, Security Misconfiguration, and its defining trait is exactly this gap between code and configuration. The application can be written correctly and still ship insecure because the environment it runs in was set up wrong. A scan of the source has no window into that environment.

Where the Checks Live

The tools that catch runtime misconfiguration inspect the running or deployed system. DAST hits the live application and reads what it actually returns — the headers it sets, the errors it exposes, the endpoints it answers. Configuration scanning and CSPM read the deployed server and cloud settings directly and flag the open port, the public bucket, the permissive role.

Each of those observes state that exists only after deployment, which is why a static scan can’t stand in for them. The check has to reach the running system to see the setting that’s actually live. A scanner that claimed to verify your production configuration would be reporting on an environment it never touched.

What BrassCoders Catches

BrassCoders owns the source-resident slice of this: a hardcoded debug flag, a wildcard CORS policy written into the code, an insecure default committed to a config file, a bind to 0.0.0.0 in the source. Those are structural, and the scanner flags them deterministically before they ship. An AI assistant that writes debug=True into the example hands you exactly that kind of finding.

The two layers divide cleanly. BrassCoders catches the misconfiguration you committed; DAST and config scanning catch the misconfiguration you deployed. Run the scan so no insecure default ships in the code, and run a config scan against the environment so no insecure setting ships in the deploy.

pip install brasscoders
brasscoders --offline scan /path/to/your/project

The scan catches the insecure default written in source. The setting flipped at deploy time is the runtime layer’s job, and the fix starts with knowing which layer you’re on.