Fix frogbot security issues v3

[eranturgeman]

• All tests passed. If this feature is not already covered by the tests, I added new tests.
• This pull request is on the dev branch.
• I used gofmt for formatting the code before submitting the pull request.
• Update documentation about new features / new supported technologies

---

[github-actions]

📗 Scan Summary

• Frogbot scanned for vulnerabilities and found 9 issues

Scan Category	Status	Security Issues
Software Composition Analysis	✅ Done	6 Issues Found 4 High 2 Medium
Contextual Analysis	✅ Done	-
Static Application Security Testing (SAST)	✅ Done	Not Found
Secrets	✅ Done	3 Issues Found 3 High
Infrastructure as Code (IaC)	✅ Done	Not Found

📦 Vulnerable Dependencies

Severity	ID	Contextual Analysis	Dependency Path
High	CVE-2021-4435	Missing Context	-
High	CVE-2020-8131	Not Covered	-
High	CVE-2019-5448	Not Covered	-
High	CVE-2019-10773	Not Covered	-
Medium	CVE-2025-9308	Not Covered	-
Medium	CVE-2019-15608	Not Covered	-

🔖 Details

[ CVE-2021-4435 ] yarn 1.0.0

Vulnerability Details

Contextual Analysis:	Missing Context
CVSS V3:	7.8

An untrusted search path vulnerability was found in Yarn. When a victim runs certain Yarn commands in a directory with attacker-controlled content, malicious commands could be executed in unexpected ways.

[ CVE-2020-8131 ] yarn 1.0.0

Vulnerability Details

Contextual Analysis:	Not Covered
CVSS V3:	7.5

Arbitrary filesystem write vulnerability in Yarn 1.21.1 and earlier allows attackers to write to any path on the filesystem and potentially lead to arbitrary code execution by forcing the user to install a malicious package.

[ CVE-2019-5448 ] yarn 1.0.0

Vulnerability Details

Contextual Analysis:	Not Covered
CVSS V3:	8.1

Yarn before 1.17.3 is vulnerable to Missing Encryption of Sensitive Data due to HTTP URLs in lockfile causing unencrypted authentication data to be sent over the network.

[ CVE-2019-10773 ] yarn 1.0.0

Vulnerability Details

Contextual Analysis:	Not Covered
CVSS V3:	7.8

In Yarn before 1.21.1, the package install functionality can be abused to generate arbitrary symlinks on the host filesystem by using specially crafted "bin" keys. Existing files could be overwritten depending on the current user permission set.

[ CVE-2025-9308 ] yarn 1.0.0

Vulnerability Details

Contextual Analysis:	Not Covered
CVSS V3:	5.5

Es wurde eine Schwachstelle in yarnpkg Yarn bis 1.22.22 entdeckt. Betroffen hiervon ist die Funktion setOptions der Datei src/util/request-manager.js. Mittels dem Manipulieren mit unbekannten Daten kann eine inefficient regular expression complexity-Schwachstelle ausgenutzt werden. Der Angriff muss auf lokaler Ebene erfolgen.

[ CVE-2019-15608 ] yarn 1.0.0

Vulnerability Details

Contextual Analysis:	Not Covered
CVSS V3:	5.9

The package integrity validation in yarn < 1.19.0 contains a TOCTOU vulnerability where the hash is computed before writing a package to cache. It's not computed again when reading from the cache. This may lead to a cache pollution attack. This issue is fixed in 1.19.0.

---

🐸 JFrog Frogbot

[github-actions]

🤫 Secret Vulnerability

Severity	Origin	Finding
High	jfrog	Hardcoded secrets were found

Full description

Vulnerability Details

Abbreviation:	REQ.SECRET.GENERIC.CODE

Storing hardcoded secrets in your source code or binary artifact could lead to several risks.

If the secret is associated with a wide scope of privileges, attackers could extract it from the source code or binary artifact and use it maliciously to attack many targets. For example, if the hardcoded password gives high-privilege access to an AWS account, the attackers may be able to query/modify company-wide sensitive data without per-user authentication.

Best practices

Use safe storage when storing high-privilege secrets such as passwords and tokens, for example -

• Environment Variables

Environment variables are set outside of the application code, and can be dynamically passed to the application only when needed, for example -
SECRET_VAR=MySecret ./my_application
This way, MySecret does not have to be hardcoded into my_application.

Note that if your entire binary artifact is published (ex. a Docker container published to Docker Hub), the value for the environment variable must not be stored in the artifact itself (ex. inside the Dockerfile or one of the container's files) but rather must be passed dynamically, for example in the docker run call as an argument.

• Secret management services

External vendors offer cloud-based secret management services, that provide proper access control to each secret. The given access to each secret can be dynamically modified or even revoked. Some examples include -

• Hashicorp Vault
• AWS KMS (Key Management Service)
• Google Cloud KMS

Least-privilege principle

Storing a secret in a hardcoded manner can be made safer, by making sure the secret grants the least amount of privilege as needed by the application.
For example - if the application needs to read a specific table from a specific database, and the secret grants access to perform this operation only (meaning - no access to other tables, no write access at all) then the damage from any secret leaks is mitigated.
That being said, it is still not recommended to store secrets in a hardcoded manner, since this type of storage does not offer any way to revoke or moderate the usage of the secret.

---

🐸 JFrog Frogbot

[github-actions]

🤫 Secret Vulnerability

Severity	Origin	Finding
High	jfrog	Hardcoded secrets were found

Full description

Vulnerability Details

Abbreviation:	REQ.SECRET.GENERIC.CODE

Storing hardcoded secrets in your source code or binary artifact could lead to several risks.

If the secret is associated with a wide scope of privileges, attackers could extract it from the source code or binary artifact and use it maliciously to attack many targets. For example, if the hardcoded password gives high-privilege access to an AWS account, the attackers may be able to query/modify company-wide sensitive data without per-user authentication.

Best practices

Use safe storage when storing high-privilege secrets such as passwords and tokens, for example -

• Environment Variables

Environment variables are set outside of the application code, and can be dynamically passed to the application only when needed, for example -
SECRET_VAR=MySecret ./my_application
This way, MySecret does not have to be hardcoded into my_application.

Note that if your entire binary artifact is published (ex. a Docker container published to Docker Hub), the value for the environment variable must not be stored in the artifact itself (ex. inside the Dockerfile or one of the container's files) but rather must be passed dynamically, for example in the docker run call as an argument.

• Secret management services

External vendors offer cloud-based secret management services, that provide proper access control to each secret. The given access to each secret can be dynamically modified or even revoked. Some examples include -

• Hashicorp Vault
• AWS KMS (Key Management Service)
• Google Cloud KMS

Least-privilege principle

Storing a secret in a hardcoded manner can be made safer, by making sure the secret grants the least amount of privilege as needed by the application.
For example - if the application needs to read a specific table from a specific database, and the secret grants access to perform this operation only (meaning - no access to other tables, no write access at all) then the damage from any secret leaks is mitigated.
That being said, it is still not recommended to store secrets in a hardcoded manner, since this type of storage does not offer any way to revoke or moderate the usage of the secret.

---

🐸 JFrog Frogbot

[github-actions]

🤫 Secret Vulnerability

Severity	Origin	Finding
High	jfrog	Hardcoded secrets were found

Full description

Vulnerability Details

Abbreviation:	REQ.SECRET.GENERIC.CODE

Storing hardcoded secrets in your source code or binary artifact could lead to several risks.

If the secret is associated with a wide scope of privileges, attackers could extract it from the source code or binary artifact and use it maliciously to attack many targets. For example, if the hardcoded password gives high-privilege access to an AWS account, the attackers may be able to query/modify company-wide sensitive data without per-user authentication.

Best practices

Use safe storage when storing high-privilege secrets such as passwords and tokens, for example -

• Environment Variables

Environment variables are set outside of the application code, and can be dynamically passed to the application only when needed, for example -
SECRET_VAR=MySecret ./my_application
This way, MySecret does not have to be hardcoded into my_application.

Note that if your entire binary artifact is published (ex. a Docker container published to Docker Hub), the value for the environment variable must not be stored in the artifact itself (ex. inside the Dockerfile or one of the container's files) but rather must be passed dynamically, for example in the docker run call as an argument.

• Secret management services

External vendors offer cloud-based secret management services, that provide proper access control to each secret. The given access to each secret can be dynamically modified or even revoked. Some examples include -

• Hashicorp Vault
• AWS KMS (Key Management Service)
• Google Cloud KMS

Least-privilege principle

Storing a secret in a hardcoded manner can be made safer, by making sure the secret grants the least amount of privilege as needed by the application.
For example - if the application needs to read a specific table from a specific database, and the secret grants access to perform this operation only (meaning - no access to other tables, no write access at all) then the damage from any secret leaks is mitigated.
That being said, it is still not recommended to store secrets in a hardcoded manner, since this type of storage does not offer any way to revoke or moderate the usage of the secret.

---

🐸 JFrog Frogbot