🛡️ Sentinel: [HIGH] Fix Null Byte Injection in File Validation

[seonghobae]

🛡️ Sentinel: [HIGH] Fix Null Byte Injection in File Validation

🚨 Severity: HIGH
💡 Vulnerability: DefaultDocumentValidationService에서 업로드된 파일의 원본 파일명에 Null Byte(\u0000)가 포함되어 있는지 검증하지 않았습니다.
🎯 Impact: 공격자가 파일명에 Null Byte를 주입하여 확장자 검증을 우회하고(예: malicious.hwp\u0000.pdf), 하위 시스템에서 파일명이 절삭되도록 만들어 악성 파일을 업로드할 수 있는 위험이 있습니다.
🔧 Fix: 원본 파일명을 획득한 직후 fileName.indexOf('\u0000') >= 0 검사를 수행하여 Null Byte가 발견되면 즉시 IllegalArgumentException을 던져(fail securely) 해당 입력을 명시적으로 거부하도록 수정했습니다.
✅ Verification:

• 단위 테스트 rejectsFilenameWithNullByte 작성 및 통과 확인
• mvn test 명령어로 기존 테스트 포함 모든 테스트 100% 통과 확인 (Failures: 0)
• mvn -DskipTests checkstyle:check 명령어로 추가된 코드가 strict Checkstyle 룰을 준수함을 확인
• .jules/sentinel.md에 보안 교훈(Learning) 기록 완료

---

PR created automatically by Jules for task 10962904880897055436 started by @seonghobae

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[seonghobae]

#120 current-head failure follow-up

I re-read the failing current-head logs/SARIF and pushed c0f485c to address the real dependency findings instead of suppressing them.

Observed failures:

• trivy-fs SARIF on the PR merge commit reported com.fasterxml.jackson.core:jackson-databind at 2.19.0 with CVE-2026-54512 and CVE-2026-54513 (HIGH), plus CVE-2026-54514 and CVE-2026-54515 (MEDIUM). Fixed version is 2.21.5 for the full set.
• osv-scan log did not report exploitable findings in source, but failed dependency extraction after Maven Central returned 429 while resolving the old Spring Boot parent metadata (3.5.0). I bumped the parent to a current patch line so extraction has a current base and logs should now identify dependency state cleanly.
• Scorecard posture items are governance/repo-setting work; for this PR I added repo-local SECURITY.md and Maven Dependabot as concrete improvements, while the central Java/Kotlin CodeQL PR scan gap is being handled in fix(ci): tighten central workflow gates .github#382.

Changes pushed:

• Spring Boot parent 3.5.0 -> 3.5.14.
• Explicit jackson-databind version via jackson-bom.version=2.21.5.
• Removed unused org.apache.tika:tika-parsers-standard-package; source/POM scan for org.apache.tika|tika-parsers|Tika under src pom.xml returned no current usage.
• Added .github/dependabot.yml for Maven updates and SECURITY.md for private vulnerability reporting.

Verification:

• mvn -DskipTests -Dincludes=com.fasterxml.jackson.core:jackson-databind dependency:tree resolves jackson-databind:2.21.5.
• mvn test passed: 336 tests, 0 failures, 0 errors, 0 skipped.
• git diff --check passed except Windows LF->CRLF working-tree warnings.
• Codegraph sync/status completed on this branch before commit.

Next loop item: re-check the current-head GitHub checks/SARIF once Actions starts this new SHA, and cancel old-head queued runs where the API permits it so the queue only works on current heads.