Multiple findings based on single query for one terraform resource

[kazaker]

Greetings!
I've been using KICS to scan terraform code and it works great, but there is something I don't quite understand.
There is this query:

{
"id": "92fe237e-074c-4262-81a4-2077acb928c1",
"queryName": "Sensitive Port Is Exposed To Wide Private Network",
"severity": "MEDIUM",
"category": "Networking and Firewall",
"descriptionText": "A sensitive port, such as port 23 or port 110, is open for a wide private network in either TCP or UDP protocol",
"descriptionUrl": "https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group",
"platform": "Terraform",
"aggregation": 63,
"descriptionID": "127a32be",
"cloudProvider": "aws"
}

I noticed, that when I scan my code this query produces multiple findings for the same piece of code. When I checked positive_expected_result.json for this query, I saw that it is expected to create multiple results. For example, for this piece of code:

resource "aws_security_group" "positive4" {
name = "allow_tls4"
description = "Allow TLS inbound traffic"
vpc_id = aws_vpc.main.id
ingress {
description = "TLS from VPC"
from_port = 20
to_port = 22
protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"]
}
}

this query is expected to produce 3 finding, according to positive_expected_result.json. And for this one:

module "vote_service_sg" {
source = "terraform-aws-modules/security-group/aws"
version = "4.3.0"
name = "user-service"
description = "Security group for user-service with custom ports open within VPC, and PostgreSQL publicly open"
vpc_id = "vpc-12345678"
ingress_with_cidr_blocks = [
{
description = "TLS from VPC"
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["172.16.0.0/12"]
}
]
}

it will produce 126 findings!

It hardly seems useful since 126 messages related to one resource convey the same message as 1. And 126 identical messages pollute report and make it harder to use.

Am I missing something here or it can be considered a bug?

[rafaela-soares]

Hello @kazaker

Thank you so much for using KICS and reaching us!

This query iterates over all the ports that KICS considers sensitive (63 ports). You can find them here. For each one, KICS will verify the ingress of the security group and it will evaluate if the sensitive port is being targeted under TCP or UDP protocol. That's why it returns many results.

The first sample defines the ingress from ports 20 to 22 under TCP protocol, which means that covers ports 20, 21 e 22 (KICS considers all sensitive). That's why the query produces 3 findings.

resource "aws_security_group" "positive4" {
name = "allow_tls4"
description = "Allow TLS inbound traffic"
vpc_id = aws_vpc.main.id
ingress {
description = "TLS from VPC"
------>from_port = 20
------>to_port = 22
------>protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"]
}
}

On the other hand, the second sample defines the ingress from port 0 to port 0 under any protocol (-1 means all). That means that covers all suitable port numbers. In this case, returns 126 findings (63 TCP + 63 UDP).

module "vote_service_sg" {
source = "terraform-aws-modules/security-group/aws"
version = "4.3.0"
name = "user-service"
description = "Security group for user-service with custom ports open within VPC, and PostgreSQL publicly open"
vpc_id = "vpc-12345678"
ingress_with_cidr_blocks = [
{
description = "TLS from VPC"
-----> from_port = 0
-----> to_port = 0
-----> protocol = "-1"
cidr_blocks = ["172.16.0.0/12"]
}
]
}

The JSON report provides more detailed information compared to the CLI result, such as the expected value and the actual value. You can generate the JSON report by using the flag -o <path-where-you-want-to-save>. As an example:

Let me know if it helped and/or if you have further questions 😊

[kazaker]

Hello @rafaela-soares ,
thank you very much for a detailed explanation.
Now I understand why it happens.
In my opinion, it still doesn't look that good, especially when we are trying to use kics-github-action:

• it frequently breaks PR comments function because PR comment is limited to 65k characters and this check takes up a lot of space with the same message
• for the same reason it breaks annotations

However, since this an intended behaviour, I guess nothing we can do here.
Thank again.

[rafaela-soares]

Hello @kazaker,

I totally understand your point. I will bring this question to the team in order to discuss a workaround to avoid so much noise. Maybe we
could list all the sensitive ports that are being targeted in a single result.

Meanwhile, if you do not want to get this query results, you can use the flag --exclude-queries.

If you have any further questions, do not hesitate to ask 😊