Scan patterns
The DataParade CLI’s structural scan and classification are largely data-driven from YAML shipped under cli/patterns/ in the @dataparade/cli package (same paths in the monorepo: cli/patterns/...). For how to invoke a scan, see Scan arguments and Environment variables.
Current production language support for scanning is TypeScript, JavaScript, Python, and Terraform (.tf / .tfvars), including common AWS, Azure (azurerm), and Kubernetes (kubernetes_*) provider resources.
How patterns are loaded
When you run scan, the CLI builds a unified pattern configuration (loadUnifiedPatternConfig in code) that loads several YAML files together. Detectors use the language and shared pattern files to emit findings (with patternIds, confidence, evidence). Property inference uses shared regex/rule tables. The classifier then maps those findings to asset / actor / third_party components using separate classifier YAML.
At startup the CLI also cross-checks that classifier pattern_defaults cover every patternId emitted from the pattern YAMLs, and that third-party service names in third-party.patterns.yaml have matching entries in classifier/third-party.classifier.yaml. A mismatch fails fast with a clear error so drift between files cannot ship silently.
A few pattern IDs (for example env_variable and config_file) are wired in TypeScript as well as YAML; the unified loader treats them as emitted patterns so classifier coverage stays consistent.
Detection and property rules (shared / per language)
| File | Role |
|---|---|
cli/patterns/actor.patterns.yaml | Language-agnostic actor cues (regexes + rules) so analyzers can emit actor-related findings with stable patternIds. |
cli/patterns/property.patterns.yaml | Property inference: named regexes and inference_rules that map code/env/config matches onto allowed engineering/privacy/security fields (aligned with detectable keys in code). |
cli/patterns/third-party.patterns.yaml | External APIs / SDKs: HTTP client shapes, URL patterns, and a service catalog (names, hosts) used to detect third-party usage before classification. |
cli/patterns/typescript.patterns.yaml | TypeScript: frameworks (Express, Nest, …), DB clients, auth libraries, config keys, SQL heuristics, and related patternIds + regexes. |
cli/patterns/python.patterns.yaml | Python: DB clients, auth decorators, route frameworks, env/config patterns, and HTTP client patterns analogous to the TS side. |
cli/patterns/terraform.patterns.yaml | Terraform: static parsing of resource, data, module, and provider blocks; cross-resource references; resource-type hints for AWS, Azure, and Kubernetes providers. See also cli/patterns/terraform.md in the repository. |
cli/patterns/*-terraform-service-hints.generated.json | Generated per-provider prefix hints (AWS, Azure, Kubernetes) merged into Terraform classification before each provider’s default catch-all rule. Maintainers regenerate these from CDKTF packages via pnpm run generate:terraform-provider-hints in cli/ (see cli/patterns/terraform.md in the repository). |
Terraform (IaC)
The Terraform analyzer ingests .tf and .tfvars files and emits terraform_resource, terraform_module, and terraform_provider findings. It does not run terraform plan or apply unless you opt in (see Scan arguments).
- AWS —
aws_*resource types (hand-written hints plus generated coverage from@cdktf/provider-aws). - Azure —
azurerm_*and hand-writtenazapi_*rules (generated hints from@cdktf/provider-azurerm). - Kubernetes —
kubernetes_*in-cluster resources such as deployments, services, ingress, secrets, and PVCs (generated hints from@cdktf/provider-kubernetes). Example: self-hosted app stacks that useprovider "kubernetes"(for example Twenty CRM underpackages/twenty-docker/k8s/terraform/).
Reference-based data flows connect resources that depend on each other in HCL (for example a deployment referencing a namespace or PVC).
Classifier mapping (cli/patterns/classifier/)
| File | Role |
|---|---|
cli/patterns/classifier/components.classifier.yaml | Main RawFinding → component defaults: pattern_defaults (type, subType, priority), name normalization, and other lists so classification stays out of hard-coded tables. |
cli/patterns/classifier/actors.classifier.yaml | Actor-specific pattern_defaults (for example web_actor → customer, service_actor → employee) layered with the main classifier config. |
cli/patterns/classifier/third-party.classifier.yaml | Third-party catalog: serviceName, matchKeys, type, subType for known vendors; must stay aligned with services referenced from third-party.patterns.yaml. |
AI enrichment: provider topology (separate load)
| File | Role |
|---|---|
cli/patterns/provider-topology.rules.yaml | Declares managed resources and service nodes per cloud/SDK provider. For Terraform, matching uses terraformResourceTypes / terraformResourceTypePrefixes on each node (for example AWS S3/Lambda, Azure storage, Kubernetes workload/service/ingress). Also used when AI inference runs for SDK-backed providers (Supabase, Stripe, etc.). Loaded separately from the unified structural bundle above. |
Third-party data-flow signal rules (separate load)
| File | Role |
|---|---|
cli/patterns/pii-signals.rules.yaml | Regex and label rules for personally identifiable or sensitive data cues in code (feeds heuristic thirdPartyDataFlow categories when AI inference data-flow output is enabled). |
cli/patterns/non-pii-signals.rules.yaml | Rules for non-PII categories (identifiers, telemetry, usage metadata, etc.) and optional capability tags on insights. |
These files do not replace structural data-flow edges; they enrich metadata summaries and the app’s third-party Data tab after import.
To change how the scanner behaves in a fork or internal build, edit these YAML files under cli/patterns/ (and run CLI tests). Application diagram YAML import is documented elsewhere and is unrelated to these pattern files. For the result file the CLI produces after a scan, see Output and results.