Everything-as-Code: Pushing the boundaries of SAST

### Overview Frans van Buul, product manager for static analysis at Fortify (OpenText), explores whether traditional Static Application Security Testing (SAST) technology can scale to secure the growing "Everything-as-Code" ecosystem. While source code historically meant traditional web or server applications, modern development uses code for infrastructure, CI/CD pipelines, smart contracts, and policies. Although SAST holds strong potential to automate security analysis across these domains, current tools struggle due to architectural assumptions designed decades ago for imperative programming languages.

### Key Topics - **Evolution of Everything-as-Code:** Code now defines environments beyond standard applications, including infrastructure as code (IaC), CI/CD pipelines (e.g., GitHub Actions), and smart contracts. A motivating example in GitHub workflows illustrates bash injection vulnerabilities triggered by untrusted pull request titles injected via inline expression syntax. - **Traditional SAST Architecture and Limitations:** SAST tools parse code into an intermediate representation (IR), generate control flow graphs (CFGs), and solve data flow equations. Common techniques include structural analysis (identifying surface patterns like hardcoded passwords, prone to false positives/negatives) and taint analysis (tracking untrusted inputs across sinks). However, conventional SAST heavily biases toward imperative flow rather than declarative definitions. - **Declarative Infrastructure Analysis (Bicep and ARM JSON):** Using Azure's Bicep and ARM JSON templates, van Buul highlights the need to detect both insecure infrastructure (e.g., configurations permitting non-SSL MySQL connections deduced from parameter choices) and insecure templates (e.g., leaking secure string credentials via string interpolation and output directives). - **Smart Contract Security (Solidity):** Analyzing decentralized Ethereum applications highlights vulnerabilities with catastrophic financial consequences (over $2 billion lost in a single year). Standards like the SWC registry (and Enterprise Ethereum Alliance) categorize these flaws. Two key vulnerabilities examined are authorization flaws via `tx.origin` instead of `msg.sender`, and reentrancy attacks caused by external calls preceding state updates.

### Technical Details - **Declarative vs. Imperative Flow:** In declarative environments like Bicep, statement execution order does not define variable initialization. Traditional CFG-based analysis fails without adapting to declarative semantics. - **Encapsulated Languages:** ARM JSON represents an embedded domain-specific language within generic JSON, marked by syntactical cues like square brackets and type fields. SAST engines need multi-level parsing capabilities rather than treating JSON as static data. - **Constant Propagation:** Essential for IaC to evaluate configuration properties, parameter sets, and flags. - **Specialized Taint and Flow Rules:** In Solidity's `tx.origin` flaw, the vulnerable taint passes through a boolean comparison (`tx.origin == owner`). In classic taint analysis, booleans drop taint flags (as in SQL injection mitigations), meaning taint rules must adapt per vulnerability type. For reentrancy, tracking state security and external interaction order requires control flow state modeling rather than simple value-taint tracking.

### Takeaways While niche, language-specific scanners exist, mainstream enterprise SAST tools are not yet fully equipped to comprehensively secure Everything-as-Code. Organizations adopting SAST for IaC or smart contracts should thoroughly evaluate scanner coverage rather than assuming standard security guarantees. Expanding SAST to these domains requires redesigning intermediate representations, adding encapsulated parsing, supporting declarative logic, and engineering flexible, context-specific taint and state analysis models.