software-composition-analysis

2 개의 포스트

datadog

단일 풀 리퀘스트부터 전체 소프트웨어 패키지까지: 대규모 악성 코드 탐지 (새 탭에서 열림)

BewAIre는 LLM을 활용한 악성 코드 탐지 시스템으로, 기존의 풀 리퀘스트 분석에서 전체 의존성 패키지와 패키지 레지스트리 스캔으로 범위를 확장했다. 저비용 필터 단계와 고성능 에이전트 조사 단계를 결합해 비용과 지연 시간을 줄이면서도 정확도를 97.4%에서 99.86%로 높였고, 오탐을 17건에서 0건으로 낮췄다. 또한 LLM만으로 판단하지 않고 도메인·의존성 검증 같은 정적 검사를 함께 사용해 공급망 공격 탐지의 안정성을 강화했다. ## 풀 리퀘스트 분석만으로는 부족한 이유 - 공격자는 axios, LiteLLM, Mistral 같은 널리 사용되는 의존성 패키지를 침해해 악성 코드를 downstream 사용자에게 확산시킬 수 있다. - 기존 BewAIre는 풀 리퀘스트의 diff를 분석해 침투 테스트, 버그 바운티 활동, 실제 공격을 식별했다. - 그러나 공격 표면은 풀 리퀘스트에 한정되지 않으므로, 전체 패키지와 upstream 레지스트리까지 검사할 필요가 생겼다. - 단순히 더 강력한 추론 모델을 사용하면 정확도는 높아지지만 비용이 증가하고, 대규모 diff는 컨텍스트 윈도우 제한에 부딪힌다. ## 2단계 LLM 평가 구조 - **필터 단계** - 모든 변경 사항을 저렴하고 빠른 모델로 1차 검사한다. - 대규모 diff에는 diff 청크 분할 전략을 적용한다. - 판단은 “의심스러움” 또는 “정상”의 이진 결과다. - 정상으로 판정되면 즉시 종료해 고비용 분석을 피한다. - **조사 단계** - 필터가 의심 신호를 감지한 경우에만 고성능 추론 모델을 호출한다. - 단순히 diff를 읽는 것이 아니라 도구를 사용해 추가 정보를 수집한다. - GitHub API로 커밋 목록, 파일 내용, 기여자 이력, 의존성 메타데이터, 커밋 범위를 조사할 수 있다. - 의심스러운 커밋이 최종 diff에서 사라지도록 되돌려졌는지, 의존성이 typosquatting인지, 작성자의 계정과 소속이 정상적인지 확인한다. - 의존성은 osv.dev와 Datadog SCA 같은 외부 리소스로 검증한다. ## 스택형 LLM 호출이 오탐을 줄인 방식 - 대표 테스트 데이터 690개 diff에서 정확도가 **97.4%에서 99.86%**로 향상됐다. - 오탐은 **17건에서 0건**으로 감소했다. - 대부분의 정상 변경은 필터 단계에서 빠르게 종료되므로 전체 지연 시간도 줄었다. - 의심스러운 변경에 대해서는 더 많은 문맥과 도구를 활용해 정밀한 분석을 수행한다. - 필터 단계와 조사 단계의 역할을 분리함으로써 비용, 속도, 탐지 품질을 동시에 관리했다. ## 에이전트 기반 조사 사례: 파일명에 숨은 명령어 주입 - 공격자는 다음과 같은 형태의 파일명을 사용했다. ```text m$(echo${IFS}...|base64 -d|bash).md ``` - 파일명에 셸 명령 치환을 삽입하고, Base64로 인코딩한 명령을 디코딩해 실행하도록 구성했다. - 실제 페이로드는 외부 서버에서 코드를 내려받아 `bash`로 실행하는 `curl ... | bash` 형태였다. - `${IFS}`를 사용해 공백을 우회하고 보안 필터를 피하려 했다. - 조사 에이전트는 다음과 같은 추가 정황도 확인했다. - 작성자 계정이 생성된 지 7일밖에 되지 않음 - 프로필 정보와 팔로워가 없음 - 리뷰나 승인이 없음 - diff 자체의 악성 명령뿐 아니라 계정 이력과 PR 상태까지 결합해 공격 가능성을 판정했다. ## LLM과 정적 검사의 결합 - 필터 단계는 빠르고 저렴하지만 외부 정보를 직접 탐색하지 못해 일부 공격을 정상으로 판단할 수 있다. - 대표적인 사례가 Datadog과 유사한 도메인을 사용하는 typosquatting 공격이다. - 이를 보완하기 위해 전처리 파이프라인에서 입력에 포함된 모든 도메인을 추출한다. - 정상적인 Datadog 도메인 목록을 바탕으로 생성한 typosquatting 변형 목록과 비교한다. - 이 정적 검사는 LLM에게 의심스러운 Datadog 인접 도메인이라는 명확한 신호를 제공한다. - 비결정적이고 비용이 높은 LLM 판단과 결정적이고 저렴한 정적 검사를 조합해 정확도와 비용 효율을 함께 확보했다. ## 실용적인 결론 대규모 공급망 보안에서는 모든 변경을 고성능 LLM으로 분석하기보다, 저비용 필터와 선택적 심층 조사를 결합하는 방식이 효과적이다. 특히 계정 이력·커밋 상태·도메인·의존성 데이터 같은 외부 문맥과 정적 규칙을 함께 사용해야 LLM의 오탐과 누락을 줄일 수 있다.

gitlab

깃랩 컨테이너 스 (새 탭에서 열림)

GitLab은 컨테이너 라이프사이클 전반에서 발생할 수 있는 보안 위협에 대응하기 위해 파이프라인 기반 스캐닝부터 레지스트리 모니터링까지 다섯 가지 핵심 스캐닝 방식을 제공합니다. 이를 통해 개발자는 취약점을 조기에 발견하는 '시프트 레프트(Shift-left)' 보안을 실현하고, 프로덕션 환경에 배포된 이미지의 안전성을 지속적으로 확보할 수 있습니다. 결과적으로 GitLab의 컨테이너 스캐닝은 단순한 도구를 넘어 소프트웨어 구성 분석(SCA)의 필수 요소로서 통합적인 보안 관리 워크플로우를 구축하도록 돕습니다. ### 파이프라인 기반 컨테이너 스캐닝 * **기능 및 목적**: CI/CD 파이프라인 실행 단계에서 컨테이너 이미지를 검사하여 취약점이 포함된 이미지가 배포되는 것을 사전에 차단합니다. * **기술적 특징**: 오픈 소스 보안 스캐너인 Trivy를 활용하며, Free부터 Ultimate 티어까지 폭넓게 사용할 수 있습니다. * **설정 방법**: 프로젝트의 보안 구성 메뉴에서 머지 요청(MR)을 통해 자동 설정하거나, `.gitlab-ci.yml` 파일에 `Jobs/Container-Scanning.gitlab-ci.yml` 템플릿을 직접 추가하여 활성화합니다. * **사용자 정의**: `CS_IMAGE` 변수를 통해 특정 이미지를 지정하거나, `CS_SEVERITY_THRESHOLD` 변수를 사용해 'High' 또는 'Critical' 등 특정 수준 이상의 취약점만 필터링하여 리포팅하도록 설정할 수 있습니다. ### 취약점 가시성 및 관리 통합 * **머지 요청(MR) 위젯**: 스캔 결과가 MR 페이지 내 보안 위젯에 즉시 노출되어, 개발자가 코드를 병합하기 전에 영향받는 패키지와 해결 가이드를 확인할 수 있습니다. * **중앙 집중식 취약점 보고서**: 보안 팀은 'Vulnerability Report'를 통해 프로젝트 전체의 취약점을 통합 관리하며, 상태 관리(탐지됨, 확인됨, 해결됨 등) 및 담당자 할당이 가능합니다. * **의존성 목록(SBOM)**: 컨테이너 내부의 모든 운영체제 패키지와 애플리케이션 라이브러리를 카탈로그화하여 제공합니다. 이를 통해 소프트웨어 자재 명세서(SBOM)를 관리하고 공급망 보안을 강화할 수 있습니다. ### 레지스트리용 컨테이너 스캐닝 * **자동 모니터링**: GitLab 컨테이너 레지스트리에 푸시된 `latest` 태그 이미지를 대상으로 보안 정책 봇이 자동 스캔을 트리거합니다. * **지속적 취약점 탐지**: Ultimate 티어에서 제공되는 이 기능은 수동 파이프라인 실행 없이도 최신 취약점 데이터베이스(Advisories)를 바탕으로 이미지를 지속적으로 감시합니다. * **활성화 조건**: 프로젝트에 최소 하나 이상의 커밋이 있어야 하며, 컨테이너 레지스트리 알림 기능이 구성된 상태에서 '보안 구성' 메뉴의 토글 스위치를 통해 활성화할 수 있습니다. ### 성공적인 컨테이너 보안을 위한 제언 효과적인 보안 운영을 위해 먼저 **파이프라인 기반 스캐닝**을 도입하여 개발 초기 단계에서 취약점을 걸러내는 환경을 조성하는 것이 중요합니다. 이후 서비스 규모가 커지면 **레지스트리용 스캐닝**을 병행하여 배포된 이후에 새롭게 발견되는 제로데이 취약점 등에 실시간으로 대응하는 다층 방어 전략을 권장합니다.