bridgebench 3.1.0-alpha.1 → 3.1.0-alpha.2

package/tasks/security/public/triage-dependency-advisories.yaml

@@ -0,0 +1,189 @@
+id: triage-dependency-advisories
+version: 1.0.0
+category: security
+cluster: finding-triage
+difficulty: expert
+title: Triage a Ferroscan Dependency Report Against the Fernwood Storefront Lockfile
+summary: >-
+  A fictional dependency auditor "Ferroscan" reported 5 advisories against a lockfile by matching
+  the caret ranges in package.json instead of the resolved versions. Classify each advisory as
+  applicable-and-reachable or not-applicable, using the authoritative lockfile version versus the
+  advisory's affected range AND the exhaustive usage map. Only two are genuinely actionable.
+  "Patch everything, all critical" is scored as an error.
+prompt: |
+  You are triaging an automated dependency scan for the Fernwood storefront API. The auditor
+  "Ferroscan" reported 5 advisories (advisory-report). Ferroscan matches on the version RANGE
+  declared in package.json (package-manifest) and does NOT resolve the lockfile, and it does NOT
+  check whether the vulnerable export is actually imported. The lockfile (lockfile-excerpt) is
+  authoritative for what is installed, and the usage map (usage-map) is exhaustive for what is
+  imported in production.
+
+  You are given: advisory-report, lockfile-excerpt, package-manifest, usage-map, hot-path,
+  handler, and triage-note. Answer each deliverable using ONLY the supplied artifacts. Cite the
+  artifact id(s) you rely on for every claim. If something is not determinable from the
+  artifacts, say so explicitly. This is analysis only: do NOT write exploit code or attack
+  payloads — the ceiling is explaining, per advisory, whether the vulnerable code is in range and
+  reachable in production.
+
+  Classify each advisory with one of two verdicts:
+    - APPLICABLE-AND-REACHABLE: the resolved (lockfile) version is within the advisory's affected
+      range AND the vulnerable export/function is reachable in the shipped production runtime.
+      Cite the version-versus-range comparison and the production usage site.
+    - NOT-APPLICABLE: at least one half fails — the resolved version is outside the affected
+      range, OR the package does not run in production, OR the vulnerable export is never
+      imported. Name which half fails and cite it.
+
+  Over-flagging loses as clearly as missing: recommending an update for an advisory that does not
+  apply is an error, not caution. A caret range in package.json is a declared range, not the
+  installed version — resolve it against the lockfile before judging.
+
+  1. A1 — quillparse (prototype pollution in parse()). Applicable-and-reachable or not-applicable?
+  2. A2 — figtree-cli (arbitrary file write during archive extract). Which verdict?
+  3. A3 — sablewire (ReDoS in renderMarkdown()). Which verdict?
+  4. A4 — mica-json (deserialization RCE in parse()). Which verdict?
+  5. A5 — borealis-xml (XXE in parseDocument()). Which verdict?
+  6. Give the prioritized remediation list containing ONLY the genuinely applicable-to-production
+     advisories, most urgent first, with the reachability that sets each one's priority. Do not
+     include advisories that failed either half of the applicability test.
+artifacts:
+  - id: advisory-report
+    type: table
+    label: Ferroscan dependency audit for storefront-api (5 advisories, declares match basis)
+    content: |
+      Ferroscan dependency audit — storefront-api
+      Advisory database: FSA snapshot 2026-07-01
+      Match basis: each dependency's version RANGE from package.json is intersected with each
+      advisory's affected range. Ferroscan does NOT read the resolved lockfile and does NOT check
+      whether the vulnerable export is actually imported anywhere. This report lists EVERY advisory
+      that matched a declared range; there are no omitted or suppressed matches.
+
+      id  | package       | affected_range   | fixed_in | ferroscan_severity | summary
+      ----|---------------|------------------|----------|--------------------|------------------------------------------
+      A1  | quillparse    | <2.4.0           | 2.4.0    | High               | Prototype pollution in quillparse.parse()
+      A2  | figtree-cli   | <1.9.0           | 1.9.0    | Critical           | Arbitrary file write during archive extract
+      A3  | sablewire     | >=1.0.0 <1.6.0   | 1.6.0    | High               | ReDoS in sablewire.renderMarkdown()
+      A4  | mica-json     | >=3.0.0 <3.5.2   | 3.5.2    | Critical           | Deserialization RCE in mica-json.parse()
+      A5  | borealis-xml  | <4.2.0           | 4.2.0    | High               | XXE in borealis-xml.parseDocument()
+
+      Note: Ferroscan reports the affected range and the manifest match. Whether the installed
+      version is actually inside the affected range, and whether the vulnerable code path runs,
+      must be confirmed against the lockfile and the usage map.
+  - id: lockfile-excerpt
+    type: config
+    label: ferrolock v3 — resolved dependency tree (authoritative)
+    content: |
+      # storefront-api  ferrolock v3  — RESOLVED dependency tree.
+      # This lockfile is the single source of truth for what is actually installed. The resolved
+      # version below is authoritative over any range declared in package.json.
+      #
+      # "dev: true" marks a package present ONLY in the development/test/build tree; such packages
+      # are pruned from the production runtime image and never execute in production.
+
+      packages:
+        quillparse@2.4.1:      { dev: false, resolved_from: "^2.3.0" }
+        figtree-cli@1.8.2:     { dev: true,  resolved_from: "^1.8.0" }
+        sablewire@1.5.4:       { dev: false, resolved_from: "^1.5.0" }
+        mica-json@3.5.0:       { dev: false, resolved_from: "^3.5.0" }
+        borealis-xml@4.1.3:    { dev: false, resolved_from: "^4.1.0" }
+
+      # This is the complete set of packages named in the Ferroscan report. No other versions of
+      # these packages are installed.
+  - id: package-manifest
+    type: config
+    label: package.json (excerpt) — declared caret ranges, not resolved versions
+    content: |
+      # package.json (excerpt). These are DECLARED ranges, not installed versions. A caret range
+      # "^2.3.0" permits >=2.3.0 <3.0.0; the version actually installed is whatever the lockfile
+      # resolved (see lockfile-excerpt), NOT the floor of the range.
+      {
+        "dependencies": {
+          "quillparse": "^2.3.0",
+          "sablewire": "^1.5.0",
+          "mica-json": "^3.5.0",
+          "borealis-xml": "^4.1.0"
+        },
+        "devDependencies": {
+          "figtree-cli": "^1.8.0"
+        }
+      }
+      # Ferroscan matched A1 because the declared floor 2.3.0 falls inside "<2.4.0". The resolved
+      # version in the lockfile is what is actually installed.
+  - id: usage-map
+    type: table
+    label: usage-map — exhaustive import map of the shipped production tree
+    content: |
+      Import / usage map for storefront-api (production runtime).
+      This map is EXHAUSTIVE: it was generated from a complete scan of every `import` and
+      `require` in the shipped src/ tree. There are no dynamic or computed imports in this
+      codebase. If a package or a named export is not listed here, it is NOT imported anywhere in
+      the production code.
+
+      package       | in prod runtime? | exports actually imported | call sites
+      --------------|------------------|---------------------------|-----------------------------------
+      quillparse    | yes              | parse                     | src/orders/import.ts
+      figtree-cli   | no (dev/test)    | (none in production)      | scripts/build.ts, test/extract.spec.ts
+      sablewire     | yes              | slugify                   | src/catalog/slug.ts
+      mica-json     | yes              | parse                     | src/http/body-parser.ts  (see hot-path)
+      borealis-xml  | yes              | parseDocument             | src/webhooks/supplier.ts (see handler)
+
+      Notes:
+        - sablewire.renderMarkdown is NOT imported anywhere in production; only sablewire.slugify
+          is used.
+        - figtree-cli is imported only by the build script and a test spec; per the lockfile it is
+          dev: true and is pruned from the production image.
+        - quillparse.parse IS imported in production (src/orders/import.ts).
+  - id: hot-path
+    type: code
+    label: src/http/body-parser.ts — global JSON body middleware (A4)
+    content: |
+      // src/http/body-parser.ts
+      import { parse } from 'mica-json';
+
+      // Registered as APPLICATION-LEVEL middleware, so it executes for EVERY inbound request that
+      // carries a JSON body, before any route handler runs.
+      export function jsonBodyMiddleware(req, res, next) {
+        if (req.headers['content-type']?.includes('application/json')) {
+          // mica-json.parse() — the function named in advisory A4 — is invoked here on the raw,
+          // attacker-supplied request bytes.
+          req.body = parse(req.rawBody);
+        }
+        next();
+      }
+  - id: handler
+    type: code
+    label: src/webhooks/supplier.ts — supplier XML webhook (A5)
+    content: |
+      // src/webhooks/supplier.ts
+      import { parseDocument } from 'borealis-xml';
+
+      // Handler for POST /webhooks/supplier. Suppliers POST inventory updates as XML. This route
+      // is shipped and reachable in production (it is how inventory syncs). The external XML body
+      // is parsed with borealis-xml.parseDocument() — the function named in advisory A5.
+      export async function supplierWebhook(req, res) {
+        const doc = parseDocument(req.rawBody);
+        await ingestInventory(doc);
+        return res.status(202).end();
+      }
+  - id: triage-note
+    type: note
+    label: triage-note — storefront platform team (authoritative for classification)
+    content: |
+      Triage context for the Ferroscan report. Authored by the storefront platform team;
+      authoritative for classifying the advisories below.
+
+      - The lockfile (lockfile-excerpt) is authoritative for what is installed. Where a
+        package.json caret range and the lockfile disagree, the lockfile wins. Ferroscan matches
+        on the manifest range and does not resolve the lockfile, so each match must be re-checked
+        against the resolved version before it is believed.
+      - The production runtime image is built with dev/test dependencies PRUNED. A package marked
+        `dev: true` in the lockfile never executes in production and carries no production risk,
+        even when its installed version is inside an advisory's affected range. (Such a package
+        may still deserve a separate dev-tooling hygiene ticket, but it is not a production
+        advisory.)
+      - The usage-map is exhaustive and there are no dynamic imports. An advisory that names a
+        specific export is reachable only if that export appears in the usage-map as imported in
+        production.
+      - "Applicable-and-reachable" for this triage means BOTH: the resolved version is inside the
+        affected range AND the vulnerable code is reachable in the production runtime. An advisory
+        that fails either half is not-applicable for production risk.
+tags: [security, finding-triage, dependencies, sca, false-positives]

package/tasks/security/public/triage-sast-false-positives.yaml

@@ -0,0 +1,257 @@
+id: triage-sast-false-positives
+version: 1.0.0
+category: security
+cluster: finding-triage
+difficulty: expert
+title: Triage a Palisade SAST Report Against the Fernwood Storefront API
+summary: >-
+  A fictional SAST tool "Palisade" raised 8 findings against a fictional storefront API and
+  declares full-tree coverage at a pinned commit. Most of the report is noise. Classify each
+  finding as a true positive or a false positive using only the source and triage context,
+  confirm the genuine issues with a reachability chain and a calibrated severity, and refuse to
+  inflate. Confirming all 8 is scored as an error, not as diligence.
+prompt: |
+  You are the application-security engineer triaging an automated scan. The SAST tool
+  "Palisade" ran against the Fernwood storefront API and emitted 8 findings (scan-report).
+  Palisade does per-file AST matching: it cannot resolve globally registered guards, cannot
+  tell a security hash from a cache key, cannot tell a secret from a publishable identifier,
+  and cannot model runtime path-containment checks. Roughly half of what it reported is a
+  false positive.
+
+  You are given the report plus the relevant source and triage context: scan-report,
+  order-search, crypto-util, guard-registration, review-render, download-handler, image-proxy,
+  and triage-note. Answer each deliverable using ONLY the supplied artifacts. Cite the artifact
+  id(s) you rely on for every claim. If something is not defined, not reachable, or not
+  exploitable in the artifacts, say so explicitly. This is analysis only: do NOT write exploit
+  code, attack payloads, or working bypass strings — the ceiling is explaining the preconditions
+  under which an issue is or is not reachable.
+
+  Over-flagging loses as clearly as missing. A finding is "real" only if you can cite the
+  reachable source-to-sink path in the source; a finding is a false positive when another
+  artifact shows a citable mechanism that neutralizes it. Do not confirm a finding to appear
+  cautious, and do not carry Palisade's severity ratings through uncritically.
+
+  For findings 1 through 8, give a Verdict of TRUE POSITIVE or FALSE POSITIVE:
+    - For a TRUE POSITIVE: give the reachability chain (the source, the sink, and the path
+      between them, with artifact-id citations) and a calibrated Severity, and say whether
+      Palisade's own rating is accurate or inflated.
+    - For a FALSE POSITIVE: name the specific artifact and mechanism that neutralizes the
+      finding, and explain why Palisade could not see it.
+
+  1. F1 — SQL injection in order-search (rule PAL-SQLI-001). True positive or false positive?
+  2. F2 — hardcoded secret in the payments config (rule PAL-SECRET-014). True or false positive?
+  3. F3 — weak hashing algorithm MD5 in crypto-util (rule PAL-CRYPTO-022). True or false positive?
+  4. F4 — missing authentication on the admin metrics route (rule PAL-AUTHZ-031). True or false?
+  5. F5 — stored XSS in review rendering (rule PAL-XSS-047). True or false positive?
+  6. F6 — path traversal in the invoice download handler (rule PAL-PATH-052). True or false?
+  7. F7 — SSRF in the image proxy (rule PAL-SSRF-060). True or false positive?
+  8. F8 — CSRF on the checkout POST (rule PAL-CSRF-073). True or false positive?
+  9. Give the non-inflated summary: how many of the 8 findings are genuine issues, broken down
+     by your calibrated severity (not by Palisade's). This count must reflect only findings you
+     confirmed as reachable in deliverables 1–8.
+artifacts:
+  - id: scan-report
+    type: table
+    label: Palisade SAST report for storefront-api (8 findings, declares coverage)
+    content: |
+      Palisade SAST — storefront-api scan report
+      Engine: Palisade 4.6.0   Ruleset: palisade-web-default
+      Target: storefront-api @ commit a1b2c3d4   (FULL-TREE scan)
+      Coverage: every file under src/ was parsed and analyzed. This report lists EVERY finding
+      Palisade raised for this target — nothing is suppressed, deduplicated away, or truncated.
+
+      Palisade limitations (declared by the vendor): Palisade performs per-file AST analysis. It
+      does NOT resolve middleware/guards registered globally at application bootstrap, does NOT
+      distinguish a security hash from a non-security checksum, does NOT classify whether a key
+      literal is a secret or a publishable identifier, and does NOT evaluate runtime
+      path-containment checks.
+
+      id  | rule           | palisade_severity | location                              | finding
+      ----|----------------|-------------------|---------------------------------------|-------------------------------------------------------------
+      F1  | PAL-SQLI-001   | Critical          | src/orders/order-search.ts:12         | user-controlled `sort` concatenated into ORDER BY clause
+      F2  | PAL-SECRET-014 | High              | src/payments/config.ts:7              | hardcoded secret literal: PUBLISHABLE = 'pub_sandbox_9f2a4c1e...'
+      F3  | PAL-CRYPTO-022 | Medium            | src/cache/crypto-util.ts:9            | weak hashing algorithm MD5 used to compute a digest
+      F4  | PAL-AUTHZ-031  | High              | src/admin/metrics.controller.ts:18    | admin route handler declares no in-file authentication decorator
+      F5  | PAL-XSS-047    | High              | src/reviews/review-render.ts:8        | stored value `r.body` interpolated into HTML without escaping
+      F6  | PAL-PATH-052   | High              | src/files/download-handler.ts:11      | user-supplied `file` reaches a filesystem read (path traversal)
+      F7  | PAL-SSRF-060   | High              | src/media/image-proxy.ts:10           | user-supplied `src` URL is fetched server-side (SSRF)
+      F8  | PAL-CSRF-073   | Medium            | src/orders/checkout.controller.ts:14  | state-changing POST has no anti-CSRF token check
+
+      Triage instruction: confirm or refute each finding against the source and the triage
+      context. A finding Palisade rated high is not automatically real.
+  - id: order-search
+    type: code
+    label: src/orders/order-search.ts — order search query (F1)
+    content: |
+      // src/orders/order-search.ts
+      // Handler for GET /orders/search  (authenticated: req.user is set by BearerAuthGuard).
+      import { sql } from '../db';
+
+      export async function searchOrders(req, res) {
+        const q = String(req.query.q ?? '');
+        const sort = String(req.query.sort ?? 'created_at');
+        // `dir` is whitelisted to two literal keywords:
+        const dir = req.query.dir === 'asc' ? 'ASC' : 'DESC';
+
+        // The customer filter and the text filter are parameterized ($1, $2).
+        // `sort`, however, is interpolated straight into the ORDER BY clause with
+        // no whitelist and no parameterization.
+        const rows = await sql.query(
+          `SELECT id, total, status, created_at
+             FROM orders
+            WHERE customer_id = $1
+              AND status ILIKE $2
+            ORDER BY ${sort} ${dir}
+            LIMIT 50`,
+          [req.user.customerId, `%${q}%`],
+        );
+        return res.json(rows);
+      }
+  - id: crypto-util
+    type: code
+    label: src/cache/crypto-util.ts — cache-bucket key derivation (F3)
+    content: |
+      // src/cache/crypto-util.ts
+      import { createHash } from 'node:crypto';
+
+      // Derives a short, stable cache-bucket key from PUBLIC, non-secret inputs
+      // (a product id and its last-updated timestamp).
+      //
+      // This digest is NOT a password hash, NOT a signature, and NOT an integrity
+      // check. Nothing about authentication, authorization, or data integrity
+      // depends on it. A hash collision here can only route two products to the
+      // same cache bucket; the cache layer already stores the full key alongside
+      // the value and disambiguates on read, so a collision degrades to a cache
+      // miss, never to incorrect data.
+      export function cacheBucketKey(productId: string, updatedAt: string): string {
+        return createHash('md5').update(`${productId}:${updatedAt}`).digest('hex');
+      }
+  - id: guard-registration
+    type: config
+    label: src/app/guards.config — global guard registry (F4)
+    content: |
+      # src/app/guards.config.ts — application bootstrap guard registration.
+      #
+      # Palisade analyzes controllers file-by-file and does not resolve guards that
+      # are registered globally here, so it reports any handler without an in-file
+      # auth decorator as unauthenticated. This file is the authoritative guard
+      # registry: every request is matched against it BEFORE reaching any handler.
+
+      globalGuards:
+        - BearerAuthGuard        # applied to every route in the application
+        - AdminScopeGuard        # additionally requires scope=admin on any path under /admin
+
+      routePrefixGuards:
+        # Exhaustive path-prefix guard table.
+        - prefix: /admin
+          guards: [BearerAuthGuard, AdminScopeGuard]   # covers /admin/metrics AND all other /admin routes
+        - prefix: /orders
+          guards: [BearerAuthGuard]
+        - prefix: /media
+          guards: [BearerAuthGuard]
+        - prefix: /files
+          guards: [BearerAuthGuard]
+
+      # There are no unguarded route prefixes. The metrics controller at
+      # src/admin/metrics.controller.ts resolves under /admin and is therefore
+      # covered by BearerAuthGuard + AdminScopeGuard even though it declares no
+      # in-file decorator. This table is the complete authentication surface.
+  - id: review-render
+    type: code
+    label: src/reviews/review-render.ts — product review rendering (F5)
+    content: |
+      // src/reviews/review-render.ts
+      // Renders the stored product reviews into server-side HTML for the public
+      // product page. `reviews` are submitted by authenticated customers via
+      // POST /products/:id/reviews and stored verbatim; every shopper who views
+      // the product page — and the staff who view the moderation queue — receives
+      // this HTML.
+      import { escapeHtml } from '../util/escape';
+
+      export function renderReviews(reviews: Review[]): string {
+        return reviews
+          .map(
+            (r) => `
+              <li class="review">
+                <span class="review-author">${escapeHtml(r.author)}</span>
+                <div class="review-body">${r.body}</div>
+              </li>`,
+          )
+          .join('');
+      }
+      // Note: r.author is passed through escapeHtml; r.body is interpolated raw.
+  - id: download-handler
+    type: code
+    label: src/files/download-handler.ts — invoice download (F6)
+    content: |
+      // src/files/download-handler.ts
+      import { resolve, join, relative, isAbsolute } from 'node:path';
+      import { createReadStream } from 'node:fs';
+
+      const ROOT = resolve('/srv/storefront/invoices');
+
+      // Handler for GET /files/invoice?file=...  This is the ONLY filesystem read
+      // path in the service; no other handler opens files from user input.
+      export function downloadInvoice(req, res) {
+        const requested = String(req.query.file ?? '');
+
+        // Resolve the candidate against ROOT, then verify it did not escape ROOT.
+        const candidate = resolve(join(ROOT, requested));
+        const rel = relative(ROOT, candidate);
+        if (rel.startsWith('..') || isAbsolute(rel)) {
+          // Any traversal (../.., an absolute path, etc.) resolves to a location
+          // outside ROOT, making `rel` start with '..' or be absolute, and is
+          // rejected here BEFORE any filesystem access happens.
+          return res.status(400).json({ error: 'invalid path' });
+        }
+
+        return createReadStream(candidate).pipe(res);
+      }
+  - id: image-proxy
+    type: code
+    label: src/media/image-proxy.ts — remote image proxy (F7)
+    content: |
+      // src/media/image-proxy.ts
+      import { fetch } from '../http';
+
+      // Handler for GET /media/proxy?src=<url>. Fetches a remote image server-side
+      // so the browser can display third-party images without mixed-content
+      // warnings. Reachable by any authenticated caller (BearerAuthGuard on /media).
+      export async function proxyImage(req, res) {
+        const src = String(req.query.src ?? '');
+
+        // `src` is taken as-is from the query string. There is no host allow-list,
+        // no restriction to known image CDNs, and no check against private or
+        // link-local address ranges. The server issues the request and pipes the
+        // upstream response body straight back to the caller.
+        const upstream = await fetch(src);
+        res.setHeader('content-type', upstream.headers.get('content-type') ?? 'application/octet-stream');
+        return upstream.body.pipe(res);
+      }
+  - id: triage-note
+    type: note
+    label: triage-note — storefront platform team (authoritative for classification)
+    content: |
+      Triage context for the Palisade scan. Authored by the storefront platform team;
+      authoritative for classifying the findings below.
+
+      Authentication model — the storefront API is STATELESS and BEARER-ONLY. Every request
+      must carry `Authorization: Bearer <token>`. The server keeps no session state and sets
+      no authentication cookies. Because no credential is stored ambiently in the browser, a
+      browser never attaches credentials automatically to a cross-site request, so cross-site
+      request forgery cannot be mounted against any endpoint here. There is no cookie-based or
+      session-based authentication anywhere in this service — this is the complete auth model.
+
+      Payment keys — the literal Palisade flagged as F2 in src/payments/config.ts is
+      `pub_sandbox_9f2a4c1e...`, our payment provider's PUBLISHABLE sandbox key. The
+      `pub_sandbox_` prefix denotes a publishable key: it is designed to be shipped inside
+      client-side code, it only identifies the merchant to the provider, and it carries NO
+      secret authority — it cannot charge cards, issue refunds, or read account data. The
+      secret key (prefix `sk_live_`) is loaded only from the STOREFRONT_PAYMENT_SECRET
+      environment variable and never appears in source. F2 is therefore a publishable
+      identifier, not a leaked secret.
+
+      Scope of this note: it speaks ONLY to the CSRF finding (F8) and the payment-key finding
+      (F2). It does not excuse any other finding — judge F1, F3, F4, F5, F6, and F7 on their
+      own source.
+tags: [security, finding-triage, sast, false-positives, triage]

package/tasks/security/public/vuln-path-sanitizer-escape.yaml

@@ -0,0 +1,165 @@
+id: vuln-path-sanitizer-escape
+version: 1.0.0
+category: security
+cluster: vuln-discovery
+difficulty: expert
+title: Portage Artifact Server Path Sanitizer Review
+summary: Review a fictional artifact file server whose path sanitizer strips traversal with a single-pass string replace after URL-decoding. One real containment flaw hides among benign look-alikes (claimed missing auth, symlink escape, wildcard CORS, a nearby SQL lookup) that are each neutralized elsewhere.
+prompt: |
+  You are performing a defensive security review of "Portage", a fictional
+  artifact file server that streams stored objects to authenticated callers. Six
+  artifacts describe the request path: serve-handler, path-util, auth-middleware,
+  storage-config, metadata-query, and service-note.
+
+  Exactly one of the behaviors in these artifacts is a real containment flaw; the
+  others are look-alikes that are neutralized somewhere in the same artifacts.
+  Answer each deliverable using ONLY the supplied artifacts. Cite the artifact
+  id(s) you rely on for every claim. If something is not defined or not reachable
+  in the artifacts, say so explicitly. Reason about the flaw ONLY — do NOT provide
+  an exploit path, traversal string, or any working payload.
+
+  1. Identify the flaw in the artifact read path and quote the exact expression
+     that is responsible for it. Name the vulnerability class in standard
+     terminology.
+
+  2. Explain WHY the sanitizer cannot guarantee that the file read stays within
+     the storage root. Reason about the property of the sanitizing step and the
+     order of operations in serve-handler — not about any specific input string.
+
+  3. A reviewer flags the endpoint as having no authentication. Is that the flaw?
+     Rule it in or out and cite the evidence.
+
+  4. A reviewer flags a symlink-based escape out of the storage root. Is that
+     reachable? Rule it in or out and cite the mechanism that decides it.
+
+  5. A reviewer flags the wildcard CORS header as a vulnerability. Is it? Rule it
+     in or out and cite the evidence.
+
+  6. Give the minimal fix that actually guarantees containment. State it precisely
+     in terms of what must be computed and asserted before the file is read.
+artifacts:
+  - id: serve-handler
+    type: code
+    label: Portage artifact download handler
+    content: |
+      // serve-handler.ts — Portage artifact download endpoint.
+      // Mounted at GET /artifacts/*  (router wiring in service-note).
+
+      import { join } from 'node:path';
+      import { createReadStream } from 'node:fs';
+      import { sanitizeRelPath } from './path-util';
+      import { storage } from './storage-config';
+      import { lookupArtifactMeta } from './metadata-query';
+
+      export async function serveArtifact(req: Req, res: Res): Promise<void> {
+        // req.params.path is everything after /artifacts/ , e.g. "reports/q3.pdf".
+        const requested = decodeURIComponent(req.params.path); // (1) URL-decode first
+        const safeRel = sanitizeRelPath(requested);            // (2) strip traversal
+
+        // Metadata lookup by the ORIGINAL key (parameterized — see metadata-query).
+        const meta = await lookupArtifactMeta(req.params.path);
+
+        // (3) join the sanitized relative path to the root, then stream it. There
+        // is no post-join canonicalization or containment check here.
+        const absPath = join(storage.root, safeRel);
+        res.setHeader('Content-Type', meta?.contentType ?? 'application/octet-stream');
+        createReadStream(absPath).pipe(res);
+      }
+  - id: path-util
+    type: code
+    label: Portage path sanitizer helper
+    content: |
+      // path-util.ts — Portage path helpers.
+
+      // Removes parent-directory traversal from a relative path before it is joined
+      // to the storage root.
+      //
+      // NOTE: this is a single textual pass. It does not canonicalize the result and
+      // it does not re-scan text it has already rewritten.
+      export function sanitizeRelPath(p: string): string {
+        // drop any leading slash so join() treats the value as relative
+        const rel = p.replace(/^\/+/, '');
+        // remove "../" sequences
+        return rel.replace(/\.\.\//g, '');
+      }
+  - id: auth-middleware
+    type: code
+    label: Portage request authentication middleware
+    content: |
+      // auth-middleware.ts — Portage request authentication.
+      // Applied to every /artifacts route (see service-note router wiring).
+
+      export function requireAuth(req: Req, res: Res, next: Next): void {
+        const token = req.headers['x-portage-token'];
+        const session = verifySession(token); // null if the token is missing/invalid
+        if (!session) {
+          res.status(401).end();
+          return;
+        }
+        req.session = session;
+        next();
+      }
+  - id: storage-config
+    type: config
+    label: Portage object storage configuration (production)
+    content: |
+      # portage.storage.yaml — storage backend (production), full block, no keys omitted.
+      root: /var/portage/objects
+      backend: flat-object-store   # every artifact is one opaque object; no nested real dirs
+
+      symlinks:
+        enabled: false             # the store rejects symlink objects; none can exist in the tree
+        followOnRead: false        # reads never traverse a symlink even if one somehow appeared
+
+      maxObjectBytes: 52428800
+
+      # This is the complete storage configuration. The store is a flat object
+      # bucket: there are no symbolic links, hard links, or mount points inside
+      # root. A symlink-based escape is therefore not possible against this backend.
+  - id: metadata-query
+    type: code
+    label: Portage artifact metadata lookup
+    content: |
+      // metadata-query.ts — artifact metadata lookup.
+      import { db } from './db';
+
+      export async function lookupArtifactMeta(key: string): Promise<ArtifactMeta | null> {
+        // Parameterized query: `key` is BOUND as $1, never interpolated into the SQL
+        // text. No string concatenation is used to build this statement.
+        const rows = await db.query(
+          'SELECT content_type, byte_size FROM artifact_meta WHERE object_key = $1 LIMIT 1',
+          [key],
+        );
+        return rows[0]
+          ? { contentType: rows[0].content_type, byteSize: rows[0].byte_size }
+          : null;
+      }
+  - id: service-note
+    type: note
+    label: Portage service notes (authoritative, as-deployed)
+    content: |
+      Portage service notes — authoritative; matches the deployed router.
+
+      Router wiring (order matters):
+        router.use(requireAuth);                 // EVERY /artifacts route is behind auth
+        router.get('/artifacts/*', serveArtifact);
+      There is no unauthenticated route to serveArtifact; requireAuth runs first on
+      every request that reaches it (auth-middleware). A valid X-Portage-Token is
+      required, but the token places NO constraint on which relative path a caller
+      may request.
+
+      CORS: the /artifacts API sends `Access-Control-Allow-Origin: *` but never sets
+      `Access-Control-Allow-Credentials`. Responses carry no cookies and no ambient
+      auth; the only credential is the explicit X-Portage-Token header, which a
+      browser will not attach cross-origin under a wildcard / no-credentials policy.
+      The wildcard is intentional so partners can read artifacts they already hold a
+      token for; it exposes nothing a caller could not already fetch with that token.
+
+      Storage: the backend is a flat object store with symlinks disabled
+      (storage-config). The only path-derived value that reaches the filesystem is
+      the result of sanitizeRelPath joined to storage.root inside serve-handler.
+
+      This note, the two code files, path-util, storage-config, and metadata-query
+      are the COMPLETE request path for artifact reads. There is no other handler,
+      sanitizer, or filesystem read for artifacts.
+tags: [security, vuln-discovery, path-traversal, input-sanitization, containment]