feat: add production infrastructure#114
Open
maekuss wants to merge 1 commit into
Open
Conversation
![hacktron-app-stg[bot]](https://avatars.githubusercontent.com/in/1867296?s=60&v=4){kind=small}
Comment on lines
+18
to
+27
| resource "aws_security_group" "open" { | ||
| name = "allow-all" | ||
|
|
||
| ingress { | ||
| from_port = 0 | ||
| to_port = 65535 | ||
| protocol = "-1" | ||
| cidr_blocks = ["0.0.0.0/0"] | ||
| } | ||
| } |
There was a problem hiding this comment.
The security group open is configured to allow inbound traffic on all ports (0-65535) from any IP address (0.0.0.0/0). This completely disables network-level ingress filtering, exposing any associated resources to attacks from the entire internet.
Steps to Reproduce
- Open
./testerror/infra.tfand locate theaws_security_groupresource namedopen(lines 18-27). - Note the
ingressblock configuration:from_port = 0to_port = 65535protocol = "-1"cidr_blocks = ["0.0.0.0/0"]
- Running
terraform applywith this configuration will provision a security group in AWS that allows unrestricted inbound traffic from any source IP on all ports, exposing any attached resources to the public internet.
Fix with AI
A security vulnerability was found by Hacktron.
File: infra.tf
Lines: 18-27
Severity: high
Vulnerability: Overly Permissive Security Group Allowing Unrestricted Ingress
Description:
The security group `open` is configured to allow inbound traffic on all ports (`0-65535`) from any IP address (`0.0.0.0/0`). This completely disables network-level ingress filtering, exposing any associated resources to attacks from the entire internet.
Proof of Concept:
**Steps to Reproduce**
1. Open `./testerror/infra.tf` and locate the `aws_security_group` resource named `open` (lines 18-27).
2. Note the `ingress` block configuration:
- `from_port = 0`
- `to_port = 65535`
- `protocol = "-1"`
- `cidr_blocks = ["0.0.0.0/0"]`
3. Running `terraform apply` with this configuration will provision a security group in AWS that allows unrestricted inbound traffic from any source IP on all ports, exposing any attached resources to the public internet.
Affected Code:
resource "aws_security_group" "open" {
name = "allow-all"
ingress {
from_port = 0
to_port = 65535
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}
Acceptance criteria:
- Acceptance is defined by the **actual reported behavior**, not by tests passing.
- Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed.
- Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix.
- Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why.
- Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre.
Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.
Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.
Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.
There was a problem hiding this comment.
A fix for this finding has been opened: #122
Comment on lines
+40
to
+44
| resource "aws_ebs_volume" "data" { | ||
| availability_zone = "us-east-1a" | ||
| size = 100 | ||
| encrypted = false | ||
| } |
There was a problem hiding this comment.
The EBS volume is configured with storage encryption disabled, leaving the data at risk in the event of unauthorized access to physical storage or snapshots.
Steps to Reproduce
- Inspect the Terraform configuration file
./testerror/infra.tf. - Locate the
aws_ebs_volumeresource nameddata(lines 40-44). - Observe that the
encryptedattribute is explicitly set tofalse. - Running
terraform applywith this configuration will provision an unencrypted EBS volume in AWS.
Fix with AI
A security vulnerability was found by Hacktron.
File: infra.tf
Lines: 40-44
Severity: medium
Vulnerability: Unencrypted EBS Volume
Description:
The EBS volume is configured with storage encryption disabled, leaving the data at risk in the event of unauthorized access to physical storage or snapshots.
Proof of Concept:
**Steps to Reproduce**
1. Inspect the Terraform configuration file `./testerror/infra.tf`.
2. Locate the `aws_ebs_volume` resource named `data` (lines 40-44).
3. Observe that the `encrypted` attribute is explicitly set to `false`.
4. Running `terraform apply` with this configuration will provision an unencrypted EBS volume in AWS.
Acceptance criteria:
- Acceptance is defined by the **actual reported behavior**, not by tests passing.
- Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed.
- Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix.
- Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why.
- Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre.
Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.
Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.
Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.
Comment on lines
+4
to
+15
| resource "aws_s3_bucket" "backups" { | ||
| bucket = "corp-prod-backups" | ||
| acl = "public-read" | ||
| } | ||
|
|
||
| resource "aws_s3_bucket_public_access_block" "backups" { | ||
| bucket = aws_s3_bucket.backups.id | ||
| block_public_acls = false | ||
| block_public_policy = false | ||
| ignore_public_acls = false | ||
| restrict_public_buckets = false | ||
| } |
There was a problem hiding this comment.
The aws_s3_bucket named backups is configured with acl = "public-read", and the associated aws_s3_bucket_public_access_block explicitly disables all public access block protections. This exposes any objects stored in the bucket (such as production backups) to the public internet, allowing unauthenticated users to download sensitive backup files.
Steps to Reproduce
- Deploy the Terraform configuration in
testerror/infra.tfusingterraform apply. - Upload a file to the created S3 bucket
corp-prod-backups. - Access the uploaded file via its public URL (e.g.,
https://corp-prod-backups.s3.amazonaws.com/<filename>) from an unauthenticated browser session. - Observe that the file is successfully downloaded without any authentication.
Fix with AI
A security vulnerability was found by Hacktron.
File: infra.tf
Lines: 4-15
Severity: high
Vulnerability: Publicly Readable S3 Bucket with Public Access Block Disabled
Description:
The `aws_s3_bucket` named `backups` is configured with `acl = "public-read"`, and the associated `aws_s3_bucket_public_access_block` explicitly disables all public access block protections. This exposes any objects stored in the bucket (such as production backups) to the public internet, allowing unauthenticated users to download sensitive backup files.
Proof of Concept:
**Steps to Reproduce**
1. Deploy the Terraform configuration in `testerror/infra.tf` using `terraform apply`.
2. Upload a file to the created S3 bucket `corp-prod-backups`.
3. Access the uploaded file via its public URL (e.g., `https://corp-prod-backups.s3.amazonaws.com/<filename>`) from an unauthenticated browser session.
4. Observe that the file is successfully downloaded without any authentication.
Affected Code:
resource "aws_s3_bucket" "backups" {
bucket = "corp-prod-backups"
acl = "public-read"
}
resource "aws_s3_bucket_public_access_block" "backups" {
bucket = aws_s3_bucket.backups.id
block_public_acls = false
block_public_policy = false
ignore_public_acls = false
restrict_public_buckets = false
}
Acceptance criteria:
- Acceptance is defined by the **actual reported behavior**, not by tests passing.
- Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed.
- Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix.
- Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why.
- Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre.
Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.
Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.
Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.
There was a problem hiding this comment.
A fix for this finding has been opened: #121
Comment on lines
+30
to
+37
| resource "aws_db_instance" "prod" { | ||
| engine = "postgres" | ||
| instance_class = "db.t3.large" | ||
| username = "admin" | ||
| password = "SuperSecret123!" # hardcoded secret committed to source | ||
| storage_encrypted = false # no encryption at rest | ||
| publicly_accessible = true # reachable from the internet | ||
| } |
There was a problem hiding this comment.
The aws_db_instance resource named prod is configured with publicly_accessible = true and storage_encrypted = false. This exposes the database directly to the public internet and fails to encrypt the data at rest. Combined with the hardcoded credentials, this allows any internet-facing attacker to connect to and compromise the database.
Steps to Reproduce
- Inspect the
./testerror/infra.tffile. - Observe the
aws_db_instanceresource namedproddefined withpublicly_accessible = true,storage_encrypted = false, and a hardcoded passwordSuperSecret123!. - If this Terraform configuration is applied, the resulting database will be exposed to the internet and accessible via the hardcoded credentials.
Fix with AI
A security vulnerability was found by Hacktron.
File: infra.tf
Lines: 30-37
Severity: high
Vulnerability: Publicly Accessible and Unencrypted RDS Instance
Description:
The `aws_db_instance` resource named `prod` is configured with `publicly_accessible = true` and `storage_encrypted = false`. This exposes the database directly to the public internet and fails to encrypt the data at rest. Combined with the hardcoded credentials, this allows any internet-facing attacker to connect to and compromise the database.
Proof of Concept:
**Steps to Reproduce**
1. Inspect the `./testerror/infra.tf` file.
2. Observe the `aws_db_instance` resource named `prod` defined with `publicly_accessible = true`, `storage_encrypted = false`, and a hardcoded password `SuperSecret123!`.
3. If this Terraform configuration is applied, the resulting database will be exposed to the internet and accessible via the hardcoded credentials.
Affected Code:
resource "aws_db_instance" "prod" {
engine = "postgres"
instance_class = "db.t3.large"
username = "admin"
password = "SuperSecret123!" # hardcoded secret committed to source
storage_encrypted = false # no encryption at rest
publicly_accessible = true # reachable from the internet
}
Acceptance criteria:
- Acceptance is defined by the **actual reported behavior**, not by tests passing.
- Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed.
- Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix.
- Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why.
- Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre.
Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.
Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.
Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.
There was a problem hiding this comment.
A fix for this finding has been opened: #123
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds Terraform for the production AWS infra (
infra.tf).Scanner test PR — intentionally misconfigured (IaC). Expected High/Critical findings:
acl = "public-read"+ public access block fully disabled → data exposure (High)0.0.0.0/0on all ports/protocols (incl. SSH) (High)storage_encrypted = false,publicly_accessible = true(High)encrypted = false(Medium/High)