Huawei Cloud Terraform (huaweicloud_*) provider security coverage

[lmdestefano-commits]

Hi KICS team,

We are Personal/Telecom Argentina, an enterprise Huawei Cloud customer and partner, currently adopting Huawei Cloud at scale using Terraform and GitLab CI/CD.

While implementing shift-left IaC security controls, we identified what appears to be a provider-specific coverage gap for Terraform huaweicloud_* resources.

Before raising the question, we performed a controlled A/B test using KICS v2.1.20 through the GitLab KICS analyzer.

In the same repository, branch, directory and pipeline, we created two direct Terraform resources representing the same intentional misconfiguration:

AWS aws_security_group: ingress TCP/22 from 0.0.0.0/0
Huawei Cloud huaweicloud_networking_secgroup_rule: ingress TCP/22 from 0.0.0.0/0

No modules or variables were involved in either fixture.

Result:

AWS produced 5 findings, including:

Sensitive Port Is Exposed To Entire Network
Unrestricted Security Group Ingress
Security Group With Unrestricted Access To SSH

The equivalent Huawei Cloud resource produced 0 findings.

We also have an open Huawei Enterprise Support case (TS202609186A0RCHERA00S). Huawei has confirmed that it currently does not publish official rule packs for huaweicloud_* for KICS, Checkov or Trivy.

We would like to understand the KICS side:

Does KICS currently provide any provider-specific security coverage for Terraform huaweicloud_* resources?
If not, is Huawei Cloud provider coverage planned or under consideration?
Would the project accept upstream community contributions adding a Huawei Cloud query family?
What would be the recommended process for introducing support for a new Terraform provider/query family?
Is there an existing generic query mechanism or coverage that we may be overlooking for huaweicloud_*?

We can provide the minimal Terraform fixtures and resulting KICS reports if useful.

Thanks.

[sueun-dev]

The v2.1.20 SSH rule selects AWS resources. A standalone v2.1.20 CLI scan of synthetic TCP/22 ingress from 0.0.0.0/0 parsed both fixtures without query errors: six findings for aws_security_group, zero for huaweicloud_networking_secgroup_rule. That release's assets contained no huawei references. This supports the coverage gap for this SSH case.

For contributions, open an issue for review and an accepted label before a PR. The query guide specifies Rego, metadata and positive/negative fixtures with expected results. Provider plans and acceptance need a maintainer's answer.

[jmrplens]

Adding to what sueun-dev confirmed, two things that may help: how the last two provider families got in, and a way to cover Huawei now without waiting for one.

Precedent. The two newest Terraform families came from outside Checkmarx. NIFCLOUD's first query merged in #6314 together with the provider wiring, after the maintainers asked for the original all-in-one PR to be split, and most of the rest came in one PR (#6897). TencentCloud started with #6904, from a contributor at Tencent, followed by six more PRs grouped by service, and a maintainer did part of the provider wiring (#6909). Both started as experimental. For NIFCLOUD the maintainers asked for a PR with the provider support first, then the query PRs, plus a meta issue tracking them, and there is a "Query" issue template for the proposal. Besides the queries, a new provider touches AvailableCloudProviders in internal/constants/constants.go, the expected list in pkg/engine/source/filesystem_test.go, the queriesPaths in test/main_test.go, the cloudProvider values in .github/scripts/queries-validator/metadata-schema.json, and the provider lists in the docs.

Covering it now. KICS loads extra queries from any folder passed with -q. -q replaces the default path, so pass both. The GitLab analyzer runs KICS with its own fixed query path, so this means a separate job with the checkmarx/kics image rather than the analyzer.

I checked it with checkmarx/kics:v2.1.20 and your two resources. With the stock queries, the Huawei rule got no findings. With this query added, it got a HIGH finding on its remote_ip_prefix line:

package Cx

import data.generic.common as common_lib
import data.generic.terraform as tf_lib

CxPolicy[result] {
	doc := input.document[i]
	rule := doc.resource.huaweicloud_networking_secgroup_rule[name]

	lower(rule.direction) == "ingress"
	rule.remote_ip_prefix == "0.0.0.0/0"
	rule.port_range_min <= 22
	rule.port_range_max >= 22

	result := {
		"documentId": doc.id,
		"resourceType": "huaweicloud_networking_secgroup_rule",
		"resourceName": tf_lib.get_resource_name(rule, name),
		"searchKey": sprintf("huaweicloud_networking_secgroup_rule[%s].remote_ip_prefix", [name]),
		"issueType": "IncorrectValue",
		"keyExpectedValue": "remote_ip_prefix should not be 0.0.0.0/0 for a rule that covers port 22",
		"keyActualValue": "remote_ip_prefix is 0.0.0.0/0 and the rule covers port 22",
		"searchLine": common_lib.build_search_line(["resource", "huaweicloud_networking_secgroup_rule", name, "remote_ip_prefix"], []),
	}
}

kics scan -p <your code> -q /app/bin/assets/queries -q /path/to/custom-queries

Next to it goes a metadata.json with id (a fresh UUID), queryName, severity, category, platform: "Terraform", descriptionText, descriptionUrl, descriptionID, cwe, riskScore and cloudProvider. Use "cloudProvider": "common" for now: a query without it is dropped whenever a scan uses --cloud-provider, and huaweicloud is not an accepted value until the provider exists.

It is a minimal sketch that only matches the explicit form of your fixture. A real query also has to cover a missing remote_ip_prefix (which the provider treats as all addresses), ::/0, the ports argument instead of port_range_min/port_range_max, rules with no protocol or ports, ports given as strings, and action = "deny".

[lmdestefano-commits]

Thanks @sueun-dev and @jmrplens for reproducing the test and for the detailed guidance. This is very helpful and confirms what we observed in our GitLab/KICS pipeline.

The custom query example is also particularly useful, as it demonstrates that the Huawei resource can be covered technically.

From an upstream perspective, would you recommend that we now open a formal issue proposing Huawei Cloud (huaweicloud_*) as a new Terraform provider family for KICS, or should we wait for a maintainer to confirm interest/acceptance here first?

In parallel, as a Huawei Cloud enterprise customer and partner, we have formally asked Huawei to involve their Terraform Provider / Cloud Security teams and evaluate taking an active role in this upstream effort. Our preference would be to have Huawei participate in defining and maintaining provider-specific security coverage, rather than having individual customers independently build and maintain a complete rule set.

We are also working with GitLab Support on the integration side and will share any relevant feedback from both vendors that could help this evaluation.

[jmrplens]

I'd open the issue now rather than wait here. KICS's contributing guide says issues are where new features are requested and where changes are discussed before a PR, and that PRs are only accepted when they're linked to an issue that has been reviewed and labeled as accepted, so a maintainer's decision has to happen on an issue anyway.

The Feature request template fits; its titles follow feat(<scope>): ..., for example feat(terraform): support the huaweicloud provider. Link this discussion and include what you already have: the resource types you need covered, the custom query that shows it works, and Huawei's possible involvement. If it's accepted, the individual queries then go through the Query template.

[lmdestefano-commits]

Thanks, @jmprlens, for the clear guidance!

We'll go ahead and open a formal Feature Request using the suggested template, referencing this discussion and including our AWS/Huawei comparative test, the affected Huawei Cloud resources, and the potential involvement of Huawei Cloud.

We agree that the upstream evaluation should move forward independently of Huawei's response.

We'll share the issue link here once it's created. Thanks again for your help!

[lmdestefano-commits]

Update – Formal Feature Request opened

Following the technical findings and community feedback shared in this discussion, we have opened a formal Feature Request to introduce Huawei Cloud Terraform provider (huaweicloud_*) support in KICS.

Issue #8140 – feat(terraform): support the huaweicloud provider
#8140

The request includes our AWS/Huawei comparative tests, independent community validation, and additional evidence from an enterprise CI/CD deployment where Huawei Cloud SecMaster identified an insecure Security Group configuration that KICS did not detect before deployment.

In parallel, we are engaging Huawei Cloud Enterprise Support to explore potential collaboration on defining and maintaining provider-specific security rules.

Further technical discussion and progress on the proposed implementation can now be tracked through Issue #8140.