fix(security): restack vulnerability response media type on latest main

[seonghobae]

Purpose

Create a clean successor for #296 on the latest protected-main lineage after #292 advanced main and caused #296 application CI to fail closed at the live-base drift guard. This successor preserves only the reviewed private-vulnerability-reporting response media-type hardening and its focused adapter regressions. It does not rewrite, force-push, or mutate the predecessor branch.

Exact construction identity

• protected main immediately before construction and PR creation: 7a62f6ddfc2b435ceab84a954714b97a9534161c;
• predecessor fix(security): restack vulnerability response media type on current main #296 exact unchanged head: 72b47a90a46aae44ce72c5da707d54993a0eb4e7;
• predecessor application CI 31794516787 failed only at verify live pull-request base before lockfile control; exact checkout and package-manager verification had succeeded, while later lockfile/install/release verification was skipped;
• predecessor reviewer-ci and protected-base-eligible central Security Scan were terminal success but remain predecessor evidence only;
• successor exact head at creation: e84fcab6a9cd105df4318b3da7ce4de8a95c7f83;
• successor ancestry: exactly one commit on current protected main, 1 ahead / 0 behind, merge base exactly 7a62f6ddfc2b435ceab84a954714b97a9534161c;
• successor scope: exactly two paths: scripts/private-vulnerability-reporting-audit.mjs and test/private-vulnerability-reporting-adapter.test.ts.

The intervening protected-main movement is the #292 patch-quarantine slice and does not overlap these two paths. Both successor blobs are byte-identical to the reviewed #296 GREEN blobs; all unrelated bytes come from current protected main.

Security behavior

The bounded GitHub response adapter authenticates the media-type token before reading response bytes. It accepts exact application/json and application/vnd.github+json case-insensitively with ordinary parameters, while missing or misleading types such as text/plain; profile=application/json fail before declared-length processing or body access.

The existing 16 KiB streaming cap, fatal UTF-8 decoder, exact HTTP 200 collection contract, redirect refusal, credential omission, boolean-setting evaluation, and read-only evidence semantics remain unchanged. Focused regressions cover JSON media-type parameters/case, misleading and missing media types, oversized streaming, and declared-size refusal.

Evidence boundary

No CI, coverage, scanner, review, model, release, deployment, or predecessor evidence transfers. Keep this successor Draft until this unchanged exact head has fresh terminal-success application ci, reviewer-ci, protected-base-eligible central Security Scan, exact 100% owned production statement/branch/function/line coverage with realistic tests, and zero valid unresolved findings.

Immediately before Ready or merge, independently re-resolve protected main, exact head/ref/ancestry, workflow checkout SHAs, live rulesets, the exact central .github Security Scan revision/triggers/base filters/thresholds, formal reviews, unresolved threads, and active-writer state. Current observable live Noema policy enforces the central Security Scan workflow and does not currently impose an independent formal-approval rule; no synthetic approval requirement is introduced.

This hardens setting evidence only. It does not prove private vulnerability reporting is enabled, visible, staffed, monitored, or exercised end to end; #73 retains those operational acceptance requirements. It does not weaken gates, create a repair/self-modifying workflow, publish/deploy, invent authority/evidence, or select an outbound license.

Supersedes #296 only after fresh exact-head verification and protected integration.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 19 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: db584e13-99b9-4fe2-9250-e02b01902e0d

📥 Commits

Reviewing files that changed from the base of the PR and between 35a220c and 7dbe85b.

📒 Files selected for processing (2)

• scripts/private-vulnerability-reporting-audit.mjs
• test/private-vulnerability-reporting-adapter.test.ts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}