KENSAI Product Update: 3 New Detection Rules, Sitemap Access Fix, and Same-Day Multilingual Publishing

KENSAI shipped three new scanner rules, fixed sitemap access that blocked crawlers, and tightened the multilingual blog pipeline so same-day posts stay aligned across all supported locales.

What shipped today

Today's product update is simple: better detection, better publishing hygiene, and better crawlability. We tightened three parts of the KENSAI pipeline that were creating friction between research, publishing, and search visibility.

The result is less glamorous than a shiny new dashboard, but far more useful: more findings caught automatically, fewer silent publishing mismatches across languages, and sitemap files that crawlers can actually fetch.

1) Detection coverage expanded with three new rules

The scanner gained three new rules extracted from real finding patterns: hardcoded credentials in source or config files, sensitive data disclosure in public responses, and a compound CORS-plus-information-disclosure rule for endpoints that leak data while also trusting the wrong origins.

We also folded in patterns seen around listable S3 buckets and exposed telemetry or key material in frontend responses. That matters because these are the kinds of issues that keep showing up in production, keep getting missed in manual sweeps, and keep turning into expensive embarrassment later.

2) Same-day multilingual publishing is now stricter

We cleaned up the blog freshness logic and the locale syncing path so same-day publishing stops drifting between English and translated indexes. The rule is blunt for a reason: if the English post exists, the matching locale post needs to exist in its own locale index on the same day.

That sounds obvious, but broken automation loves obvious rules. Tightening the index discipline reduces overview mismatches, keeps localized blog pages fresher, and avoids the stupidest possible SEO failure: publishing content while hiding it from your own language pages.

3) Sitemap access for crawlers was repaired

We also fixed a real SEO footgun. Sitemap URLs were returning 403 because the web server could not traverse part of the filesystem path under the workspace root. Once that directory traversal permission issue was corrected, the checked sitemap endpoints returned 200 again.

This is exactly the kind of bug that looks harmless from inside the app and quietly kills discoverability from the outside. If your sitemap is blocked, your publishing cadence stops mattering because crawlers never get the clean inventory of URLs they need.

Why this matters

Security products win on trust, not vibes. Detection quality matters. Publishing reliability matters. Crawlability matters. If any of those break, you do extra work for worse outcomes.

Today's changes make the pipeline more honest: findings discovered by research are easier to encode as reusable rules, posts are harder to leave half-published across languages, and search engines get the files they expect.

What ships next

Next up: keep expanding detection from real-world findings, keep closing translation and index consistency gaps, and keep removing the tiny infrastructure mistakes that sabotage distribution. The boring plumbing is usually where the real leverage hides.