Code intelligence has escaped the code

A surprising amount of program behavior is defined by what is outside the program. Database URLs, feature flags, and library settings sit in configuration files or environment variables, while the code reading them may make some half-assed assumptions on what comes out on the other end. Strings are an example of a horrible "anything" type and should more often than not be encoded into more specific types, e.g., URL, semantic version class, etc.

If we want code intelligence to explain what an application does, those files become part of the question. For example, we might want to assert that, before deployment, every required configuration lookup must resolve to exactly one (valid) entry in the application’s declared production configuration file.

For example, Bifrost v0.14.4 correlates Java configuration-accessor calls with entries in explicitly named .properties files. The recordings below use the public release:

Suppose our application reads configuration through AppConfig.get(String key):

void connect(AppConfig config, Audit audit) {
    String url = config.get("db.url");
    String pool = config.get("db.pool");

    audit.get("db.url");
}

And we have this document:

# src/main/resources/app.properties
db.url=jdbc:postgresql://db/app
db.user=app

We want to connect the first call to the db.url entry. We also want to explain why the other calls don’t qualify.

Searching for the literal "db.url" finds it in both calls. Searching for methods named get finds those too. Neither tells us which method resolves to the configuration document we mean.

That would be an impressive amount of confidence (and coincidence) for two equal strings.

Instead, let's express their relationship in RQL:

(correlate
  :relation
    (configuration-key
      :documents ["src/main/resources/app.properties"])

  :code
    (call-input :parameter-index 0
      (call-sites-to :proof proven
        (enclosing-decl
          (inside
            (class (name "AppConfig"))
            (method (name "get"))))))

  :configuration
    (configuration-facts
      :format properties
      :node-kind member))

The :code side selects the accessor and asks for arguments bound to its first parameter through proven call resolution. The :configuration side selects property entries. The :relation connects a plain string-literal key to the matching entry inside the declared document.

So config.get("db.url") pairs with db.url=.... The "db.pool" call has no matching entry in this file. audit.get("db.url") resolves to a different method. An identically named property in another file stays outside the relationship unless we explicitly declare that file.

The result retains both locations and their provenance, giving us something we can inspect and navigate.

The important boundary or "narrowing" of the query is in supplying the document path. The query does not statically determine which file the application loads at runtime or which value wins after overrides.

For correctness-sake, duplicate keys result in an "ambiguous" outcome. Unreadable documents and arguments the relation cannot decode produce incomplete diagnostics. If the key comes from a constant or a dynamically constructed value, this first implementation cannot establish the same relationship.

An empty result accompanied by incomplete diagnostics tells us where the analysis stopped. It does not establish that no relationship exists.

For an agent, this makes a useful difference. It can follow an explicit relationship between a configuration read and an authored setting, inspect both sides, and carry the remaining uncertainty into its answer. This is part of Bifrost's "honest incompleteness" principle when determining a query result.

For the example in this blog, the configuration-key relation used here supports Java calls with plain string-literal keys and explicitly named .properties files. However, Bifrost also queries JSON, YAML, TOML and XML, with separate relations for other connections between code and configuration. As previously mentioned, the does not infer runtime file loading, framework binding or environment overrides.

Bifrost also powers SlopCop, where slopcop check (or its MCP equivalent) brings static analysis into a coding agent’s edit-and-check loop. A number of CVEs relating to vulnerable dependencies only trigger when certain configuration settings are enabled.

For example, CVE-2022-22947 in Spring Cloud Gateway required the Gateway Actuator endpoint to be enabled, exposed, and unsecured. Log4j's CVE-2021-45046 involved a non-default Pattern Layout containing a Thread Context Lookup such as $${ctx:loginId}, combined with attacker-controlled context data. Without these pre-conditions in the application configuration, the affected dependency is dormant and not an immediate threat to the code that uses it.

Code intelligence has escaped the code and, for now, it knows exactly which file it was allowed to visit.