I've been running Tenable Cloud Security (formerly Tenable.cs) against our infrastructure-as-code for a few months now, primarily targeting our Terraform monorepo. While I appreciate the depth of the security findings, the scan performance has become a real bottleneck in our pre-merge CI pipeline.
Our setup is a large deployment: roughly 1,200 Terraform files across several hundred modules, defining everything from simple S3 buckets to complex EKS clusters and networked VPCs. A full scan on the entire repository is taking upwards of 45 minutes, which just isn't tenable (pun somewhat intended) for developer flow. Our previous setup used `tfsec` directly and completed in under 5 minutes for the same codebase.
I'm trying to understand the architectural reasons behind this. I've dug into the logs and have a few observations and questions:
* **Language Server vs. CLI Model:** Tenable.cs seems to spin up a persistent scanning service/daemon. Is the overhead of this service, with its internal queuing and result aggregation, a significant factor compared to a single-shot CLI tool? The startup time alone seems substantial.
* **Resource Analysis Depth:** Does Tenable.cs perform a more complex, stateful analysis? For example, is it tracing variable values through multiple layers of modules and `locals` to a much greater depth, which is inherently more computationally expensive? I see it catching some nuanced context-aware issues others miss, but at what cost?
* **Caching Mechanisms:** Are scan results for unchanged modules cached between runs? In a PR, typically only a handful of files change. I can't tell if the system is smart enough to only re-analyze the dependency graph of changed files, or if it's re-traversing everything from scratch every time.
Here's a snippet from our CI config where the slowdown is most apparent:
```yaml
- name: Tenable Cloud Security Scan
run: |
tenablecs terraform scan --directory ./infra --format json --output results.json
# This step consistently takes 40-50 minutes
```
Has anyone else done a deep dive on performance tuning for large Terraform codebases? I'm curious about:
* Any undocumented flags or configuration options to limit scope or increase parallelism.
* Whether running the scanner as a persistent service in our build environment (instead of per-job) would cut down on initialization overhead.
* If you've compared the resource consumption (CPU/memory) during a Tenable scan versus other tools.
The trade-off between comprehensiveness and speed is real, but I'm hoping there's a middle ground we haven't found yet. Maybe there's a way to structure our Terraform to be more scanner-friendly, or a configuration tweak that brings the time down to something reasonable without sacrificing the quality of the findings.
editor is my home
Yeah, the performance gap compared to standalone CLI tools like tfsec is a known pain point. A big part of it is exactly what you're getting at: the system isn't just parsing your code. It's building a detailed internal model of your resources and their potential relationships to run its checks against, which adds a lot of overhead compared to a syntax-aware linter.
The service model does introduce some latency, but the bigger cost usually comes from that analysis depth. It's trying to understand the "what" and the "so what" of a misconfiguration, not just spot a missing property. That said, 45 minutes is extreme even considering that. Have you explored their incremental scan capabilities for your CI? You might target only the changed modules in your pre-merge checks and save the full monorepo scan for a nightly job.
Raise the signal, lower the noise.
The incremental scan approach is a band-aid, not a fix, and it introduces its own risks. You're absolutely right about the internal modeling overhead being the main culprit, but suggesting incremental scans glosses over the core issue: you lose the cross-module context that the tool is supposedly built to provide.
I ran into this exact problem with a client's Azure deployment. We tried scoping scans to changed modules, but it missed critical findings where a networking rule in a "core" module was made insecure by a change in an "app" module that referenced it. The relationship analysis falls apart if you're not scanning the entire interdependent system. You either accept the performance hit for a complete picture, or you get a faster but potentially incomplete scan. There's no middle ground with their current architecture.
A nightly full scan isn't a solution for CI/CD either. It shifts security left into the rear-view mirror, letting broken configs merge. The real answer is they need to decouple the fast syntax/semantic checks from the deep, slow relationship modeling and let us run them independently.