Non-blocking concerns raised while reviewing PR #144 (chore: re-triage the audit baseline, add npm to dependabot).
None of these blocked the merge. They are batched into one issue so a
review's findings stay one unit of attention rather than 1 separate
tracking issues; tick items off as they are addressed, and close this issue
when the list is done or the remaining items are judged not worth doing.
Non-blocking concerns raised while reviewing PR #144 (chore: re-triage the audit baseline, add npm to dependabot).
None of these blocked the merge. They are batched into one issue so a
review's findings stay one unit of attention rather than 1 separate
tracking issues; tick items off as they are addressed, and close this issue
when the list is done or the remaining items are judged not worth doing.
docs/SECURITY-AUDIT.md — section "Astro vendors its own image-size, invisible to this baseline")The PR itself documents that
node_modules/astro/dist/assets/utils/vendor/image-size/ships in the deployed SSR bundle, is not visible tonpm audit, is not covered by theoverridesblock, and will never be reported bycheck-audit-baseline.sh. The author states it is not exploitable today because two guards fail closed: noimage:block inastro.config.mjs(soisRemoteAllowedrejects every remote URL), and the configured@astrojs/netlify/image-service.jsexports notransformmethod (so/_imagethrows first). Both guards are configuration rather than code, so adding animage.domainsentry or switching image services would remove them. Worth tracking as a standing re-check trigger tied to any change to Astro image configuration; consider a lint or CI guard that fails if animage:block or alternate image service is introduced without revisiting this section.