My custom plugin for detecting a specific security anti-pattern, open-sourced.

After years of wading through the morass of over-engineered "security-first" microservices that somehow still manage to leak credentials like a sieve, I've decided to weaponize my cynicism into something constructive. The specific anti-pattern that grinds my gears? **Hardcoded configuration paths in containerized applications.** You know the one: a Dockerized app that expects a config file at `/etc/myapp/config.json`, baked into the image, and then the ops team is forced to mount volumes or worse, rebuild the entire image just to change a single endpoint URL. It's a classic case of pretending to be cloud-native while clinging to on-premise habits, and it makes secrets rotation a nightmare.

SonarQube's out-of-the-box security rules are decent for catching the low-hanging fruit like plaintext passwords, but they completely miss this architectural smell. So I built a custom plugin to flag it. The plugin scans for common offenders in various languages, targeting strings that look like absolute filesystem paths pointing to common configuration directories, used in file-reading operations.

Here's the core of the Java rule definition. The logic is simple: look for `new File(...)`, `Paths.get(...)`, or `FileInputStream` where the argument is a string literal starting with `/etc`, `/app/config`, `/usr/local/etc`, or similar.

```java
public class HardcodedConfigPathCheck extends IssuableSubscriptionVisitor {

private static final Pattern CONFIG_PATH_PATTERN = Pattern.compile("^(/etc/|/app/|/usr/local/etc/|/config/).*\.(json|yml|yaml|properties|conf|cfg)$");

@Override
public List nodesToVisit() {
return ImmutableList.of(Tree.Kind.STRING_LITERAL);
}

@Override
public void visitNode(Tree tree) {
StringLiteralTree stringLiteral = (StringLiteralTree) tree;
String value = stringLiteral.value();
if (CONFIG_PATH_PATTERN.matcher(value).matches()) {
// Check if parent is a file operation we care about
Tree parent = getParentOfType(tree, Tree.Kind.NEW_CLASS, Tree.Kind.METHOD_INVOCATION);
if (isFileOperation(parent)) {
reportIssue(stringLiteral, "Hardcoded absolute config file path detected. Use environment variables or a config management library.");
}
}
}
}
```

The plugin currently supports Java, Python (`open()` calls), and Go (`os.Open`/`ioutil.ReadFile`). It's deliberately noisy because in my experience, teams need the jolt. You can whitelist specific, legitimate paths via the rule parameters.

I'm open-sourcing this because:
* The hype cycle insists on microservices and containers but forgets to teach the actual operational constraints.
* This pattern directly violates twelve-factor app methodology (specifically Config), yet is rampant.
* I'm tired of seeing "lift-and-shift" masquerading as cloud migration, and this is a tiny step towards calling it out.

You can find the repo here: [link placeholder - pretend it's a real link]. It's a Maven project, built against the latest SonarQube API. Pull requests for additional languages or more sophisticated detection are welcome, though I'd caution against over-engineering the rule itself—it's a linter, not a proof verifier.

If you find this useful, or better yet, if it causes a few heated debates in your next architecture review, my work here is done.