CI 파이프라인에서 SCA 게이트 설정하기：임계값 설계부터 단계별 차단까지

개발 팀이라면 누구나 공감할 딜레마가 있다. SCA 스캔을 CI 파이프라인에 연동하고 나면, 경고는 쏟아지는데 아무도 처리하지 않거나, 아니면 파이프라인이 매일 빨간불로 가득 차 엔지니어가 우회 커밋을 남발하게 된다. 두 결과 모두 같은 실패를 가리킨다—게이트가 유명무실해지거나, 게이트가 팀의 적이 되는 것이다.

문제는 "스캔할 것이냐 말 것이냐"가 아니라 "게이트 전략을 어떻게 설계할 것이냐"에 있다.

게이트의 본질：전면 차단이 아닌 위험 단계 분류

SCA를 처음 도입하는 팀이 저지르는 첫 번째 실수는 "취약점 발견"을 곧바로 "빌드 차단"으로 직결시키는 것이다. 이 방식은 초기에 대량의 노이즈를 만들어낸다. 역사적 의존성에 누적된 기존 취약점, 개발 환경 전용 컴포넌트의 저위험 문제, 도구 자체의 오탐까지 모두 차단을 유발하고, 결국 엔지니어는 경고를 무시하거나 파이프라인을 우회하는 습관을 갖게 된다.

보다 합리적인 설계는 3단계 분류 방식이다.

• 차단(Block)：고위험 이상 취약점(CVSS ≥ 9.0), 공개된 익스플로잇 체인이 존재하는 심각한 취약점, 제품 출시 컴플라이언스에 영향을 미치는 라이선스 충돌 컴포넌트. 이 단계는 머지 전에 반드시 해결해야 하며 예외를 허용하지 않는다.
• 경고(Warn)：중위험 취약점, EOL 컴포넌트(Log4j 1.x처럼 2015년에 이미 유지보수가 종료된 버전을 아직 사용하는 경우 등), 잠재적 충돌은 있지만 영향 범위가 아직 확인되지 않은 라이선스. 경고는 티켓 시스템에 등록되어 다음 이터레이션에서 처리하고, 현재 빌드는 차단하지 않는다.
• 통과(Pass)：저위험 취약점, 테스트 의존성에서만 나타나는 문제, 보안 팀이 확인한 완화 조치가 존재하는 기지의 위험. SBOM에 기록하고 주기적으로 재검토한다.

이 단계 분류 로직은 CleanSource SCA의 내장 정책 엔진과 기본적으로 일치한다. CVSS 점수, 취약점 도달 가능성, 라이선스 유형, 컴포넌트가 위치한 환경(프로덕션/테스트/빌드) 등 여러 차원을 조합해 게이트 규칙을 구성할 수 있어, 일괄 적용으로 인한 오탐 피해를 방지한다.

임계값 설계：숫자에 의미를 부여하라

"CVSS 몇 점부터 차단할 것인가"는 가장 자주 받는 질문이지만, 실제로 임계값을 결정하는 것은 어떤 범용 기준이 아니라 여러분의 비즈니스 컨텍스트다.

임계값 설계 단계에서 진지하게 검토해야 할 몇 가지 차원이 있다.

• 컴포넌트가 공격 표면에 직접 노출되어 있는가? CVSS 7.5짜리 취약점이라도, 내부 배치 처리에만 사용되는 백엔드 서비스에 존재하는 경우와, 외부에 API를 제공하는 핵심 서비스에 존재하는 경우의 처리 우선순위는 완전히 달라야 한다.
• 공개 PoC나 알려진 실제 악용 사례가 존재하는가? Log4Shell(CVE-2021-44228)은 2021년 12월 공개 당시 CVSS가 10점이었지만, 실제 악용 속도가 너무 빨라 점수 자체의 참고 가치가 크게 떨어졌다. 때로는 취약점의 "온도"가 점수보다 더 중요하다.
• 수정 버전이 존재하는가? 업스트림에 패치가 없다면 차단은 압박만 만들 뿐 해결책을 만들지 못한다. 이런 경우 경고와 완화 조치 기록이 더 현실적이다.
• 라이선스 위험의 경계는 어디인가? GPL 계열 라이선스를 상업용 클로즈드소스 제품에 도입하는 것과 내부 도구에 도입하는 것은 법적 영향이 완전히 다르다. 라이선스 충돌 탐지는 제품 형태에 맞게 별도로 규칙을 구성해야 하며, 취약점 게이트와 같은 임계값을 공유해서는 안 된다.

실용적인 시작점은 이렇다. 신규 추가 컴포넌트(증분 부분)에는 엄격한 임계값을, 기존 컴포넌트에는 완화된 임계값을 적용하되, 기존 컴포넌트에 대해서는 감소 계획을 수립한다. 이렇게 하면 역사적 부채가 무한정 늘어나는 것을 방지하면서도, 기존 문제 때문에 정상적인 개발이 매일 차단되는 상황을 피할 수 있다.

증분 스캔：속도는 게이트를 지속 가능하게 하는 핵심이다

대형 프로젝트에서 전체 스캔은 수 분, 심지어 십수 분이 걸릴 수 있다. MR마다 전체 스캔을 트리거하면 파이프라인 대기 비용이 금세 엔지니어의 거부감으로 이어진다.

증분 스캔의 핵심 아이디어는 이렇다. 이번 변경에서 새로 추가되거나 업그레이드된 컴포넌트와, 그것과 의존 관계에 있는 직접적인 상위·하위 컴포넌트만 스캔한다. 변경되지 않은 컴포넌트는 이전 스캔 캐시 결과를 그대로 사용하고, 정기 작업(예: 매일 새벽 전체 스캔을 실행해 취약점 인텔리전스 매칭 결과를 업데이트)에서만 전체 재검토를 수행한다.

CleanSource SCA의 증분 스캔 모드는 MR 하나당 트리거되는 스캔 시간을 60초 이내로 제어할 수 있다. Pre-Merge 단계에서 게이트를 구성하려는 팀에게는 충분히 수용 가능한 지연 범위다. 600개 이상의 패키지 관리 생태계를 커버하고 3억 2천만 개의 컴포넌트 지문을 축적한 데이터 기반 덕분에, "변경 부분만 스캔"한다고 해서 취약점 사각지대가 생기지 않는다.

주목할 점은, 스니펫 수준 탐지(소스코드 단편의 성분 추적)와 매니페스트 수준 탐지를 병행 사용하면, "의존성 파일에 선언되지 않고 코드 안에 숨어 있는" 컴포넌트 도입까지 발견할 수 있다는 것이다. 두 방식의 커버리지 경계에 대해서는 스니펫 수준 SCA와 매니페스트 수준 SCA 비교 분석을 참고하라.

오탐 처리：메커니즘 없는 게이트는 스스로 무너진다

오탐은 모든 보안 도구의 본질적인 문제다. 팀이 체계적인 오탐 처리 프로세스를 갖추지 않으면, 결국 경고가 집단적으로 무시되거나 누군가 설정을 수정해 규칙을 꺼버리는 결과로 이어진다. CleanSource SCA의 오탐률은 15% 이내로 제어되지만, 그럼에도 규모가 큰 프로젝트에서는 오탐의 절대 건수만으로도 인지 부담을 충분히 만들어낼 수 있다.

실제로 작동하는 오탐 처리 프로세스는 다음 단계를 포함해야 한다.

• 신고 창구：엔지니어가 CI 화면에서 직접 "오탐 의심"으로 표시하고, 판단 근거를 함께 기록한다(예: 해당 취약점의 영향 코드 경로가 현재 프로젝트에서 도달 불가능한 경우).
• 검토 담당자：보안 팀 또는 지정된 Security Champion이 정해진 SLA(예: 영업일 2일) 내에 확인 또는 기각 의견을 제시한다.
• 면제 기록：오탐으로 확인된 경우, 유효 기간이 있는 면제 항목을 생성하고 프로젝트 수준 설정 파일에 기록해 버전 관리에 포함시킨다. 면제 항목이 만료되면 자동으로 재검토가 트리거되며, 영구 면제는 허용하지 않는다.
• 업스트림 피드백：도구 측의 구조적 오탐에 대해서는 도구 제공업체에 피드백하는 채널을 열어두고 수정 진행 상황을 추적한다.

이 프로세스의 핵심은 "영구 예외"가 아닌 "기한이 있는 면제"다. 게이트에 유연성을 부여하면서도 면제 목록이 무한정 늘어나 또 다른 형태의 규칙 무력화로 변질되는 것을 막는다.

Jenkins와 GitLab CI 연동 실전 포인트

Jenkins 연동

Jenkins는 일반적으로 Pipeline 스크립트(Jenkinsfile)를 통해 SCA 스캔을 통합한다. 권장 위치는 단위 테스트 이후, 아티팩트 빌드 이전에 스캔 단계를 삽입하는 것이다. CleanSource SCA는 CLI 도구와 REST API 두 가지 호출 방식을 제공하므로 sh 스텝으로 직접 호출할 수 있으며, 스캔 결과는 JSON 또는 SARIF 형식으로 출력되어 후속 파싱이 용이하다.

게이트 로직은 도구의 기본 동작에 의존하지 않고 Jenkinsfile에 명시적으로 작성하는 것을 권장한다. 예를 들어, 스캔 결과에서 심각 취약점 건수를 읽어 0보다 크면 error()를 호출해 파이프라인을 종료하고, 중위험 취약점 건수는 환경 변수에 기록해 unstable()로 빌드를 불안정 상태로 표시하되 직접 실패 처리하지 않는다. 이처럼 명시적으로 제어하면 정책 변경이 도구 업그레이드에 의존하지 않고 버전 추적도 가능하다.

GitLab CI 연동

GitLab CI의 .gitlab-ci.yml은 SCA 스캔을 독립적인 stage로 구성하고, allow_failure: true/false로 후속 stage 차단 여부를 제어하는 것을 지원한다. 권장 구성 방식은 다음과 같다.

• scan stage에서 CleanSource SCA를 실행하고 결과 파일을 출력한다.
• gate stage에서 정책 평가 스크립트를 실행하고, 단계 분류 규칙에 따라 exit 1 여부를 결정한다.
• 스캔 보고서를 artifacts로 저장해 MR 화면 표시 및 이후 감사에 활용한다.

GitLab의 Merge Request Approval Rules는 gate stage가 실패할 경우 보안 팀 구성원이 수동으로 승인해야만 머지할 수 있도록 구성할 수 있다. 직접 차단보다 유연하며, 빠른 이터레이션이 필요한 사업 부문에 적합하다.

SAST 기능도 함께 필요한 팀이라면, CleanCode Security Agent를 CleanSource SCA와 같은 파이프라인에서 병렬로 실행하고 스캔 트리거를 공유해 중복 설정으로 인한 유지보수 부담을 줄일 수 있다. 바이너리 납품이나 펌웨어 시나리오가 포함된다면, CleanBinary를 아티팩트 배포 단계에서 추가해 성분 분석 커버리지를 보완할 수 있다.

---

SCA 게이트 구성은 일회성 엔지니어링 작업이 아니라 지속적인 교정이 필요한 과정이다. 취약점 인텔리전스는 업데이트되고, 컴포넌트 생태계는 변화하며, 비즈니스의 위험 선호도도 달라진다. 게이트 전략 역시 그에 맞춰 반복 개선해야 한다. 단계별 차단에서 출발해 증분 스캔 속도를 수용 가능한 수준으로 만들고, 오탐 처리 프로세스를 안정적으로 운영한다면, 게이트는 비로소 개발 프로세스의 일부가 될 수 있다. 엔지니어가 우회해야 할 장애물이 아니라.

산업별 시나리오에서 차별화된 SCA 전략을 어떻게 설계하는지 알고 싶다면, 금융 업종 오픈소스 거버넌스 실천과 의료기기 SBOM 컴플라이언스의 구체적인 사례 분석을 참고하라.