A real report, exactly as delivered.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
GitHub Personal Access Token
**Category:** GitHub
**Match:** GITHUB_TOKEN=[secret redacted]

---

Reported:
**Secret:** REDACTED
**Match:** REDACTED
**Rule Id:** github-pat

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Stripe Secret Key
**Category:** Stripe
**Match:** STRIPE_SECRET_KEY=[secret redacted]

---

Reported:
**Secret:** REDACTED
**Match:** REDACTED
**Rule Id:** stripe-access-token

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Make sure this MySQL database password gets changed and removed from the code.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
GitHub Personal Access Token
**Category:** GitHub
**Match:**   apiToken: "[secret redacted]",

---

Reported:
**Secret:** REDACTED
**Match:** REDACTED
**Rule Id:** github-pat

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
PyYAML: yaml.load() API could execute arbitrary code
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 5.1

In PyYAML before 5.1, the yaml.load() API could execute arbitrary code if used with untrusted data. The load() function has been deprecated in version 5.1 and the 'UnsafeLoader' has been introduced for backward compatibility with the function.

Suggested remediation:
5.1

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
PyYAML: incomplete fix for CVE-2020-1747
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 5.4

A vulnerability was discovered in the PyYAML library in versions before 5.4, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. This flaw allows an attacker to execute arbitrary code on the system by abusing the python/object/new constructor. This flaw is due to an incomplete fix for CVE-2020-1747.

Suggested remediation:
5.4

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
python-sqlalchemy: SQL Injection when the order_by parameter can be controlled
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 1.3.0b3

SQLAlchemy through 1.2.17 and 1.3.x through 1.3.0b2 allows SQL Injection via the order_by parameter.

Suggested remediation:
1.3.0b3

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/Dockerfile
**Type:** Dockerfile Security Check

Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.
Specify at least 1 USER command in Dockerfile with non-root user as argument

Suggested remediation:
Add 'USER <non root user name>' line to the Dockerfile

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

S3 buckets should block public ACLs on buckets and any objects they contain. By blocking, PUTs with fail if the object has any public ACL a.

No public access block so not blocking public acls
Number	Content
1	resource "aws_s3_bucket" "backups" {
2	  bucket = "badapp-backups"
3	  acl    = "public-read"
4	}

Suggested remediation:
Enable blocking any PUT calls with a public ACL specified

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

S3 bucket policy should have block public policy to prevent users from putting a policy that enable public access.

No public access block so not blocking public policies
Number	Content
1	resource "aws_s3_bucket" "backups" {
2	  bucket = "badapp-backups"
3	  acl    = "public-read"
4	}

Suggested remediation:
Prevent policies that allow public access being PUT

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

S3 Buckets should be encrypted to protect the data that is stored within them if access is compromised.

Bucket does not have encryption enabled
Number	Content
1	resource "aws_s3_bucket" "backups" {
2	  bucket = "badapp-backups"
3	  acl    = "public-read"
4	}

Suggested remediation:
Configure bucket encryption

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

S3 buckets should ignore public ACLs on buckets and any objects they contain. By ignoring rather than blocking, PUT calls with public ACLs will still be applied but the ACL will be ignored.

No public access block so not blocking public acls
Number	Content
1	resource "aws_s3_bucket" "backups" {
2	  bucket = "badapp-backups"
3	  acl    = "public-read"
4	}

Suggested remediation:
Enable ignoring the application of public ACLs in PUT calls

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

Buckets should not have ACLs that allow public access

Bucket has a public ACL: "public-read"
Number	Content
1	resource "aws_s3_bucket" "backups" {
2	  bucket = "badapp-backups"
3	  acl    = "public-read"
4	}

Suggested remediation:
Don't use canned ACLs or switch to private acl

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

S3 buckets should restrict public policies for the bucket. By enabling, the restrict_public_buckets, only the bucket owner and AWS Services can access if it has a public policy.

No public access block so not restricting public buckets
Number	Content
1	resource "aws_s3_bucket" "backups" {
2	  bucket = "badapp-backups"
3	  acl    = "public-read"
4	}

Suggested remediation:
Limit the access to public buckets to only the owner or AWS Services (eg; CloudFront)

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

Security groups provide stateful filtering of ingress and egress network traffic to AWS
resources. It is recommended that no security group allows unrestricted ingress access to
remote server administration ports, such as SSH to port 22 and RDP to port 3389.

Security group rule allows ingress from public internet.
Number	Content
6	resource "aws_security_group" "web" {
7	  ingress {
8	    from_port   = 0
9	    to_port     = 65535
10	    protocol    = "tcp"
11	    cidr_blocks = ["0.0.0.0/0"]
12	  }
13	}

Suggested remediation:
Set a more restrictive CIDR range

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

Encryption using AWS keys provides protection for your S3 buckets. To increase control of the encryption and manage factors like rotation use customer managed keys.

Bucket does not encrypt data with a customer managed key.
Number	Content
1	resource "aws_s3_bucket" "backups" {
2	  bucket = "badapp-backups"
3	  acl    = "public-read"
4	}

Suggested remediation:
Enable encryption using customer managed keys

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Asymmetric Private Key
**Category:** AsymmetricPrivateKey
**Match:** ----BEGIN RSA PRIVATE KEY-----***********************************************************************************************************************************-----END RSA PRIVATE

---

Reported:
**Secret:** REDACTED
**Match:** REDACTED
**Rule Id:** private-key

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Result message:** child_process.exec()/execSync() run their argument through a shell. Passing a template literal or concatenated string builds a command-injection sink. Use execFile()/spawn() with an argument array instead, and never interpolate untrusted input into a shell string.

**Snippet:**
```  exec("ping -c 1 " + req.query.host, (err, stdout) => res.send(stdout)),```

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Result message:** Use of eval() executes its string argument as code. If any part of the input is attacker-influenced this is a code-injection sink. Replace with a safe parser (e.g. JSON.parse) or an explicit dispatch table.

**Snippet:**
```router.get("/calc", (req, res) => res.send(String(eval(req.query.expr))));```

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Result message:** subprocess called with shell=True runs the command through /bin/sh. Combined with a formatted or concatenated command string this is an OS-command-injection sink. Pass an argument list and shell=False (the default) instead.

**Snippet:**
```    subprocess.call("tar czf backup.tgz " + path, shell=True)```

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
python-jinja2: str.format_map allows sandbox escape
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 2.10.1

In Pallets Jinja before 2.10.1, str.format_map allows a sandbox escape.

Suggested remediation:
2.10.1

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
jinja2: Jinja has a sandbox breakout through indirect reference to format method
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 3.1.5

Jinja is an extensible templating engine. Prior to 3.1.5, An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox. This vulnerability is fixed in 3.1.5.

Suggested remediation:
3.1.5

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
python-requests: Redirect from HTTPS to HTTP does not remove Authorization header
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 2.20.0

The Requests package before 2.20.0 for Python sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.

Suggested remediation:
2.20.0

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
python-sqlalchemy: SQL Injection when the group_by parameter can be controlled
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 1.2.19

SQLAlchemy 1.2.17 has SQL Injection when the group_by parameter can be controlled.

Suggested remediation:
1.2.19

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Review this potentially hard-coded password.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
"apiToken" detected here, make sure this is not a hard-coded secret.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Make sure that executing this OS command is safe here.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
"API_KEY" detected here, make sure this is not a hard-coded secret.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

Versioning in Amazon S3 is a means of keeping multiple variants of an object in the same bucket.

You can use the S3 Versioning feature to preserve, retrieve, and restore every version of every object stored in your buckets.

With versioning you can recover more easily from both unintended user actions and application failures.

Bucket does not have versioning enabled
Number	Content
1	resource "aws_s3_bucket" "backups" {
2	  bucket = "badapp-backups"
3	  acl    = "public-read"
4	}

Suggested remediation:
Enable versioning to protect against accidental/malicious removal or modification

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
python-jinja2: ReDoS vulnerability in the urlize filter
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 2.11.3

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the `_punctuation_re regex` operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Suggested remediation:
2.11.3

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
jinja2: HTML attribute injection when passing user input as keys to xmlattr filter
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 3.1.3

Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Suggested remediation:
3.1.3

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
jinja2: accepts keys containing non-attribute characters
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 3.1.4

Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe. This vulnerability is fixed in 3.1.4.

Suggested remediation:
3.1.4

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
python-requests: Unintended leak of Proxy-Authorization header
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 2.31.0

Requests is a HTTP library. Since Requests 2.3.0, Requests has been leaking Proxy-Authorization headers to destination servers when redirected to an HTTPS endpoint. This is a product of how we use `rebuild_proxies` to reattach the `Proxy-Authorization` header to requests. For HTTP connections sent through the tunnel, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the `Proxy-Authorization` header must be sent in the CONNECT request as the proxy has no visibility into the tunneled request. This results in Requests forwarding proxy credentials to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate sensitive information. This issue has been patched in version 2.31.0.

Suggested remediation:
2.31.0

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
requests: subsequent requests to the same host ignore cert verification
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 2.32.0

Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0.

Suggested remediation:
2.32.0

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
requests: Requests vulnerable to .netrc credentials leak via malicious URLs
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 2.32.4

Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Suggested remediation:
2.32.4

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
requests: Requests: Security bypass due to predictable temporary file creation
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 2.33.0

Requests is a HTTP library. Prior to version 2.33.0, the `requests.utils.extract_zipped_paths()` utility function uses a predictable filename when extracting files from zip archives into the system temporary directory. If the target file already exists, it is reused without validation. A local attacker with write access to the temp directory could pre-create a malicious file that would be loaded in place of the legitimate one. Standard usage of the Requests library is not affected by this vulnerability. Only applications that call `extract_zipped_paths()` directly are impacted. Starting in version 2.33.0, the library extracts files to a non-deterministic location. If developers are unable to upgrade, they can set `TMPDIR` in their environment to a directory with restricted write access.

Suggested remediation:
2.33.0

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
The "node" image runs with "root" as the default user. Make sure it is safe here.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Copying recursively might inadvertently add sensitive data to the container. Make sure it is safe here.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
No Public Access Block configuration prevents public ACL/policies to be set on this S3 bucket. Make sure it is safe here.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Make sure granting access to "AllUsers" group is safe here.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Make sure that this dynamic injection or execution of code is safe.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/Dockerfile
**Type:** Dockerfile Security Check

You should add HEALTHCHECK instruction in your docker container images to perform the health check on running containers.
Add HEALTHCHECK instruction in your Dockerfile

Suggested remediation:
Add HEALTHCHECK instruction in Dockerfile

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

Ensures S3 bucket logging is enabled for S3 buckets
Bucket has logging disabled
Number	Content
1	resource "aws_s3_bucket" "backups" {
2	  bucket = "badapp-backups"
3	  acl    = "public-read"
4	}

Suggested remediation:
Add a logging block to the resource to enable access logging

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

The "block public access" settings in S3 override individual policies that apply to a given bucket, meaning that all public access can be controlled in one central types for that bucket. It is therefore good practice to define these settings for each bucket in order to clearly define the public access that can be allowed for it.

Bucket does not have a corresponding public access block.
Number	Content
1	resource "aws_s3_bucket" "backups" {
2	  bucket = "badapp-backups"
3	  acl    = "public-read"
4	}

Suggested remediation:
Define a aws_s3_bucket_public_access_block for the given bucket to control public access policies

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

Security groups should include a description for auditing purposes.

Simplifies auditing, debugging, and managing security groups.

Security group explicitly uses the default description.
Number	Content
6	resource "aws_security_group" "web" {
7	  ingress {
8	    from_port   = 0
9	    to_port     = 65535
10	    protocol    = "tcp"
11	    cidr_blocks = ["0.0.0.0/0"]
12	  }
13	}

Suggested remediation:
Add descriptions for all security groups

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
**Target:** badapp/infra/main.tf
**Type:** Terraform Security Check

Security group rules should include a description for auditing purposes.

Simplifies auditing, debugging, and managing security groups.

Security group rule does not have a description.
Number	Content
6	resource "aws_security_group" "web" {
7	  ingress {
8	    from_port   = 0
9	    to_port     = 65535
10	    protocol    = "tcp"
11	    cidr_blocks = ["0.0.0.0/0"]
12	  }
13	}

Suggested remediation:
Add descriptions for all security groups rules

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Omitting "--ignore-scripts" can lead to the execution of shell scripts. Make sure it is safe here.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Restrict IP addresses authorized to access administration services.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
Omitting "logging" or acl="log-delivery-write" makes logs incomplete. Make sure it is safe here.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
No bucket policy enforces HTTPS-only access to this bucket. Make sure it is safe here.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
This framework implicitly discloses version information by default. Make sure it is safe here.

Shown exactly as our checks reported it, with two exceptions: credential values are masked, and internal system names are removed.

Reported:
jinja2: Jinja sandbox breakout through attr filter selecting format method
**Target:** badapp/worker/requirements.txt
**Type:** pip
**Fixed version:** 3.1.6

Jinja is an extensible templating engine. Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

Suggested remediation:
3.1.6