The deploy pipeline has no rollback path. A bad release stays live until someone notices and manually intervenes.

1. Add a health check gate after deploy that fails the job on a bad release.
2. Wire an automatic rollback to the previous known-good revision on that failure.
3. Alert on rollback so a human still gets paged.

A privileged credential appears in code that is bundled and shipped to the browser. Anyone who loads the app can read it and use it to bypass row-level security.

1. Move the key to a server-only environment variable and remove it from the client bundle.
2. Rotate the exposed key and invalidate any cached references.
3. Gate privileged writes behind row-level security; verify with a failing test before and after.

semgrep rule yaml.github-actions.security.gha-curl-pipe-shell.gha-curl-pipe-shell matched. A `run:` step pipes the output of `curl` or `wget` directly into a shell interpreter. This is the "curl | bash" install pattern — if the remote server is compromised or the URL is hijacked, an attacker can execute arbitrary code in your CI runner. Consider downloading the file first, verifying its checksum or signature, and then executing it.

1. Review the flagged code against the semgrep rule yaml.github-actions.security.gha-curl-pipe-shell.gha-curl-pipe-shell.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.run-shell-injection.run-shell-injection matched. Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

1. Review the flagged code against the semgrep rule yaml.github-actions.security.run-shell-injection.run-shell-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.run-shell-injection.run-shell-injection matched. Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

1. Review the flagged code against the semgrep rule yaml.github-actions.security.run-shell-injection.run-shell-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.run-shell-injection.run-shell-injection matched. Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

1. Review the flagged code against the semgrep rule yaml.github-actions.security.run-shell-injection.run-shell-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.run-shell-injection.run-shell-injection matched. Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

1. Review the flagged code against the semgrep rule yaml.github-actions.security.run-shell-injection.run-shell-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.run-shell-injection.run-shell-injection matched. Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".

1. Review the flagged code against the semgrep rule yaml.github-actions.security.run-shell-injection.run-shell-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection matched. Detected a sequelize statement that is tainted by user-input. This could lead to SQL injection if the variable is user-controlled and is not properly sanitized. In order to prevent SQL injection, it is recommended to use parameterized queries or prepared statements.

1. Review the flagged code against the semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection matched. Detected a sequelize statement that is tainted by user-input. This could lead to SQL injection if the variable is user-controlled and is not properly sanitized. In order to prevent SQL injection, it is recommended to use parameterized queries or prepared statements.

1. Review the flagged code against the semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection matched. Detected a sequelize statement that is tainted by user-input. This could lead to SQL injection if the variable is user-controlled and is not properly sanitized. In order to prevent SQL injection, it is recommended to use parameterized queries or prepared statements.

1. Review the flagged code against the semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection matched. Detected a sequelize statement that is tainted by user-input. This could lead to SQL injection if the variable is user-controlled and is not properly sanitized. In order to prevent SQL injection, it is recommended to use parameterized queries or prepared statements.

1. Review the flagged code against the semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule generic.secrets.security.detected-generic-secret.detected-generic-secret matched. Generic Secret detected

1. Review the flagged code against the semgrep rule generic.secrets.security.detected-generic-secret.detected-generic-secret.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule generic.secrets.security.detected-jwt-token.detected-jwt-token matched. JWT token detected

1. Review the flagged code against the semgrep rule generic.secrets.security.detected-jwt-token.detected-jwt-token.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule generic.secrets.security.detected-jwt-token.detected-jwt-token matched. JWT token detected

1. Review the flagged code against the semgrep rule generic.secrets.security.detected-jwt-token.detected-jwt-token.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule generic.secrets.security.detected-jwt-token.detected-jwt-token matched. JWT token detected

1. Review the flagged code against the semgrep rule generic.secrets.security.detected-jwt-token.detected-jwt-token.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.remote-property-injection.remote-property-injection matched. Bracket object notation with user input is present, this might allow an attacker to access all properties of the object and even it's prototype. Use literal values for object properties.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.remote-property-injection.remote-property-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection matched. Detected a sequelize statement that is tainted by user-input. This could lead to SQL injection if the variable is user-controlled and is not properly sanitized. In order to prevent SQL injection, it is recommended to use parameterized queries or prepared statements.

1. Review the flagged code against the semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection matched. Detected a sequelize statement that is tainted by user-input. This could lead to SQL injection if the variable is user-controlled and is not properly sanitized. In order to prevent SQL injection, it is recommended to use parameterized queries or prepared statements.

1. Review the flagged code against the semgrep rule javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.browser.security.eval-detected.eval-detected matched. Detected the use of eval(). eval() can be dangerous if used to evaluate dynamic content. If this content can be input from outside the program, this may be a code injection vulnerability. Ensure evaluated content is not definable by external sources.

1. Review the flagged code against the semgrep rule javascript.browser.security.eval-detected.eval-detected.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

POST / is handled by (unknown handler) but no authentication middleware, guard, decorator, dependency or authorization annotation was detected.

1. Apply the project authentication middleware to this route, router group, controller or module.
2. Add authorization checks for admin-only or tenant-scoped actions.
3. Add a regression test proving unauthenticated requests are rejected.

An XML parser is used without disabling external-entity expansion. Attacker-supplied XML can read local files (file:///etc/passwd) or make outbound requests via XXE / billion-laughs.

1. Python: use `defusedxml` instead of stdlib `xml.etree.ElementTree`.
2. Java: `DocumentBuilderFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)`.
3. .NET: `XmlResolver = null; DtdProcessing = DtdProcessing.Prohibit;`.
4. Node: pass `{ explicitArray: false, processExternalEntities: false }` to `xml2js`.

The pinned version of `jsonwebtoken` is vulnerable to CVE-2022-23529. This makes the JWT verifier silently accept forged tokens.

1. Bump `jsonwebtoken` to a version that addresses CVE-2022-23529.
2. After upgrading, re-test the JWT verifier path — defaults often changed across the fix release.
3. Add a CI check that fails on `jsonwebtoken` versions below the fix.

`jwt.decode(...)` is called without an `algorithms=[...]` argument. On PyJWT < 2.0 this silently accepts the token's declared algorithm — including `none` if the attacker chooses.

1. Add `algorithms=['RS256']` (or the right symmetric/asymmetric choice for your stack).
2. Pin PyJWT to >= 2.0 so the default behaviour rejects rather than silently accepts.
3. Centralise the decode call in a single helper so it can't drift per-call-site.

Token verification appears reimplemented in multiple places. Each copy drifts, and a fix in one is missed in the others.

1. Extract token verification into one shared module or middleware.
2. Replace the per-service copies with calls into it.
3. Add a test that an invalid/expired token is rejected by every entry point.

Base image `gcr.io/distroless/nodejs24-debian13` uses a floating tag. Rebuilds pull a different image as upstream publishes, so the build is not reproducible and a compromised upstream tag silently lands in production.

1. Replace the floating tag with a `@sha256:...` digest pin (e.g. `FROM node:18.17.0-alpine@sha256:...`).
2. Add a renovate / dependabot policy that proposes digest bumps when upstream publishes a new patch.
3. Re-check after every base-image rebuild: `docker inspect <image> --format='{{.RepoDigests}}'`.

Base image `alpine` uses a floating tag. Rebuilds pull a different image as upstream publishes, so the build is not reproducible and a compromised upstream tag silently lands in production.

1. Replace the floating tag with a `@sha256:...` digest pin (e.g. `FROM node:18.17.0-alpine@sha256:...`).
2. Add a renovate / dependabot policy that proposes digest bumps when upstream publishes a new patch.
3. Re-check after every base-image rebuild: `docker inspect <image> --format='{{.RepoDigests}}'`.

The image runs as root (no USER directive). A container-escape bug compounds to host root; a vulnerable process running as a low-privilege UID does not.

1. Add a `USER` directive with a non-zero UID near the end of the final stage (e.g. `USER 1000`).
2. For application directories the user writes to, `chown` them to the new UID earlier in the build.
3. Verify with `docker run <image> id` that the runtime UID is non-zero.

Requests carry no correlation id, so a single user action cannot be traced across services when something fails in production.

1. Generate a request id at the edge and attach it to the request context.
2. Propagate it on every outbound call and include it in every log line.
3. Surface it in error responses so support can correlate reports.

trufflehog matched detector JWT. The credential was checked against the live service and was NOT confirmed valid.

1. Rotate the exposed credential at the issuing service immediately.
2. Remove it from source and load it from a secret manager at runtime.
3. Purge it from git history; verified secrets must assume the worst.

trufflehog matched detector JWT. The credential was checked against the live service and was NOT confirmed valid.

1. Rotate the exposed credential at the issuing service immediately.
2. Remove it from source and load it from a secret manager at runtime.
3. Purge it from git history; verified secrets must assume the worst.

trufflehog matched detector PrivateKey. The credential was checked against the live service and was NOT confirmed valid.

1. Rotate the exposed credential at the issuing service immediately.
2. Remove it from source and load it from a secret manager at runtime.
3. Purge it from git history; verified secrets must assume the worst.

semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag matched. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

1. Review the flagged code against the semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag matched. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

1. Review the flagged code against the semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag matched. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

1. Review the flagged code against the semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag matched. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

1. Review the flagged code against the semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag matched. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

1. Review the flagged code against the semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag matched. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

1. Review the flagged code against the semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag matched. GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

1. Review the flagged code against the semgrep rule yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule package_managers.npm.npm-missing-minimum-release-age.npm-missing-minimum-release-age matched. This .npmrc does not set a minimum release age or sets it too low. Newly published packages can be malicious or unstable. Add `min-release-age = 7` to wait 7 days before resolving newly published package versions. Added in: v11.10 Reference: https://github.blog/changelog/2026-02-18-npm-bulk-trusted-publishing-config-and-script-security-now-generally-available/

1. Review the flagged code against the semgrep rule package_managers.npm.npm-missing-minimum-release-age.npm-missing-minimum-release-age.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule package_managers.npm.npm-missing-minimum-release-age.npm-missing-minimum-release-age matched. This .npmrc does not set a minimum release age or sets it too low. Newly published packages can be malicious or unstable. Add `min-release-age = 7` to wait 7 days before resolving newly published package versions. Added in: v11.10 Reference: https://github.blog/changelog/2026-02-18-npm-bulk-trusted-publishing-config-and-script-security-now-generally-available/

1. Review the flagged code against the semgrep rule package_managers.npm.npm-missing-minimum-release-age.npm-missing-minimum-release-age.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.lang.security.audit.prototype-pollution.prototype-pollution-loop.prototype-pollution-loop matched. Possibility of prototype polluting function detected. By adding or modifying attributes of an object prototype, it is possible to create attributes that exist on every object, or replace critical attributes with malicious ones. This can be problematic if the software depends on existence or non-existence of certain attributes, or uses pre-defined attributes of object prototype (such as hasOwnProperty, toString or valueOf). Possible mitigations might be: freezing the object prototype, using an object without prototypes (via Object.create(null) ), blocking modifications of attributes that resolve to object prototype, using Map instead of object.

1. Review the flagged code against the semgrep rule javascript.lang.security.audit.prototype-pollution.prototype-pollution-loop.prototype-pollution-loop.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.lang.security.audit.detect-non-literal-regexp.detect-non-literal-regexp matched. RegExp() called with a `challengeKey` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

1. Review the flagged code against the semgrep rule javascript.lang.security.audit.detect-non-literal-regexp.detect-non-literal-regexp.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.lang.security.audit.detect-non-literal-regexp.detect-non-literal-regexp matched. RegExp() called with a `challengeKey` function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread. For this reason, it is recommended to use hardcoded regexes instead. If your regex is run on user-controlled input, consider performing input validation or use a regex checking/sanitization library such as https://www.npmjs.com/package/recheck to verify that the regex does not appear vulnerable to ReDoS.

1. Review the flagged code against the semgrep rule javascript.lang.security.audit.detect-non-literal-regexp.detect-non-literal-regexp.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.lang.security.audit.hardcoded-hmac-key.hardcoded-hmac-key matched. Detected a hardcoded hmac key. Avoid hardcoding secrets and consider using an alternate option such as reading the secret from a config file or using an environment variable.

1. Review the flagged code against the semgrep rule javascript.lang.security.audit.hardcoded-hmac-key.hardcoded-hmac-key.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.jsonwebtoken.security.jwt-hardcode.hardcoded-jwt-secret matched. A hard-coded credential was detected. It is not recommended to store credentials in source-code, as this risks secrets being leaked and used by either an internal or external malicious adversary. It is recommended to use environment variables to securely provide credentials or retrieve credentials from a secure vault or HSM (Hardware Security Module).

1. Review the flagged code against the semgrep rule javascript.jsonwebtoken.security.jwt-hardcode.hardcoded-jwt-secret.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.lang.security.audit.hardcoded-hmac-key.hardcoded-hmac-key matched. Detected a hardcoded hmac key. Avoid hardcoding secrets and consider using an alternate option such as reading the secret from a config file or using an environment variable.

1. Review the flagged code against the semgrep rule javascript.lang.security.audit.hardcoded-hmac-key.hardcoded-hmac-key.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.express-detect-notevil-usage.express-detect-notevil-usage matched. Detected usage of the `notevil` package, which is unmaintained and has vulnerabilities. Using any sort of `eval()` functionality can be very dangerous, but if you must, the `eval` package is an up to date alternative. Be sure that only trusted input reaches an `eval()` function.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.express-detect-notevil-usage.express-detect-notevil-usage.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.browser.security.eval-detected.eval-detected matched. Detected the use of eval(). eval() can be dangerous if used to evaluate dynamic content. If this content can be input from outside the program, this may be a code injection vulnerability. Ensure evaluated content is not definable by external sources.

1. Review the flagged code against the semgrep rule javascript.browser.security.eval-detected.eval-detected.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.express-res-sendfile.express-res-sendfile matched. The application processes user-input, this is passed to res.sendFile which can allow an attacker to arbitrarily read files on the system through path traversal. It is recommended to perform input validation in addition to canonicalizing the path. This allows you to validate the path against the intended directory it should be accessing.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.express-res-sendfile.express-res-sendfile.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.express-res-sendfile.express-res-sendfile matched. The application processes user-input, this is passed to res.sendFile which can allow an attacker to arbitrarily read files on the system through path traversal. It is recommended to perform input validation in addition to canonicalizing the path. This allows you to validate the path against the intended directory it should be accessing.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.express-res-sendfile.express-res-sendfile.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.express-res-sendfile.express-res-sendfile matched. The application processes user-input, this is passed to res.sendFile which can allow an attacker to arbitrarily read files on the system through path traversal. It is recommended to perform input validation in addition to canonicalizing the path. This allows you to validate the path against the intended directory it should be accessing.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.express-res-sendfile.express-res-sendfile.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.express-res-sendfile.express-res-sendfile matched. The application processes user-input, this is passed to res.sendFile which can allow an attacker to arbitrarily read files on the system through path traversal. It is recommended to perform input validation in addition to canonicalizing the path. This allows you to validate the path against the intended directory it should be accessing.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.express-res-sendfile.express-res-sendfile.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.express-open-redirect.express-open-redirect matched. The application redirects to a URL specified by user-supplied input `query` that is not validated. This could redirect users to malicious locations. Consider using an allow-list approach to validate URLs, or warn users they are being redirected to a third-party website.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.express-open-redirect.express-open-redirect.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.lang.security.audit.unknown-value-with-script-tag.unknown-value-with-script-tag matched. Cannot determine what 'subs' is and it is used with a '<script>' tag. This could be susceptible to cross-site scripting (XSS). Ensure 'subs' is not externally controlled, or sanitize this data.

1. Review the flagged code against the semgrep rule javascript.lang.security.audit.unknown-value-with-script-tag.unknown-value-with-script-tag.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.lang.security.audit.unknown-value-with-script-tag.unknown-value-with-script-tag matched. Cannot determine what 'subs' is and it is used with a '<script>' tag. This could be susceptible to cross-site scripting (XSS). Ensure 'subs' is not externally controlled, or sanitize this data.

1. Review the flagged code against the semgrep rule javascript.lang.security.audit.unknown-value-with-script-tag.unknown-value-with-script-tag.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.express-check-directory-listing.express-check-directory-listing matched. Directory listing/indexing is enabled, which may lead to disclosure of sensitive directories and files. It is recommended to disable directory listing unless it is a public resource. If you need directory listing, ensure that sensitive files are inaccessible when querying the resource.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.express-check-directory-listing.express-check-directory-listing.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.express-check-directory-listing.express-check-directory-listing matched. Directory listing/indexing is enabled, which may lead to disclosure of sensitive directories and files. It is recommended to disable directory listing unless it is a public resource. If you need directory listing, ensure that sensitive files are inaccessible when querying the resource.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.express-check-directory-listing.express-check-directory-listing.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.express-check-directory-listing.express-check-directory-listing matched. Directory listing/indexing is enabled, which may lead to disclosure of sensitive directories and files. It is recommended to disable directory listing unless it is a public resource. If you need directory listing, ensure that sensitive files are inaccessible when querying the resource.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.express-check-directory-listing.express-check-directory-listing.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.express-check-directory-listing.express-check-directory-listing matched. Directory listing/indexing is enabled, which may lead to disclosure of sensitive directories and files. It is recommended to disable directory listing unless it is a public resource. If you need directory listing, ensure that sensitive files are inaccessible when querying the resource.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.express-check-directory-listing.express-check-directory-listing.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.express.security.audit.xss.pug.explicit-unescape.template-explicit-unescape matched. Detected an explicit unescape in a Pug template, using either '!=' or '!{...}'. If external data can reach these locations, your application is exposed to a cross-site scripting (XSS) vulnerability. If you must do this, ensure no external data can reach this location.

1. Review the flagged code against the semgrep rule javascript.express.security.audit.xss.pug.explicit-unescape.template-explicit-unescape.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

An interactive API documentation UI is registered without a visible environment gate. Production exposure of Swagger UI gives attackers an enumerable API surface.

1. Wrap the registration with `if (process.env.NODE_ENV !== 'production')` (or framework equivalent).
2. Or require admin auth on the docs route.
3. Set `docs_url=None` (FastAPI) / `swagger_ui_enabled=false` (NestJS) in production config.

jwt.verify(...) is called without `audience` / `aud` AND `issuer` / `iss` parameters. Tokens minted for a different service or by a different identity provider can be replayed against this verifier.

1. Add `audience=` and `issuer=` (PyJWT) / `audience:` + `issuer:` (jsonwebtoken) / `Audiences` + `ValidIssuer` (.NET).
2. audience: your service's identifier (OIDC client_id / service URL). issuer: your auth provider (Auth0 / Cognito / IdP base URL).
3. Add a regression test that submits a token with wrong audience or wrong issuer and asserts rejection.

jwt.decode(...) is called without `audience` / `aud` AND `issuer` / `iss` parameters. Tokens minted for a different service or by a different identity provider can be replayed against this verifier.

1. Add `audience=` and `issuer=` (PyJWT) / `audience:` + `issuer:` (jsonwebtoken) / `Audiences` + `ValidIssuer` (.NET).
2. audience: your service's identifier (OIDC client_id / service URL). issuer: your auth provider (Auth0 / Cognito / IdP base URL).
3. Add a regression test that submits a token with wrong audience or wrong issuer and asserts rejection.

The route DELETE /api/Products/:id is a sensitive action (delete), and the handler file does not call any recognised audit-logging pattern. SOC 2 CC7.2 / ISO 27001 A.12.4 / HIPAA §164.312(b) all require audit records for privileged actions.

1. Use your framework's audit library (Rails `audited` / `paper_trail`, Django `django-auditlog`, Laravel `spatie/laravel-activitylog`, .NET `Audit.NET`, Spring Envers).
2. Capture: who (actor user_id), what (action verb), which (resource id), when (timestamp), before/after state for updates.
3. Persist to a dedicated audit table or log sink with retention aligned to your compliance regime (SOC 2: typically 1 year; HIPAA: 6 years).

The route DELETE /api/Recycles/:id is a sensitive action (delete), and the handler file does not call any recognised audit-logging pattern. SOC 2 CC7.2 / ISO 27001 A.12.4 / HIPAA §164.312(b) all require audit records for privileged actions.

1. Use your framework's audit library (Rails `audited` / `paper_trail`, Django `django-auditlog`, Laravel `spatie/laravel-activitylog`, .NET `Audit.NET`, Spring Envers).
2. Capture: who (actor user_id), what (action verb), which (resource id), when (timestamp), before/after state for updates.
3. Persist to a dedicated audit table or log sink with retention aligned to your compliance regime (SOC 2: typically 1 year; HIPAA: 6 years).

The route DELETE /api/Quantitys/:id is a sensitive action (delete), and the handler file does not call any recognised audit-logging pattern. SOC 2 CC7.2 / ISO 27001 A.12.4 / HIPAA §164.312(b) all require audit records for privileged actions.

1. Use your framework's audit library (Rails `audited` / `paper_trail`, Django `django-auditlog`, Laravel `spatie/laravel-activitylog`, .NET `Audit.NET`, Spring Envers).
2. Capture: who (actor user_id), what (action verb), which (resource id), when (timestamp), before/after state for updates.
3. Persist to a dedicated audit table or log sink with retention aligned to your compliance regime (SOC 2: typically 1 year; HIPAA: 6 years).

The route DELETE /api/Cards/:id is a sensitive action (delete), and the handler file does not call any recognised audit-logging pattern. SOC 2 CC7.2 / ISO 27001 A.12.4 / HIPAA §164.312(b) all require audit records for privileged actions.

1. Use your framework's audit library (Rails `audited` / `paper_trail`, Django `django-auditlog`, Laravel `spatie/laravel-activitylog`, .NET `Audit.NET`, Spring Envers).
2. Capture: who (actor user_id), what (action verb), which (resource id), when (timestamp), before/after state for updates.
3. Persist to a dedicated audit table or log sink with retention aligned to your compliance regime (SOC 2: typically 1 year; HIPAA: 6 years).

The route DELETE /api/Addresss/:id is a sensitive action (delete), and the handler file does not call any recognised audit-logging pattern. SOC 2 CC7.2 / ISO 27001 A.12.4 / HIPAA §164.312(b) all require audit records for privileged actions.

1. Use your framework's audit library (Rails `audited` / `paper_trail`, Django `django-auditlog`, Laravel `spatie/laravel-activitylog`, .NET `Audit.NET`, Spring Envers).
2. Capture: who (actor user_id), what (action verb), which (resource id), when (timestamp), before/after state for updates.
3. Persist to a dedicated audit table or log sink with retention aligned to your compliance regime (SOC 2: typically 1 year; HIPAA: 6 years).

The route POST /rest/user/login is a sensitive action (login), and the handler file does not call any recognised audit-logging pattern. SOC 2 CC7.2 / ISO 27001 A.12.4 / HIPAA §164.312(b) all require audit records for privileged actions.

1. Use your framework's audit library (Rails `audited` / `paper_trail`, Django `django-auditlog`, Laravel `spatie/laravel-activitylog`, .NET `Audit.NET`, Spring Envers).
2. Capture: who (actor user_id), what (action verb), which (resource id), when (timestamp), before/after state for updates.
3. Persist to a dedicated audit table or log sink with retention aligned to your compliance regime (SOC 2: typically 1 year; HIPAA: 6 years).

The route GET /rest/user/change-password is a sensitive action (password-change), and the handler file does not call any recognised audit-logging pattern. SOC 2 CC7.2 / ISO 27001 A.12.4 / HIPAA §164.312(b) all require audit records for privileged actions.

1. Use your framework's audit library (Rails `audited` / `paper_trail`, Django `django-auditlog`, Laravel `spatie/laravel-activitylog`, .NET `Audit.NET`, Spring Envers).
2. Capture: who (actor user_id), what (action verb), which (resource id), when (timestamp), before/after state for updates.
3. Persist to a dedicated audit table or log sink with retention aligned to your compliance regime (SOC 2: typically 1 year; HIPAA: 6 years).

The route POST /rest/user/reset-password is a sensitive action (password-change), and the handler file does not call any recognised audit-logging pattern. SOC 2 CC7.2 / ISO 27001 A.12.4 / HIPAA §164.312(b) all require audit records for privileged actions.

1. Use your framework's audit library (Rails `audited` / `paper_trail`, Django `django-auditlog`, Laravel `spatie/laravel-activitylog`, .NET `Audit.NET`, Spring Envers).
2. Capture: who (actor user_id), what (action verb), which (resource id), when (timestamp), before/after state for updates.
3. Persist to a dedicated audit table or log sink with retention aligned to your compliance regime (SOC 2: typically 1 year; HIPAA: 6 years).

Different runtime versions across environments means preview can pass while production breaks. Pin one version everywhere.

1. Pin a single node version in an .nvmrc or engines field.
2. Reference that one source from every CI job and the Dockerfile.
3. Fail CI if the running version drifts from the pinned one.

semgrep rule javascript.audit.detect-replaceall-sanitization.detect-replaceall-sanitization matched. Detected a call to `replaceAll()` in an attempt to HTML escape the string `tableData[i].description`. Manually sanitizing input through a manually built list can be circumvented in many situations, and it's better to use a well known sanitization library such as `sanitize-html` or `DOMPurify`.

1. Review the flagged code against the semgrep rule javascript.audit.detect-replaceall-sanitization.detect-replaceall-sanitization.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.

semgrep rule javascript.lang.security.audit.unsafe-formatstring.unsafe-formatstring matched. Detected string concatenation with a non-literal variable in a util.format / console.log function. If an attacker injects a format specifier in the string, it will forge the log message. Try to use constant values for the format string.

1. Review the flagged code against the semgrep rule javascript.lang.security.audit.unsafe-formatstring.unsafe-formatstring.
2. Apply the secure pattern the rule recommends, or refactor to remove the risky construct.
3. Add semgrep to CI so the rule fails the build on regression.