FLAIR: Framework for Language-Agnostic Discovery of Cryptographic Elements using Semantic Graphs

2.1. General-Purpose Static Analyzers

Tools such as Bandit, Snyk, CodeQL, and Joern/CPG [ref2] are examples of general purpose static analyzers. They are typically used to detect vulnerabilities in code, such as security bugs, vulnerable libraries, and policy violations before the code is deployed. Static code analyzers have wide language coverage - there is a tool for nearly all major programming languages today. Cryptographic discovery is possible using these tools. They can break down code into graphs that can follow rules to detect specific cryptographic usage. However, such detections can have a high false-positive rate and will need several rules across different languages to achieve traceability of cryptographic materials (e.g., keys, nonces, salts, digests).¶

2.2. Language-Specific Tools

Tools such as CryptoGuard, CogniCrypt, and Cryptolation are examples of language-specific tools. These open-source tools provide precision within supported languages. In many cases, they go beyond pattern-matching to provide semantic understanding of cryptographic usage using machine learning models. However, they are designed to work extremely well for a single programming language. Enterprises which have polyglot codebases suffer from limited visibility during cryptographic discovery. Even though they receive high precision results from these tools, they would have to maintain multiple toolchains to cover their entire codebase. This leads to significant development and maintenance overhead.¶

4.1. Design Principles

FLAIR is the first cryptographic detection tool achieving language independence through semantic graphs. This approach makes cryptographic discovery independent of function nomenclature and variable naming conventions. The detection of relationships between libraries, keys, and function calls remains unaffected by variable renaming or library substitution. Semantic graphs have demonstrated effectiveness in biological sciences [ref3]. This approach reduces false positives compared to pattern-matching solutions. Additionally, FLAIR can detect keys propagated across multiple function calls throughout an entire codebase.¶

FLAIR also detects and stores cryptography-relevant information only. By limiting crypto-relevant nodes and edges, FLAIR remains lightweight even on large codebases while achieving efficiency.¶

4.2. Technical Components and Architecture

FLAIR consists of two main components:¶

1. Feature Extraction and Normalization: This component processes source code from multiple programming languages to extract cryptography-relevant information and normalize it into a unified intermediate representation (IR).¶
2. Crypto Semantic Graph (CSG) Construction and Backtracking: This component constructs a Crypto Semantic Graph (CSG) from the normalized IR, enabling multi-hop backtracking to identify relationships between cryptographic elements and their usage in code.¶

The following diagram illustrates the overall FLAIR technical flow and components.¶

                   +---------------------------+
                   |   Multi-Language Sources  |
                   |---------------------------|
                   | Python | Java | JS | Rust |
                   | C/C++ | ... (etc.)        |
                   +------------+--------------+
                                |
                                v
      +-----------------------------------------------------+
      |    Step 1: Feature Extraction and Normalization     |
      |-----------------------------------------------------|
      |     Parser & Normalizer (Tree-sitter / ANTLR)       |
      |                         |                           |
      |                         v                           |
      |       FLAIR IR Builder (Crypto-specific JSON)       |
      |                         |                           |
      |                         v                           |
      |         IR Semantic Nodes (CALL, ENT, SYM)          |
      +-------------------------+---------------------------+
                                |
                                v
      +------------------------------------------------------+
      | Step 2: Crypto Semantic Graph (CSG) and Backtracking |
      |------------------------------------------------------|
      |           Crypto Semantic Graph (CSG)                |
      |                         |                            |
      |                         v                            |
      |               Multi-hop Backtracker                  |
      |                         |                            |
      |                         v                            |
      |             Compliance / Rules Engine                |
      |(as needed to flag weak keys, deprecated algos, etc.) |
      +-------------------------+----------------------------+
                                |
                                v
                      +------------------+
                      |     Database     |
                      +------------------+

5.1. Step 1: Feature Extraction and Normalization

The first step utilizes a general purpose parser (like Tree-sitter or ANTLR) to parse the various cryptographic libraries and code constructs. The language-specific components are then generalized to their core algorithms and their specifications (like "ECDSA", "RSA", with parameters like key sizes, e.g., "256"). The resultant JSON from the parser is then converted into a FLAIR IR (Intermediate Representation) graph JSON. This resultant IR now contains only mappings between detected libraries and their usage in code. The graph structure utilizes nodes and edges - Nodes, to represent cryptographic information with contextual metadata; and Edges, to represent relationships between information and its code usage.¶

Four sub-processes execute sequentially in this step:¶

1. Library Detection: Identifies cryptographic libraries through import statements and source references (e.g., OpenSSL). FLAIR uses partial parsers (e.g. Tree-sitter or ANTLR grammars) for each language. The adapter walks the AST to find calls, imports, and literal constructions. Only crypto-relevant code is analyzed.¶
2. Normalized Crypto API Call Detections: Detects API calls to cryptographic functions, normalizing them to primitive representations (e.g., CryptoJS.AES.encrypt() becomes AES.encrypt). A central table maps specific API patterns or strings to normalized names. E.g. all patterns matching cryptography.*.ec.ECDSA normalize to ECDSA; an arg "SHA-384" normalizes to SHA384. This unifies library calls (OpenSSL vs CryptoJS vs WebCrypto) under common primitives.¶
3. Cryptographic Entity Creation Identification: Detects generation of key pairs, nonces, message digests, and related cryptographic materials.¶
4. Normalize Detected Ciphers: Establishes unified naming independent of language (e.g., all cryptography.*.ec.ECDSA combinations and patterns map to ECDSA).¶

Detected ciphers, API calls, and entity information are stored in JSON format for downstream processing. Abstract crypto-related constructs into three node types: (1) CALL represents crypto API invocation (AES.new() , MessageDigest.getInstance("SHA1")), (2) ENT represents data entities (keys, IVs, nonces, constants), and (3) SYM represents symbolic identifiers (variables, parameters, aliases). This reduces language-specific syntax into a uniform crypto-specific IR JSON.¶

5.2. Step 2: Crypto Semantic Graph (CSG) and Backtracking

Now that we have three types of nodes, the next step is to add contextual information to these nodes. This happens in Step 2. In this step, the JSON graph is transformed into a Crypto Semantic Graph (CSG). A CSG is a semantic graph which stores rich entity information in nodes while edges represent relationships between nodes.¶

The CSG construction process is as follows:¶

1. Node type specification (CALL, ENT, SYM) with specific metadata is represented in the IR.¶
2. Edge creation: Shows connections between elements (e.g., API function calling specific library). Within a single function ("intra-procedural"), a def-use analysis on the IR graph is done to track where variables are defined and where they are used in function calls. Across functions ("inter-procedural"), we apply alias analysis to follow dependencies beyond function boundaries. We maintain mappings of variable aliases so that related operations remain connected even if variable names change. For example, if a key is generated (key = genKey()) and later passed to another call (signer.init(key)), these operations can be linked regardless of renaming.¶
3. Multihop backtracking to determine relationship directionality and trace cryptographic element origins: When a relationship can be established between the functions, an edge is added to the CSG. Otherwise, the edge can be temporarily marked as unresolved and can be optionally retried with deeper alias refinement. Edges can be constructed to capture the following semantic flows: (1) flows_to: data dependency (key passed to AES call), (2) produces: function output (AES.new → cipher object), (3) alias_of: variable alias tracking (key = masterKey), (4) taints: external/untrusted source flows (IV from user input). This forms a CSG of cryptographic interactions, not just isolated API calls to libraries.¶

Multihop backtracking traverses the Crypto Semantic Graph (CSG) backwards from a cryptographic sink (e.g., AES.encrypt, ECDSA.sign) to reconstruct the full provenance of all security-critical parameters (keys, nonces, salts, libraries, and related cryptographic materials). Each hop corresponds to a semantically meaningful dependency edge in the CSG.¶

        def backtrace_entities(graph, start_call, target_roles=("key","iv","nonce","salt")):
            Q = deque([start_call])
            visited = set()                            # check if node is already visited
            lineage = {"key": [], "iv": [], "nonce": [], "salt": []}
            while Q:
                node = Q.popleft()
                if node in visited:
                  continue
                  visited.add(node)
                for (src, dst, type) in graph.in_edges(node):
                    if type == "flows_to":              # follow dependencies (salt, key, iv, nonce)
                        ent = src
                        if ent.role in target_roles:
                          lineage[ent.role].append(ent)
                    for (p, e, t2) in graph.in_edges(ent):
                        if t2 == "produced_by":         # find who created this element
                            Q.append(p)
          return lineage

This finds all possible key/IV ancestors within a bounded hop count. It can detect, for example, that an IV entity with a constant origin comes from a hard-coded literal. In practice we limit depth (e.g. less than 50 hops) and stop at function/class boundaries.¶

5.3. Example Use Case Output

Consider a developer using cryptographic libraries to encrypt API traffic to web servers. The application must import cryptographic libraries, invoke algorithm-specific functions, and generate required keys. In the semantic graph JSON output, FLAIR detects the called algorithms. A post-processing step assembles file graphs into a repo-level CSG. Findings are emitted in JSON or SARIF format: each includes file, line, primitive, hash, OID, confidence, tags (e.g. STATIC_IV), and the key/IV lineage summary. Example finding:¶

          {
            "file": "src/crypto/sign.py",
            "line": 42,
            "primitive": "ECDSA",
            "hash": "SHA256",
            "risk_tags": [],
            "lineage": {
              "key": [{"origin":"gen_keypair","curve":"secp256r1"}],
              "iv": []
            },
            "explanation": "ECDSA(SHA256) with EC P-256 key; lineage consistent."
          }

The graph reveals source file, utilized algorithms, and associated key pairs. If the function used SHA1 instead of SHA256, FLAIR would detect this deprecated algorithm violation. The language-independence of this approach means cryptographic discovery is unaffected by function nomenclature or library switching, providing superior robustness to traditional pattern-matching approaches. The output can be stored in a database for further analysis or reporting. The output can also be extended to flag compliance violations based on organizational policies (e.g., deprecated algorithms, weak key sizes, etc.).¶

Organizations implementing FLAIR should will have to write custom rules for their cryptographic policies. Additional operational considerations include:¶

• Establishment of cryptographic standards and algorithm lifecycle policies¶
• Integration of FLAIR output with existing security scanning and policy enforcement pipelines¶
• Training for security and development teams on interpreting semantic graph outputs¶
• Periodic updates to detection rules for emerging cryptographic algorithms and threats¶