보안 점검 도구가 Viya 4 이미지를 훑으면 pac4j 계열 JAR 에 CVE 가 붙어 나오는 일이 있다. pac4j 는 자바용 인증 라이브러리이고, Viya 4 의 인증 담당 서비스인 SAS Logon Manager 가 Spring Security 와 함께 쓰는 구성 요소다.
사용자 -> Ingress(nginx) -> SAS Logon Manager -> OAuth2 / OIDC / SAML / LDAP
|
+-- JWT 발급과 검증
로그인이 끝나면 SAS Logon 이 JWT 를 발급하고, 이후 REST · CAS 호출은 Authorization: Bearer <토큰> 으로 인증한다. 토큰의 서명 검증에 JWT 처리 라이브러리가 쓰인다.
스캔 결과를 그대로 믿지 말고 파드 안에서 직접 본다.
kubectl -n <네임스페이스> get pods | grep sas-logon
kubectl -n <네임스페이스> exec -it <sas-logon-app 파드> -- \
find / -name '*pac4j*' -o -name '*nimbus-jose*' 2>/dev/null
Spring Boot 는 의존성을 fat JAR 안에 넣는 경우가 많다. 파일 시스템에서 안 보이면 애플리케이션 JAR 안을 본다.
kubectl -n <네임스페이스> exec -it <sas-logon-app 파드> -- \
sh -c 'unzip -l /opt/sas/viya/home/lib/*.jar 2>/dev/null | grep -i pac4j'
경로는 릴리스마다 다르므로 파드 안에서 실제 위치를 확인한다 (확인 필요).
JAR 파일 이름에 버전이 들어 있으면 그것이 기준이다. 이름에 없으면 JAR 안의 매니페스트를 본다.
unzip -p pac4j-jwt-<버전>.jar META-INF/MANIFEST.MF
확인한 버전이 CVE 의 영향 범위에 들어가는지 대조한다. 스캐너가 경로만 보고 상위 패키지 이름으로 뭉뚱그려 보고하는 경우가 흔하므로, 버전 대조 없이 취약하다고 결론 내리지 않는다.
라이브러리에 CVE 가 있다는 사실과 이 환경이 취약하다는 것은 다른 이야기다. 다음을 함께 본다.
판단이 서지 않으면 SAS 기술지원에 릴리스 번호와 JAR 버전을 붙여 문의한다. 해당 릴리스의 대응 여부를 SAS 가 관리한다.
컨테이너 안의 JAR 을 직접 바꾸지 않는다. 이미지가 다시 내려오면 되돌아가고, 지원 대상에서도 벗어난다. 정상 경로는 SAS 가 수정 버전을 담은 릴리스를 내고 그 릴리스로 올리는 것이다.
당장 올리지 못하면 노출면을 줄인다.
노드 파일 시스템을 훑는 스캔은 더 이상 쓰지 않는 옛 이미지 레이어까지 함께 잡는다. 실제로 돌고 있는 이미지 기준으로 다시 확인하는 절차는 SAS Viya 4 컨테이너 이미지 취약점 대응 에 정리돼 있다.