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:
The payments table declares card_number, card_cvv and card_expiry as plain text, and paymentService.charge inserts those values directly. Storing CVV after authorization is prohibited under PCI DSS under any circumstances, and storing PAN in cleartext pulls the entire database, its backups and anything with DB credentials into card-data scope. The public-read backups bucket in the Terraform makes the blast radius worse.

Reviewed: badapp/db/migrations/0002_add_payments.sql (lines 1-16) — quoted from the scanned source
-- Payments. Storing PAN + CVV is the point: an architecture/compliance finding that no
-- SAST rule will flag, because nothing here is syntactically wrong.
CREATE TABLE IF NOT EXISTS "payments" (
  "id"           uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  "order_id"     uuid NOT NULL REFERENCES "orders"("id"),
  "amount_cents" integer NOT NULL,
  "currency"     varchar(3) NOT NULL DEFAULT 'usd',
  "card_number"  text NOT NULL,
  "card_cvv"     text NOT NULL,
  "card_expiry"  text NOT NULL
);

CREATE UNIQUE INDEX "payments_order_idx" ON "payments" ("order_id");

ALTER TABLE "orders" ADD COLUMN "paid_at" timestamptz;

Suggested remediation:
Stop persisting card data: delegate capture to a payment processor and store only an opaque token plus last four digits and brand. Drop card_cvv immediately and plan a migration to remove card_number.

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

Reported:
aws_s3_bucket.backups sets acl = "public-read". Given the schema stores plaintext card data and password hashes, a world-readable backup bucket exposes the entire customer dataset to anyone who can enumerate or guess the object keys. There is no block-public-access configuration alongside it.

Reviewed: badapp/infra/main.tf (lines 1-14) — quoted from the scanned source
resource "aws_s3_bucket" "backups" {
  bucket = "badapp-backups"
  acl    = "public-read"
}

resource "aws_security_group" "web" {
  ingress {
    from_port   = 0
    to_port     = 65535
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Suggested remediation:
Remove the public-read ACL, set the bucket to private, and add an aws_s3_bucket_public_access_block with all four flags enabled plus server-side encryption.

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

Reported:
app.js mounts adminRoutes at /admin with no auth middleware, and admin.js defines no per-route guard. The routes behind it include a shell-executing /ping and a /refund that writes payment rows. The users table has an is_admin column and the project depends on jsonwebtoken, so an authorization concept exists in the data model but is never enforced in the request path.

Reviewed: badapp/src/app.js (lines 1-15) — quoted from the scanned source
const express = require("express");
const publicRoutes = require("./routes/public");
const userRoutes = require("./routes/users");
const adminRoutes = require("./routes/admin");
const { log } = require("./lib/logger");

const app = express();

app.use("/", publicRoutes);
app.use("/", userRoutes);
// ARCHITECTURE SMELL: admin surface mounted with no authentication middleware at all.
app.use("/admin", adminRoutes);

app.listen(3000, () => log("listening on 3000"));

Suggested remediation:
Introduce an authentication middleware (verify a signed token, load the user, require is_admin) and apply it at the app.use('/admin', ...) mount point before any admin handler is registered.

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

Reported:
findUser, findOrders and findReviews interpolate their arguments into SQL with + and no escaping, and they are fed directly from req.query.id / req.query.userId by the /user and /orders routes. The connection authenticates as the MySQL root user, so a successful injection has full database privileges including reads of the payments table.

Reviewed: badapp/src/db/queries.js (lines 1-13) — quoted from the scanned source
const { connect } = require("./client");

// SQL injection: string concatenation straight into the query.
exports.findUser = (id, cb) =>
  connect().query("SELECT * FROM users WHERE id = '" + id + "'", cb);

exports.findOrders = (userId, cb) =>
  connect().query("SELECT * FROM orders WHERE user_id = '" + userId + "'", cb);

// ARCHITECTURE SMELL: queries a `reviews` table that no migration creates (schema drift).
exports.findReviews = (productId, cb) =>
  connect().query("SELECT * FROM reviews WHERE product_id = '" + productId + "'", cb);

Suggested remediation:
Switch every query to parameter placeholders (mysql's query(sql, [params]) form) and forbid string-built SQL in the data layer via review or a lint rule.

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

Reported:
exec() runs its argument through a shell, and req.query.host is concatenated directly into it. A host value containing shell metacharacters runs additional commands in the container. Combined with the missing authentication on the /admin router, this is an unauthenticated shell.

Reviewed: badapp/src/routes/admin.js (lines 1-19) — quoted from the scanned source
const express = require("express");
const { exec } = require("child_process");
const paymentService = require("../services/paymentService");
const router = express.Router();

// NO AUTH ON ANY OF THESE. The architecture finding is the missing boundary, not the syntax.

// shell command built from user input -> command injection
router.get("/ping", (req, res) =>
  exec("ping -c 1 " + req.query.host, (err, stdout) => res.send(stdout)),
);

router.post("/refund", (req, res) =>
  paymentService.charge(req.query.orderId, { number: "[secret redacted]", cvv: "123", expiry: "12/30" },
    (e) => res.json({ ok: !e })),
);

module.exports = router;

Suggested remediation:
Replace exec with execFile('ping', ['-c','1', host]) and validate host against a strict hostname/IP pattern before use; then put the route behind authentication.

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

Reported:
The /calc handler evaluates req.query.expr with eval() and returns the result. Any caller controls the string that is evaluated in the Node process, which means arbitrary JavaScript execution with the privileges of the app (which, per the Dockerfile, runs as root). This is full remote code execution on the web tier, not an input-validation nit.

Reviewed: badapp/src/routes/users.js (lines 1-16) — quoted from the scanned source
const express = require("express");
const queries = require("../db/queries");
const orderService = require("../services/orderService");
const router = express.Router();

router.get("/user", (req, res) => queries.findUser(req.query.id, (e, rows) => res.json(rows)));

router.get("/orders", (req, res) =>
  orderService.ordersFor(req.query.userId, (e, rows) => res.json(rows)),
);

// eval on user input -> code injection
router.get("/calc", (req, res) => res.send(String(eval(req.query.expr))));

module.exports = router;

Suggested remediation:
Delete the /calc route. If expression evaluation is genuinely a product requirement, replace eval with a sandboxed, non-Turing-complete expression parser and an allowlisted grammar.

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

Reported:
worker/db.py concatenates a path into a shell command with shell=True, and run() calls eval() on its argument. Whatever feeds these functions becomes a code-execution channel into the worker container, which shares the same image and network as the web service.

Reviewed: badapp/worker/db.py (lines 1-32) — quoted from the scanned source
import os
import sqlite3
import subprocess

DSN = os.environ["DATABASE_URL"]


def lookup(user_id):
    conn = sqlite3.connect("app.db")
    # SQL injection: query built by string formatting
    return conn.execute("SELECT * FROM users WHERE id = '%s'" % user_id).fetchall()


def mark_paid(order_id):
    # ARCHITECTURE SMELL: a second, independent writer to `orders` in another language,
    # with no shared schema ownership and no migration of its own.
    conn = sqlite3.connect("app.db")
    conn.execute("UPDATE orders SET status = 'paid' WHERE id = '%s'" % order_id)


def backup(path):
    # command injection: shell=True with interpolated input
    subprocess.call("tar czf backup.tgz " + path, shell=True)


def run(code):
    # arbitrary code execution
    return eval(code)


API_KEY = "[secret redacted]"

Suggested remediation:
Replace subprocess.call("tar czf ... " + path, shell=True) with a list-argument call and shell=False, and delete run(); if dynamic behaviour is needed, dispatch through an explicit map of allowed operations.

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:
The scan reports testFileCount 0 across 24 files, and the CI workflow runs npm install && npm test as its sole step. With no tests present that step either fails or passes vacuously; either way the pipeline provides no signal, and there is nothing preventing regressions in the payment and query paths.

Reviewed: badapp/.github/workflows/ci.yml (lines 1-9) — quoted from the scanned source
name: ci
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm install && npm test

Suggested remediation:
Add integration tests for the routes and the query layer (starting with /orders and paymentService), and make CI fail on missing tests rather than treating an empty suite as a pass.

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

Reported:
The migrations use uuid columns, gen_random_uuid(), timestamptz and quoted identifiers — PostgreSQL syntax — while the application uses the npm mysql driver against a mysql:5.7 container with a mysql:// DSN. These migrations cannot create the schema the running code queries, so the declared data model and the deployed one will diverge from day one.

Reviewed: badapp/db/migrations/0001_init.sql (lines 1-27) — quoted from the scanned source
-- Core schema. Deliberately stores card data in plaintext (design finding, not a SAST one).
CREATE TABLE IF NOT EXISTS "users" (
  "id"            uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  "email"         text NOT NULL UNIQUE,
  "password_hash" text NOT NULL,
  "is_admin"      boolean NOT NULL DEFAULT false,
  "created_at"    timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE IF NOT EXISTS "products" (
  "id"          uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  "sku"         varchar(64) NOT NULL UNIQUE,
  "name"        text NOT NULL,
  "price_cents" integer NOT NULL,
  CONSTRAINT "products_price_positive" CHECK ("price_cents" > 0)
);

CREATE TABLE IF NOT EXISTS "orders" (
  "id"         uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  "user_id"    uuid NOT NULL REFERENCES "users"("id"),
  "product_id" uuid NOT NULL REFERENCES "products"("id"),
  "quantity"   integer NOT NULL DEFAULT 1,
  "status"     text NOT NULL DEFAULT 'pending'
);

CREATE INDEX "orders_user_idx" ON "orders" ("user_id");

Suggested remediation:
Pick one engine. If MySQL is the target, rewrite the migrations in MySQL syntax (CHAR(36)/BINARY(16) ids, TIMESTAMP, backtick quoting) and run them in CI against the same image used in compose.

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

Reported:
aws_security_group.web has a single ingress rule covering ports 0-65535 from any source address. That exposes any service that happens to bind on the instance — database, admin ports, debug listeners — rather than just the application port, and removes the network layer as a compensating control for the auth gaps above.

Reviewed: badapp/infra/main.tf (lines 1-14) — quoted from the scanned source
resource "aws_s3_bucket" "backups" {
  bucket = "badapp-backups"
  acl    = "public-read"
}

resource "aws_security_group" "web" {
  ingress {
    from_port   = 0
    to_port     = 65535
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Suggested remediation:
Narrow the ingress rule to the specific application port from the load balancer's security group, and add explicit rules only for ports that must be reachable.

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

Reported:
src/config.js exports awsAccessKeyId, awsSecretAccessKey, apiToken, adminPassword and jwtSecret as literals in a source file, and db/client.js consumes adminPassword as the database password. Whatever the current values are, this design puts credentials in version control and in every image layer, makes rotation a code deploy, and prevents per-environment separation. A source comment asserts the values are decoys; that claim cannot be verified from the code and should not be relied on.

Reviewed: badapp/src/config.js (lines 1-9) — quoted from the scanned source
// Hardcoded credentials — scanner bait, not real.
module.exports = {
  awsAccessKeyId: "[secret redacted]",
  awsSecretAccessKey: "[secret redacted]",
  apiToken: "[secret redacted]",
  adminPassword: "[secret redacted]",
  jwtSecret: "[secret redacted]",
};

Suggested remediation:
Change config.js to read from process.env (the repo already declares names such as AWS_ACCESS_KEY_ID, JWT_SIGNING_SECRET, DATABASE_URL), fail fast when a variable is missing, and rotate every value that has ever been committed.

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

Reported:
db/client.js hardcodes user "root" and passes config.adminPassword as the database password, and docker-compose sets DATABASE_URL to a root DSN. Any SQL injection therefore executes with full DDL and cross-database privileges, and one secret serves two unrelated trust boundaries.

Reviewed: badapp/src/db/client.js (lines 1-12) — quoted from the scanned source
const mysql = require("mysql");
const config = require("../config");

// ARCHITECTURE SMELL: a new connection per call, credentials from a checked-in module.
exports.connect = () =>
  mysql.createConnection({
    host: "db",
    user: "root",
    password: config.adminPassword,
    database: "badapp",
  });

Suggested remediation:
Create a dedicated application database user with DML-only grants on the badapp schema, give it its own secret supplied via the environment, and stop reusing adminPassword for the datastore.

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

Reported:
client.connect() calls mysql.createConnection on each invocation and no caller ends the connection. Under load this means a TCP handshake plus MySQL auth per request, and connections accumulate until the server's max_connections is hit, at which point all queries start failing. The mysql driver ships a pool API that is going unused.

Reviewed: badapp/src/db/client.js (lines 1-12) — quoted from the scanned source
const mysql = require("mysql");
const config = require("../config");

// ARCHITECTURE SMELL: a new connection per call, credentials from a checked-in module.
exports.connect = () =>
  mysql.createConnection({
    host: "db",
    user: "root",
    password: config.adminPassword,
    database: "badapp",
  });

Suggested remediation:
Replace createConnection with a single module-level mysql.createPool and have the query layer borrow and release connections, or call pool.query directly.

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

Reported:
The handler concatenates req.query.name into an HTML response and sends it with Express's default text/html content type, so attacker-supplied markup and script execute in the victim's browser on the application origin. There is no CSP or output-encoding layer anywhere in the app.

Reviewed: badapp/src/routes/public.js (lines 1-10) — quoted from the scanned source
const express = require("express");
const router = express.Router();

router.get("/health", (req, res) => res.json({ ok: true }));

// reflected user input -> XSS
router.get("/hello", (req, res) => res.send("<h1>Hello " + req.query.name + "</h1>"));

module.exports = router;

Suggested remediation:
HTML-escape the value before interpolation (or render via a template engine with auto-escaping) and add a restrictive Content-Security-Policy header.

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

Reported:
Both routes take the identifier straight from req.query and return the rows as JSON with no session, no ownership check and no field filtering. findUser does SELECT *, so password_hash and is_admin are serialised to the caller. This is an insecure direct object reference plus over-exposure of sensitive columns.

Reviewed: badapp/src/routes/users.js (lines 1-16) — quoted from the scanned source
const express = require("express");
const queries = require("../db/queries");
const orderService = require("../services/orderService");
const router = express.Router();

router.get("/user", (req, res) => queries.findUser(req.query.id, (e, rows) => res.json(rows)));

router.get("/orders", (req, res) =>
  orderService.ordersFor(req.query.userId, (e, rows) => res.json(rows)),
);

// eval on user input -> code injection
router.get("/calc", (req, res) => res.send(String(eval(req.query.expr))));

module.exports = router;

Suggested remediation:
Derive the acting user from an authenticated session/token, scope the query to that user (or require an admin role), and project only the columns the client needs instead of SELECT *.

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

Reported:
paymentService.charge builds an INSERT by concatenating orderId and the card number, CVV and expiry into the statement text. Besides the injection risk, string-built SQL containing PAN data tends to end up verbatim in driver error messages and query logs.

Reviewed: badapp/src/services/paymentService.js (lines 1-11) — quoted from the scanned source
const { connect } = require("../db/client");

// ARCHITECTURE SMELL: a service reaching past the query layer into the driver directly,
// AND persisting full card data (see 0002_add_payments.sql).
exports.charge = (orderId, card, cb) =>
  connect().query(
    "INSERT INTO payments (order_id, amount_cents, card_number, card_cvv, card_expiry) VALUES ('" +
      orderId + "', 100, '" + card.number + "', '" + card.cvv + "', '" + card.expiry + "')",
    cb,
  );

Suggested remediation:
Parameterise the insert, and route it through the shared query layer rather than calling connect().query directly from a service.

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

Reported:
lookup() and mark_paid() interpolate user_id and order_id into SQL strings with %s formatting. sqlite3 accepts parameters natively, so this is gratuitous injection exposure in a component that mutates order payment status.

Reviewed: badapp/worker/db.py (lines 1-32) — quoted from the scanned source
import os
import sqlite3
import subprocess

DSN = os.environ["DATABASE_URL"]


def lookup(user_id):
    conn = sqlite3.connect("app.db")
    # SQL injection: query built by string formatting
    return conn.execute("SELECT * FROM users WHERE id = '%s'" % user_id).fetchall()


def mark_paid(order_id):
    # ARCHITECTURE SMELL: a second, independent writer to `orders` in another language,
    # with no shared schema ownership and no migration of its own.
    conn = sqlite3.connect("app.db")
    conn.execute("UPDATE orders SET status = 'paid' WHERE id = '%s'" % order_id)


def backup(path):
    # command injection: shell=True with interpolated input
    subprocess.call("tar czf backup.tgz " + path, shell=True)


def run(code):
    # arbitrary code execution
    return eval(code)


API_KEY = "[secret redacted]"

Suggested remediation:
Use parameterised execute calls, e.g. conn.execute("SELECT * FROM users WHERE id = ?", (user_id,)), throughout worker/db.py.

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

Reported:
worker/db.py reads DATABASE_URL into DSN but then ignores it and connects to sqlite3 "app.db", updating orders.status to 'paid'. Two services claim ownership of the same logical table in two different databases, and the SQLite file is per-container and ephemeral, so payment status written by the worker is invisible to the web tier and lost on restart.

Reviewed: badapp/worker/db.py (lines 1-32) — quoted from the scanned source
import os
import sqlite3
import subprocess

DSN = os.environ["DATABASE_URL"]


def lookup(user_id):
    conn = sqlite3.connect("app.db")
    # SQL injection: query built by string formatting
    return conn.execute("SELECT * FROM users WHERE id = '%s'" % user_id).fetchall()


def mark_paid(order_id):
    # ARCHITECTURE SMELL: a second, independent writer to `orders` in another language,
    # with no shared schema ownership and no migration of its own.
    conn = sqlite3.connect("app.db")
    conn.execute("UPDATE orders SET status = 'paid' WHERE id = '%s'" % order_id)


def backup(path):
    # command injection: shell=True with interpolated input
    subprocess.call("tar czf backup.tgz " + path, shell=True)


def run(code):
    # arbitrary code execution
    return eval(code)


API_KEY = "[secret redacted]"

Suggested remediation:
Make the worker connect using DSN through the same engine as the web service, and give payment-status writes a single owner (either the worker or the app) with a migration that lives in db/migrations.

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:
The environment inventory includes ADMIN_BYPASS_TOKEN alongside JWT_SIGNING_SECRET, yet no code in the scanned files reads either one and no authentication middleware exists. A named bypass token is a standing backdoor pattern: if any deployed code path honours it, it sidesteps whatever authorization is eventually added.

Suggested remediation:
Confirm whether anything consumes ADMIN_BYPASS_TOKEN; if so, remove that code path and rely on the normal token [secret redacted] flow, and drop the variable from all environments.

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

Reported:
The workflow pins actions/checkout to a major tag and runs npm install, which resolves dependencies afresh and can mutate the lockfile, so CI is not reproducing the versions a deploy would use. The workflow also has no Node version setup step, so the runner's default Node decides the build, which may differ from the node:14 image in the Dockerfile.

Reviewed: badapp/.github/workflows/ci.yml (lines 1-9) — quoted from the scanned source
name: ci
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm install && npm test

Suggested remediation:
Add actions/setup-node pinned to the same Node major as the image, switch to npm ci, and pin actions to a full commit SHA.

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

Reported:
The db service maps 3306:3306, which makes the database reachable from outside the compose network rather than only from web and worker. The root password is supplied inline in the compose environment block, so it lands in shell history, process listings and docker inspect output.

Reviewed: badapp/docker-compose.yml (lines 1-17) — quoted from the scanned source
services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=mysql://root:[secret redacted]@db:3306/badapp
  db:
    image: mysql:5.7
    ports:
      - "3306:3306"
    environment:
      - MYSQL_ROOT_PASSWORD=[secret redacted]
  worker:
    build: .
    command: python worker/db.py

Suggested remediation:
Remove the db ports mapping (service-to-service traffic already works over the compose network) and move MYSQL_ROOT_PASSWORD and DATABASE_URL into a secrets mechanism or an untracked env file.

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

Reported:
The Dockerfile does COPY . . with no .dockerignore evidence, then runs CMD as the default root user. That bakes local files — including any .env, git metadata and infrastructure code — into the image layers and gives a process that already has command-injection and eval sinks full root capability inside the container.

Reviewed: badapp/Dockerfile (lines 1-8) — quoted from the scanned source
FROM node:14
WORKDIR /app
COPY . .
RUN npm install
# Runs as root, ships the whole tree including .env — infra findings.
EXPOSE 3000
CMD ["node", "src/app.js"]

Suggested remediation:
Add a .dockerignore covering .env, .git, infra and node_modules, install with a production-only lockfile install, and add a non-root USER before CMD.

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

Reported:
The data layer exposes a query against reviews, but the migration set defines only users, products, orders and payments. Any caller of findReviews will fail at runtime with an unknown-table error, and the mismatch shows migrations are not the authoritative source for the schema the code assumes.

Reviewed: badapp/src/db/queries.js (lines 1-13) — quoted from the scanned source
const { connect } = require("./client");

// SQL injection: string concatenation straight into the query.
exports.findUser = (id, cb) =>
  connect().query("SELECT * FROM users WHERE id = '" + id + "'", cb);

exports.findOrders = (userId, cb) =>
  connect().query("SELECT * FROM orders WHERE user_id = '" + userId + "'", cb);

// ARCHITECTURE SMELL: queries a `reviews` table that no migration creates (schema drift).
exports.findReviews = (productId, cb) =>
  connect().query("SELECT * FROM reviews WHERE product_id = '" + productId + "'", cb);

Suggested remediation:
Either add a migration creating reviews or delete findReviews, and add a CI step that applies migrations to a scratch database and exercises the query layer against it.

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

Reported:
POST /refund passes a literal card object into paymentService.charge, and charge itself inserts amount_cents as the constant 100 regardless of the order. The endpoint is also named refund while performing an insert into payments. Financial logic embedded as literals in a route handler is impossible to test or configure and will silently produce wrong ledger rows.

Reviewed: badapp/src/routes/admin.js (lines 1-19) — quoted from the scanned source
const express = require("express");
const { exec } = require("child_process");
const paymentService = require("../services/paymentService");
const router = express.Router();

// NO AUTH ON ANY OF THESE. The architecture finding is the missing boundary, not the syntax.

// shell command built from user input -> command injection
router.get("/ping", (req, res) =>
  exec("ping -c 1 " + req.query.host, (err, stdout) => res.send(stdout)),
);

router.post("/refund", (req, res) =>
  paymentService.charge(req.query.orderId, { number: "[secret redacted]", cvv: "123", expiry: "12/30" },
    (e) => res.json({ ok: !e })),
);

module.exports = router;

Suggested remediation:
Derive the amount from the order record, pass card or token data in as a parameter rather than a literal, and rename the operation to match what it actually does.

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

Reported:
Handlers such as /user and /orders bind the error as e and never inspect it, sending res.json(rows) with rows undefined on failure, which yields a 200 with an empty body. /refund collapses every failure mode into ok: false with no detail or logging. Debugging a production incident with this pattern requires reproducing it locally.

Reviewed: badapp/src/routes/users.js (lines 1-16) — quoted from the scanned source
const express = require("express");
const queries = require("../db/queries");
const orderService = require("../services/orderService");
const router = express.Router();

router.get("/user", (req, res) => queries.findUser(req.query.id, (e, rows) => res.json(rows)));

router.get("/orders", (req, res) =>
  orderService.ordersFor(req.query.userId, (e, rows) => res.json(rows)),
);

// eval on user input -> code injection
router.get("/calc", (req, res) => res.send(String(eval(req.query.expr))));

module.exports = router;

Suggested remediation:
Add a shared error-handling path: check err in each callback, log it with context, and respond with an appropriate status code via Express's next(err) and a single error middleware.

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

Reported:
There is a db/queries module that owns SQL, but paymentService imports connect from db/client and issues its own INSERT. With two places allowed to write SQL, cross-cutting fixes — parameterisation, pooling, redaction of card fields in logs — have to be applied in more than one location and will drift.

Reviewed: badapp/src/services/paymentService.js (lines 1-11) — quoted from the scanned source
const { connect } = require("../db/client");

// ARCHITECTURE SMELL: a service reaching past the query layer into the driver directly,
// AND persisting full card data (see 0002_add_payments.sql).
exports.charge = (orderId, card, cb) =>
  connect().query(
    "INSERT INTO payments (order_id, amount_cents, card_number, card_cvv, card_expiry) VALUES ('" +
      orderId + "', 100, '" + card.number + "', '" + card.cvv + "', '" + card.expiry + "')",
    cb,
  );

Suggested remediation:
Move the payment insert into db/queries as a named, parameterised function and have paymentService depend only on that module.

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:
package.json declares jsonwebtoken, handlebars, lodash and minimist, and the Python side declares sqlalchemy, jinja2, pyyaml and requests, yet none of the scanned source imports them — the worker uses raw sqlite3 and the routes build HTML by concatenation. Unused runtime dependencies enlarge the image and the attack surface, and the presence of jsonwebtoken suggests an auth design that was never implemented.

Suggested remediation:
Remove dependencies that nothing imports, and if JWT auth is the intended design, implement it rather than leaving the library declared.

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

Reported:
findUser, findOrders and findReviews all use SELECT *. Beyond leaking password_hash to the /user response, this couples the API payload to the physical schema, so adding a column silently changes what the endpoint returns and what crosses the wire.

Reviewed: badapp/src/db/queries.js (lines 1-13) — quoted from the scanned source
const { connect } = require("./client");

// SQL injection: string concatenation straight into the query.
exports.findUser = (id, cb) =>
  connect().query("SELECT * FROM users WHERE id = '" + id + "'", cb);

exports.findOrders = (userId, cb) =>
  connect().query("SELECT * FROM orders WHERE user_id = '" + userId + "'", cb);

// ARCHITECTURE SMELL: queries a `reviews` table that no migration creates (schema drift).
exports.findReviews = (productId, cb) =>
  connect().query("SELECT * FROM reviews WHERE product_id = '" + productId + "'", cb);

Suggested remediation:
Enumerate the required columns in each query and map them to an explicit response shape in the route layer.

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

Reported:
app.js registers no express.json() or urlencoded middleware, and POST /refund reads orderId from req.query. Request bodies are therefore unavailable to any handler, and mutating operations carry their parameters in the URL where they end up in access logs and browser history.

Reviewed: badapp/src/routes/admin.js (lines 1-19) — quoted from the scanned source
const express = require("express");
const { exec } = require("child_process");
const paymentService = require("../services/paymentService");
const router = express.Router();

// NO AUTH ON ANY OF THESE. The architecture finding is the missing boundary, not the syntax.

// shell command built from user input -> command injection
router.get("/ping", (req, res) =>
  exec("ping -c 1 " + req.query.host, (err, stdout) => res.send(stdout)),
);

router.post("/refund", (req, res) =>
  paymentService.charge(req.query.orderId, { number: "[secret redacted]", cvv: "123", expiry: "12/30" },
    (e) => res.json({ ok: !e })),
);

module.exports = router;

Suggested remediation:
Register express.json() in app.js and change /refund to read its parameters from the request body.

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

Reported:
lib/logger.js emits a timestamp and a concatenated string, and orderService interpolates the caller-supplied userId into it. There is no level, no request correlation id and no structure, so logs cannot be filtered or joined to a request, and newline characters in the input can forge log lines.

Reviewed: badapp/src/services/orderService.js (lines 1-8) — quoted from the scanned source
const queries = require("../db/queries");
const { log } = require("../lib/logger");

exports.ordersFor = (userId, cb) => {
  log("loading orders for " + userId);
  return queries.findOrders(userId, cb);
};

Suggested remediation:
Adopt a structured logger with levels and per-request context, and pass user-supplied values as separate fields rather than concatenating them into the message.

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