import * 와 같이 *(aestrick)를 사용해서 패키지나 클래스를 가지고 오는 것을 와일드 카드 import라고 한다. 자바, SQL 등 에서 가끔 보인다. 단순히 생각했을 때는 그럼 모든 import의 상위호환아니야? 라고 생각할 수 있지만, 위험한 생각이다. 그럼 와일드 카드 import가 왜 쓰이는지. 왜 권장하지 않는지 알아보자.


와일드카드 Import

*(aestrick)를 사용해서 패키지의 하위 클래스들을 모두 import 해 온다. 

import java.util.*

위처럼 사용하면 util 내부의 모든 클래스를 가져올 수 있다. 

 

언뜻 보면 매우 편리한 기능같다.

하지만 와일드카드 import는 Google JAVA convention에서도 그렇고 지양하는 방법이다.

이에는 치명적인 단점이 있기 때문이다.

 

와일드카드 Import의 단점

🚨 클래스명 중첩 가능성

"다른 패키지에 같은 클래스명을 가진 클래스가 없다"를 보장할 수 없다.

즉, 같은 이름을 가진 클래스가 2개 이상이어서 오버라이딩이 발생할 수 있고, 이는 예기치 않은 오류 발생으로 이어진다.

 

와일드카드 Import에 대한 오해

위의 정의에서 "와일드카드 import는 패키지의 모든 클래스를 가져온다"라고 했지만, 실상 모두 메모리에 로드되는 것은 아니다.

 

🤔 1. 메모리 낭비가 발생한다?

NO!

- JVM이 클래스를 메모리에 로드하는 시점은 런타임이다.

- import는 컴파일 타임에 사용된다.

≫ import를 많이 사용한다고 해서 메모리 사용량이 늘어나지는 않는다.

 

🤔 2. 컴파일 시 클래스 매칭 시간이 오래 걸린다?

사실상 NO!

와일드카드를 쓰면 컴파일러가 해당 패키지에서 사용한 클래스만 찾는 작업을 한다. 

이론상으로는 매칭 시간이 오래 걸릴 것 같지만, 현대 컴파일러의 처리 속도나 IDE의 지원으로 사실상 무시 가능한 수준이다.

 

intelliJ에서 자동 와일드카드 import 설정 해제

intelliJ 설정(커멘드 + ,) -> 에디터 -> 코드 스타일 -> Java -> "'*'가 포함된 import 문을 사용하는 클래스 수" 100으로 설정(걍 큰 수로 설정)

출처: https://thehackernews.com/2025/03/github-action-compromise-puts-cicd.html

 

GitHub Action 침해로 23,000개 이상의 리포지토리 CI/CD 보안이 위험에 처하다

 

사이버 보안 연구원들은 GitHub Action인 tj-actions/changed-files가 지속적으로 CI/CD 워크플로우에서 사용되면서 보안 정보가 유출되었다는 사건에 주목하고 있다.

이번 사건의 대상은 tj-actions/changed-files가 사용된 23,000개 이상의 리포지토리로, 해당 액션은 파일과 디렉토리의 변경 사항을 추적하고 검색하는 데 활용된다.

이 공급망 침해 사건은 CVE 식별자 CVE-2025-30066이 부여되었으며, 2025년 3월 14일에 발생했다.

공격 과정에서 해커들은 액션 코드를 수정하고, 다수의 태그 버전을 소급 업데이트하여 악성 커밋을 참조하도록 만들었다. 이 침해된 액션은 GitHub Action 빌드 로그에 CI/CD 시크릿을 유출하는 역할을 한다.

결과적으로, 공개된 워크플로우 로그는 액션이 실행 중일 때 비인가 민감 정보가 유출될 수 있음을 보여준다. 이 시크릿에는 AWS 액세스 키, GitHub PAT, npm 토큰, 개인 RSA 키 등이 포함되어 있으나, 유출된 정보가 공격자가 제어하는 인프라로 이동했다는 증거는 없다.

특히, 악성 삽입 코드는 runner 워커 프로세스의 CI/CD 시크릿을 유출하는 파이썬 스크립트를 GitHub Gist에서 실행하도록 설계되었으며, 이는 확인되지 않은 소스 코드 커밋에서 비롯되었다. 이후 GitHub Gist는 셧다운 상태에 들어갔다.

tj-actions/changed-files는 조직의 소프트웨어 개발 파이프라인에서 사용되며, 개발자들이 코드 리뷰 후 보통 메인 브랜치에 병합한 코드를 기반으로 파이프라인을 통해 빌드 및 배포를 진행하는 과정에서 활용된다. 이 액션은 커밋, 브랜치, PR 간에 파일이 추가, 수정, 삭제된 내역을 추적할 수 있도록 해준다.

해커들은 액션 코드를 수정하고 악성 커밋을 참조하기 위해 다수의 태그 버전을 소급 업데이트했으며, 이로 인해 수천 개의 CI 파이프라인에 영향을 미치면서 CI/CD 시크릿을 유출하는 악성 파이썬 스크립트를 실행하게 되었다.

이번 tj-actions/changed-files 침해 사건은 확산 중인 CI/CD 환경에서의 공급망 공격 위험을 다시 한번 부각시킨다. 악성 페이로드는 자동 스캐닝 도구의 탐지를 피하기 위해 정교하게 숨겨져 있었다.

프로젝트 소유자들은 익명의 해커들이 침해된 리포지토리에 접근 권한이 있는 @tj-actions-bot이 사용한 GitHub PAT을 해킹하려 시도했다고 전한다. 이에 따라 계정 비밀번호는 업데이트되었고, 인증 방식은 패스키 사용으로 업그레이드되었으며, 권한 수준도 최고 등급으로 재설정되었고, 침해된 PAT은 사용 중지되었다.

영향을 받은 개인 액세스 토큰은 사용 중지된 GitHub Action 시크릿에 저장되어 있으며, 재발 방지를 위해 모든 tj-actions 조직의 프로젝트에서는 더 이상 PAT 사용이 허용되지 않을 예정이다.

GitHub Action 사용자들은 최신 버전으로 업데이트할 것을 권고하며, 3월 14일~15일 사이에 실행된 워크플로우를 검토해 변경된 파일로 인한 예기치 않은 결과가 없는지 확인해야 한다.

이번 보안 이슈는 처음이 아니다. 2024년 1월, tj-actions/changed-filestj-actions/branch-names에서 임의의 코드 실행을 허용하는 치명적 결함(CVE-2023-49291, CVSS 점수: 9.8)이 발견된 바 있다.

이번 사건을 통해 오픈소스 소프트웨어가 최종 사용자에게 전달되는 공급망 위험에 노출될 수 있음을 다시 한 번 실감하게 되었다.

2025년 3월 15일, 모든 버전의 tj-actions/changed-files Action이 공격을 받았다. 해시 핀(hash-pinned) 버전을 사용 중이던 고객들은 공격 시점에 업데이트하지 않았다면 영향을 받지 않을 것으로 보인다.


CI/CD

CI(Continuous Integration): 지속적인 통합

→ 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포지토리에 통합되는 것

  • 빠른 버그 확인 및 해결
  • 소프트웨어 품질 개선
  • 새로운 업데이트의 검증 및 릴리즈 시간 단축

CD(Continuous Delivery/Deployment): 지속적인 배포

→ 공유 리포지토리로 자동으로 릴리즈 & 프로덕션 레벨까지 자동으로 배포

  • 빠른 시간 내에 고객에게 릴리즈 되는 것

  • compromise: 침해
  • retrieve: 검색하다
  • retroactively: 소급하여
  • siphon: 이동하다
  • unverified: 확인되지 않은
  • deploy: 배포
  • revoked: 취소됨
  • pave: 덮어쓰다
  • susceptible: 느끼기 쉬운

ERD를 그리다가 VARCHAR 단위를 보게 되었다. VARCHAR은 CHAR과 어떤 점이 다를지 궁금해져서 조사해보았다.


sql에도 당연하게 데이터 타입이 존재한다. 언제 어떤 데이터타입을 사용하는게 좋을 지 정리해본다.

FLOAT

= 소수점 아래 7자리까지 부동 소수점 숫자 표현

(4바이트)

DOUBLE(REAL)

= 소수점 아래 15자리까지 부동 소수점 숫자 표현

(8바이트)

INT

= ±21억 까지의 정수

(4바이트)

CHAR(n)

= 값의 실제 크기와 관계없이 지정된 크기만큼의 저장공간 할당

(1 ~ 255바이트)

→ 실제 데이터의 크기와 선언된 데이터 크기의 편차가 클 경우 공간 낭비!

  • 그냥 CHAR=CHAR(1)

VARCHAR(n)

= 값의 실제 크기만큼 저장공간 할당

(1 ~ 65535바이트)

→ 데이터 수정(UPDATE)시 빈번한 페이지 재정렬 발생 가능… 비효율적…

UPDATE 후의 데이터가 기존 데이터보다 크기가 클 경우, 기존 데이터 영역을 폐기하고 새로이 할당

→ 크기가 큰 varchar을 여러 개 사용하면 row size 제한에 걸린다. 데이터 전체가 row size에 영향을 준다.

→ 조회 요청이 여러번 오면 버퍼에 캐싱되어 읽어온다.

TEXT

= 값의 실제 크기만큼 저장공간 할당

(1 ~ 65535바이트)

→ 크기가 큰 text를 여러 개 사용해도 row size 제한에 걸리지 않는다.

데이터가 별도로 저장되고, 그 존재만 row size에 영향을 주기 때문에 9~12바이트만 row size에 영향을 준다.

→ 조회 요청이 여러번 오면 별도 저장된 데이터를 실제 공간만큼 할당하고 사용을 요청만큼 반복한다.

https://chanho0912.tistory.com/108

📌 VARCHAR vs TEXT

  VARCHAR TEXT
📏 데이터 최대 길이 상대적으로 짧을 때 사용 상대적으로 길 때 사용
📖 테이블 조회 시 사용 빈도 자주 필요 자주 필요하지 않음
💾 DBMS 메모리 사용 메모리 충분할 때 적합 메모리 제한적일 때 적합
⚡ 속도 & 성능 빠름 (메모리 버퍼에서 직접 접근) 느림 (별도의 저장 공간에서 읽어야 함)
📂 저장 방식 테이블 row에 직접 저장 외부 저장 후 포인터로 관리
🌷 MySQL에는 string 타입이 없다!


DATETIME

= 'YYYY-MM-DD HH:MM:SS' 형식

(8바이트)

TIMESTAMP

= 'YYYY-MM-DD HH:MM:SS' 형식

(4바이트)

→ time_zone 시스템 변수와 관련이 있고 UTC 시간대 변환하여 저장

JSON

= JSON 문서를 저장

(8바이트)

비밀번호를 저장할 때 sha-256을 사용해서 암호화 후 저장하라고 한다.

intelliJ를 다운받았는데 거기서도 sha-256을 봤다.


SHA-256

(Secure Hash Algorithm)

SHA-256은 대표적인 일방향 해시 함수이다.

🍒일방향 해시 함수
입력값을 고정된 길이의 해시 값으로 변환하는 함수
→ 복호화할 수 없음.

 

SHA는 미국 국가안보국(NSA)가 설계한 암호화 기법이다.

여러 시리즈가 있는데, 최초는 SHA-0이었다. 그 후, SHA-1, SHA-2(SHA-224, SHA-256, SHA-384, SHA-512), SHA-3이 발표되었다.

 

<동작 과정>

 

  1. 원래 message에 salt값을 추가한다.(salt에 대해서는 후술하겠다.)
  2. message를 “1010010101…”형태의 이진코드로 변환한다.
  3. 512bits를 단위로 자른다.(= block)
    1. [Padding] 만약, 512bits보다 작다면 pad를 추가하여 길이를 맞춘다.
  4. block을 다시 32bits로 자른다.
  5. 압축 함수를 64회 실행한다.
  6. block 별로 해시값을 구한다.

 

Salt

원래 메세지에 추가하는 임의의 문자열이다.

SHA-256은 일방향 해시함수이기 때문에, input이 같으면 해시값도 같다. 따라서 길이가 짧을 수록, 해독이 쉽다. 또한 이미 SHA-256으로 암호화된 메세지를 해독해 놓은 테이블도 존재한다.(레인보우 테이블)

🍒 Rainbow table
해시 함수(MD5, SHA-1, SHA-2 등)을 사용하여 만들어낼 수 있는 값들을 저장한 표

 

+ Recent posts