Yoo HeehyeonYoo Heehyeon

지금 소프트웨어 개발에서 모든 코드를 처음부터 끝까지 직접 짜는 경우는 드물다. 대부분 외부 라이브러리와 프레임워크에 기대고, 그만큼 남의 코드가 내 서비스 안으로 들어온다. 그래서 내 코드가 멀쩡해도, 의존성에 취약점이 있으면 서비스 전체가 같이 위험해진다. 공급망 보안이 중요해진 이유도 여기에 있다.

1. 직접 의존성과 전이적 의존성

SCA의 핵심은 내가 직접 넣은 라이브러리만 보는 게 아니라, 그 아래로 이어지는 의존성까지 전부 따라가는 데 있다.

• 직접 의존성: package.json, requirements.txt 같은 파일에 내가 직접 적은 패키지
• 전이적 의존성: A가 B를 쓰고 B가 C를 쓸 때, A가 간접적으로 의존하게 되는 C 같은 패키지

Log4Shell이 크게 터진 이유도 이 구조 때문이다. 개발자가 Log4j를 직접 쓰지 않아도, 다른 프레임워크가 내부에서 참조하고 있으면 같이 영향을 받는다. SCA는 package-lock.json, go.sum 같은 락 파일을 읽어 의존성 그래프를 만들고, 그 위에 취약점 정보를 매핑한다.

2. SBOM: 소프트웨어의 명세서

SCA의 대표 결과물 중 하나가 SBOM이다. 쉽게 말하면 소프트웨어를 구성하는 부품 목록이다. 식품 원재료표를 떠올리면 이해가 빠르다.

SBOM이 있으면 새 취약점이 나왔을 때 우리 서비스가 영향권인지 바로 조회할 수 있다. 이 목록이 없으면 다시 의존성을 전부 뒤져야 한다.

3. 오탐과 우선순위 관리

SCA는 경고를 많이 뱉는다. 문제는 그걸 전부 같은 우선순위로 처리할 수는 없다는 점이다. 그래서 Reachability 분석이 중요해진다.

• 취약한 라이브러리 버전 v1.2.3을 쓰고 있다.
• 하지만 우리 코드는 그 라이브러리의 취약한 함수 vuln_func()을 실제로 호출하지 않는다.

단순 버전 매칭만으로는 실무 우선순위를 정하기 어렵다. 결국은 실제 호출 그래프를 보고, 진짜로 실행 가능한 위험만 걸러내는 방향으로 가야 한다.