gitlab

98 개의 포스트

gitlab

GitLab은 리팩터링과 코드 재서식을 통해 취약점을 추적하는 방법 (새 탭에서 열림)

GitLab은 코드 위치나 줄 번호가 바뀌어도 동일한 취약점을 안정적으로 추적하기 위해 Scope+Offset 핑거프린팅을 개선했습니다. 기존 방식은 주석과 빈 줄도 오프셋에 포함해 비기능적 수정만으로 중복 취약점을 만들 수 있었지만, 개선된 방식은 이를 무시합니다. 벤치마크에서 중복 핑거프린트를 제거하고 고유 핑거프린트를 43% 줄였으며, `scope_offset_compressed` 알고리즘으로 GitLab에 적용되었습니다. ## 코드 변경으로 발생하는 취약점 추적 문제 - 개발자가 주석을 추가하거나 파일을 재포맷하거나 함수를 이동하면 코드 줄 번호가 달라질 수 있습니다. - 줄 번호만으로 취약점을 식별하면 기존 취약점이 새로운 문제로 오인됩니다. - 그 결과 보안 팀은 이미 검토한 취약점을 다시 분류해야 하고, 스캔 결과에 대한 신뢰도도 낮아집니다. ## 기존 Scope+Offset 핑거프린팅 - 2022년에 도입된 방식으로, 취약점을 다음 두 요소의 조합으로 식별합니다. - 취약점을 포함하는 가장 좁은 코드 범위: 모듈, 클래스, 함수 등 - 해당 범위 내부에서 취약점까지의 줄 오프셋 - 파일 전체의 절대 줄 번호 대신 범위 내부 위치를 사용해 코드 이동에 더 강합니다. - 기존 줄 기반 추적보다 불필요한 재감사를 약 30% 줄였습니다. - 그러나 범위 시작점부터 취약점까지의 모든 줄을 계산했기 때문에 주석과 빈 줄 추가에는 취약했습니다. ## 비기능적 코드 무시를 통한 개선 - 개선된 알고리즘은 핑거프린트를 계산할 때 다음 요소를 제외합니다. - 주석 - 빈 줄 - 프로그램 동작에 영향을 주지 않는 코드가 취약점의 정체성에 영향을 주지 않아야 한다는 원칙을 적용했습니다. - 따라서 취약점 앞에 주석을 추가하거나 파일을 재포맷해도 동일한 핑거프린트가 유지됩니다. - 기존 방식의 추적 정밀도는 유지하면서 비기능적 수정에 대한 안정성만 높였습니다. - 스캐너가 이미 생성하는 파스 트리를 재사용하므로 스캔 시간은 증가하지 않습니다. ## 벤치마크 결과 - C/C++, C#, Go, Java, JavaScript, Python, Ruby의 소스 파일 439개를 대상으로 평가했습니다. - 취약점 바로 앞에 주석 또는 빈 줄 하나를 추가하는 커밋 2,247개를 생성했습니다. - 기존 Scope+Offset 방식: - 중복 핑거프린트 1,361개 발생 - 기준 대비 77% 증가 - 정규화된 방식: - 중복 핑거프린트 0개 - 고유 핑거프린트 43% 감소 - 모든 커밋이 취약점 인근의 비기능적 수정이라는 최악의 조건에서도 효과를 확인했습니다. ## GitLab 적용 방식 - 개선된 알고리즘 이름은 `scope_offset_compressed`입니다. - 다음 언어를 지원합니다. - C# - C/C++ - Go - Java - JavaScript - Python - Ruby - PHP - 기존 보안 보고서 형식은 변경되지 않았습니다. - 따라서 여러 SAST 도구를 함께 사용하는 환경에서도 기존 통합 구조와 호환됩니다. - 관련 연구는 “Vulnerability Tracking using Normalized Scope+Offset”라는 제목으로 ASE 2026 Industry Showcase에서 발표될 예정입니다. ## 실용적인 결론 SAST 도구는 줄 번호가 아니라 코드의 논리적 범위와 의미 있는 위치를 기준으로 취약점을 추적해야 합니다. 특히 주석, 빈 줄, 포맷 변경처럼 동작에 영향을 주지 않는 수정은 핑거프린트에서 제외하는 것이 중복 경고와 불필요한 재감사를 줄이는 효과적인 방법입니다.

gitlab

GitLab 패치 릴리스: 19.2.2, 19.1.4, 19.0.6 | GitLab 문서 (새 탭에서 열림)

2026년 8월 12일 GitLab은 CE/EE용 패치 릴리스 19.2.2, 19.1.4, 19.0.6을 공개했다. 이번 릴리스에는 Analytics Dashboards, CI/CD, Duo Workflow, 프로젝트 권한, GraphQL API 등과 관련된 다수의 보안 취약점이 수정되었으므로, 영향을 받는 자체 관리형 GitLab은 즉시 업그레이드해야 한다. GitLab.com은 이미 패치가 적용되었으며, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 릴리스 대상과 업그레이드 권고 - 대상 버전: - GitLab 19.2 → 19.2.2 - GitLab 19.1 → 19.1.4 - GitLab 19.0 → 19.0.6 - CE와 EE 모두에 적용되는 수정이 포함되어 있다. - 별도의 배포 방식이 명시되지 않은 취약점은 Omnibus, 소스 설치, Helm Chart 등 모든 배포 유형에 영향을 준다. - 취약 버전을 사용하는 자체 관리형 설치 환경은 가능한 한 빨리 최신 패치 릴리스로 업그레이드해야 한다. - GitLab은 정기 패치 릴리스를 매월 둘째·넷째 수요일에 제공하며, 심각도가 높은 취약점에는 비정기 긴급 패치를 배포한다. - 보안 취약점의 상세 이슈는 패치된 릴리스 이후 90일이 지나면 공개된다. ## Analytics Dashboards의 XSS 취약점 - **CVE-2026-15217** - Analytics Dashboards의 표 셀 설정값을 제대로 무해화하지 않아 저장형 또는 반사형 XSS가 발생할 수 있었다. - CVSS 8.7. - **CVE-2026-15216** - Analytics Dashboards의 페이지네이션 컨트롤에 렌더링되는 사용자 제어 데이터의 검증이 부족했다. - 이를 통해 XSS가 발생할 수 있었으며 CVSS는 8.7이다. - 두 취약점의 영향 범위: - 18.2 이상 19.0.6 미만 - 19.1.4 미만의 19.1 버전 - 19.2.2 미만의 19.2 버전 - 두 문제 모두 HackerOne 버그 바운티를 통해 보고되었다. ## CI/CD 및 작업 확인 모달의 권한·XSS 문제 - **CVE-2026-15423** - Developer 권한 사용자가 필요한 push 권한 없이 보호 브랜치에서 CI/CD 파이프라인을 실행할 수 있었다. - 파이프라인 참조 검증 과정의 권한 확인이 부적절했던 것이 원인이다. - CVSS 8.5. - 19.0.6, 19.1.4, 19.2.2에서 수정되었다. - **CVE-2026-16627** - CI 수동 작업 확인 모달에서 HTML 콘텐츠를 제대로 정제하지 않아 권한 상승으로 이어질 수 있는 XSS가 발생할 수 있었다. - Developer 권한 인증 사용자가 공격을 수행할 수 있으며 CVSS는 7.7이다. - 19.2.2에서 수정되었다. ## Duo Workflow와 프로젝트 설정 권한 우회 - **CVE-2026-19228** - GitLab EE의 Duo Workflow Service에서 요청에 포함된 identity 정보를 적절히 검증하지 않았다. - 인증된 사용자가 AI 사용량을 다른 네임스페이스에 귀속시킬 수 있었다. - CVSS 8.5. - GitLab 내부 팀원이 발견했으며, 19.1.4와 19.2.2에서 수정되었다. - **CVE-2026-16494** - ProjectsController의 프로젝트 업데이트 엔드포인트에 권한 검사가 누락되었다. - 인증된 사용자가 상위 권한이 필요한 프로젝트 설정을 변경할 수 있었다. - CVSS 7.1. - GitLab EE의 19.1.4 및 19.2.2에서 수정되었다. ## GraphQL API의 서비스 거부 취약점 - **CVE-2026-7427** - GraphQL API의 JSON 파서가 비정상 입력을 충분히 검증하지 않았다. - 인증되지 않은 공격자가 특수한 입력을 보내 서비스 거부(DoS)를 유발할 수 있었다. - CVSS 5.3. - 18.5 이상 19.0.6 미만, 19.1.4 미만의 19.1, 19.2.2 미만의 19.2 버전이 영향을 받는다. ## Merge Request 및 외부 상태 검사 정보 노출 - **CVE-2026-6821** - Merge Requests API의 권한 검사가 누락되어 IP 기반 접근 제한을 우회할 수 있었다. - 인증된 사용자가 비공개 프로젝트의 Merge Request 일부 정보를 읽을 수 있었다. - CVSS 4.3. - GitLab EE 12.0부터 최신 패치 이전 버전까지 광범위하게 영향을 받는다. - **CVE-2026-4879** - 외부 상태 검사 API에서 권한 검사가 부족했다. - Developer 권한 사용자가 상위 권한으로 제한된 외부 상태 검사 설정을 조회할 수 있었다. - CVSS 4.3. - 16.0 이후 19.0.6, 19.1.4, 19.2.2 이전 버전에 영향을 준다. ## npm 패키지 메타데이터 권한 우회 - **CVE-2026-8667** - npm `dist-tags` 엔드포인트의 권한 검사가 부정확했다. - Developer 권한 사용자가 Maintainer 권한 없이 일부 패키지 레지스트리 메타데이터를 수정할 수 있었다. - CVSS 4.3. - 17.6 이후의 19.0.6, 19.1.4, 19.2.2 이전 버전이 영향을 받는다. 자체 관리형 GitLab 운영자는 사용 중인 메이저·마이너 버전에 맞춰 19.0.6, 19.1.4 또는 19.2.2로 즉시 업그레이드하고, 업그레이드 전후에 보호 브랜치·프로젝트 설정·API 접근 권한을 점검하는 것이 좋다.

cloudflare

WriteGuard: MCP 서버를 위한 세밀한 제어 (새 탭에서 열림)

AI 에이전트가 외부 시스템에 쓰기 권한을 가지면, 잘못된 프롬프트 하나만으로 사람의 작업 속도를 훨씬 뛰어넘는 대규모 변경을 일으킬 수 있다. Cloudflare는 에이전트별 설정이나 사용자의 감시에 의존하지 않고, MCP 도구 호출을 중앙에서 정책 적용·식별·감사하기 위해 WriteGuard를 구축했다. WriteGuard는 인간 사용자의 권한은 유지하면서 에이전트 세션을 별도로 추적하고, 위험도에 따라 작업을 허용·기록·차단한다. ## MCP의 구조와 에이전트 동작 방식 - MCP(Model Context Protocol)는 AI 애플리케이션이 외부 도구와 데이터에 연결되도록 하는 표준이다. - MCP 서버는 다음 요소를 가진 도구를 제공한다. - 도구 이름 - 설명 - 입력 스키마 - 실제 작업을 수행하는 핸들러 - 에이전트가 도구를 선택하면 MCP 클라이언트가 서버에 호출을 보내고, 서버가 Jira·GitLab·데이터베이스 등 downstream 시스템과 상호작용한다. - 따라서 도구에 쓰기 권한이 부여되면 에이전트가 외부 시스템의 상태를 직접 변경할 수 있다. ## 무제한 쓰기 권한의 위험 - 잘못 작성된 정리 작업 프롬프트가 수천 개의 티켓을 자동으로 닫을 수 있다. - 사람이 직접 수행한 작업과 에이전트가 수행한 작업이 동일한 사용자 계정으로 기록되면 원인 분석과 복구가 어려워진다. - 여러 에이전트 세션이 동시에 실행되면 네트워크 로그만으로 특정 세션을 식별하기 어렵다. - 위험한 사례는 다음과 같다. - 계약 소프트웨어의 계약 내용 변경 - 고객지원 큐에 대량 답변 전송 - 데이터베이스 테이블 전체 삭제 - Cloudflare는 모든 사용자가 에이전트를 완벽하게 설정하거나 모든 도구 호출을 감시할 수 없다고 판단했다. ## Cloudflare의 MCP 확장 - Cloudflare의 내부 에이전트는 OpenCode, Cloudflare OS, 장기 실행 에이전트 서비스 등을 통해 MCP를 사용한다. - 내부 MCP 포털이 여러 서버를 통합하며, 연결된 서버 수는 13개에서 27개로 증가했다. - 초기에는 Jira, GitLab, 위키, 운영 시스템 등을 조회하는 읽기 전용 서버로 시작했다. - 이후 엔지니어링·제품·디자인·영업·고객 성공팀에서 실제 변경 작업을 수행하는 도구를 요구했다. - 클라이언트의 skill이나 elicitation prompt만으로는 통제가 어렵기 때문에 중앙 정책 계층인 WriteGuard를 도입했다. ## WriteGuard의 역할 - WriteGuard는 MCP 서버와 도구 호출 사이에 위치하는 공통 계층이다. - 도구 설정과 요청 컨텍스트를 바탕으로 호출을 다음과 같이 처리한다. - 호출을 그대로 통과 - 에이전트 식별 정보를 추가한 뒤 통과 - 감사 이벤트를 생성 - 핸들러 실행 전에 호출 차단 - WriteGuard는 다음 기능을 하나의 장소에서 제공한다. - 도구별 정책 관리 - 사용자 및 에이전트 신원 연결 - downstream 시스템에 에이전트 정보 표시 - 중앙 감사 로그 수집 ## 도구 위험도 기반 정책 각 도구에는 위험도, 활성화 여부, 라벨링 설정을 지정한다. - **Read Only** - 이슈 검색 - Merge Request 조회 - 파이프라인 상태 확인 - **Minimal Impact** - 리액션 추가 - 알림을 읽음으로 표시 - 이슈 구독 - **Contained Write** - 댓글 작성 - Merge Request 생성 - 이슈 필드 수정 - **Critical** - Merge Request 병합 - 운영 환경 배포 실행 - 레코드 일괄 삭제 위험도는 감사 로그 기록 여부와 호출 허용 여부를 결정하며, 위험도별로 로그를 검색할 수 있다. 또한 서버 코드를 수정하지 않고도 특정 입력 필드에 일반 텍스트나 HTML 형식의 에이전트 라벨을 삽입할 수 있다. ## 사람의 권한을 유지하고 에이전트만 식별 - 내부 MCP 서버는 Cloudflare Access와 OAuth로 사용자를 인증한다. - 에이전트는 별도 계정이 아니라 사용자의 권한을 그대로 사용한다. - 따라서 Joe가 특정 이슈를 닫을 수 없다면 Joe의 에이전트도 닫을 수 없다. - 별도 에이전트 계정을 만들지 않은 이유는 다음과 같다. - 관리해야 할 권한 체계가 추가됨 - 에이전트와 책임자인 사람의 연결이 약해짐 - 대신 WriteGuard는 사용자 신원에 MCP 클라이언트와 세션 정보를 추가한다. - downstream 애플리케이션에는 사람의 권한으로 수행된 작업이라는 정보와 함께, 어떤 에이전트 세션이 작업했는지 표시할 수 있다. ## 중앙 감사 로그와 대규모 활동 분석 - WriteGuard는 각 도구 호출을 성공, 실패, 차단으로 분류한다. - 이후 감사 이벤트를 비동기적으로 내부 audit Worker에 전송한다. - 감사 이벤트에는 다음 정보가 포함된다. - MCP 서버 - 도구 이름 - 위험도 - 호출 결과 - 사용자 - 클라이언트 - 실행 시간 - 비밀번호나 민감한 값으로 분류된 입력 키의 값은 제거한다. - 비동기 로깅을 사용하므로 에이전트가 응답을 기다리는 시간에는 추가 지연이 없다. - MCP 포털 로그가 개별 호출을 보여준다면, WriteGuard 로그는 도구의 의미적 분류·에이전트 컨텍스트·백엔드 처리 결과를 함께 제공한다. - 이를 통해 특정 시스템 하나가 아니라 전체 MCP 환경에서 에이전트의 대량 활동을 검색하고 조사할 수 있다. ## GitLab 적용 방식 - 글에서는 GitLab MCP 서버의 세 도구를 예로 든다. - `get_merge_request`: Merge Request 읽기 - `create_mr_note`: 댓글 또는 노트 작성 - `merge_mr`: Merge Request 병합 - 이 도구들은 각각 읽기, 제한적 쓰기, 중요 쓰기 등 서로 다른 위험도 정책을 적용할 수 있다. - 이를 통해 동일한 GitLab 서버 안에서도 조회는 허용하되 댓글 작성이나 병합은 별도로 기록하거나 차단하는 식의 세밀한 통제가 가능하다. ## 실용적인 결론 MCP 서버에 쓰기 권한을 추가할 때는 단순한 사용자 인증만으로는 부족하다. 도구별 위험도 정책, 에이전트 세션 식별, 민감정보 제거 감사 로그, 사전 차단 기능을 중앙 계층에서 제공해야 하며, 특히 대량 변경이 가능한 작업은 높은 위험도로 분류해 별도 통제하는 것이 안전하다.

gitlab

Claude와 GitLab으로 모든 커밋을 프로덕션까지 안전하게 배포하세요 (새 탭에서 열림)

Claude은 코딩 세션 중 취약점을 발견하고 수정하는 데 유용하지만, 커밋 이후의 병합·의존성·인프라 변경·감사까지 대체할 수는 없다. 글은 Claude Security와 GitLab을 연계해 작성 단계부터 프로덕션 배포까지 보안 검사를 지속하고, 정책을 강제하며, 감사 증거를 자동으로 남기는 방식을 제안한다. Claude가 작성 시점을 담당하고 GitLab이 이후 전체 소프트웨어 공급망을 관리하는 구조다. ## 세션 내 보안 점검에서 강제 가능한 정책으로 - Claude 보안 가이던스 플러그인은 개발자의 코딩 세션 안에서 취약점을 빠르게 찾아 수정하도록 돕는다. - 코드가 세션 밖으로 나간 뒤에는 보안팀이 어떤 검사가 수행됐는지 확인하고 후속 작업을 통제해야 한다. - GitLab 보안 구성 프로필을 사용하면 저장소 외부에서 필요한 스캔을 정의하고 여러 프로젝트와 파이프라인에 일괄 적용할 수 있다. - 병합 요청 승인 정책으로 변경을 작성한 에이전트나 해당 에이전트를 사용한 개발자가 자신의 코드를 직접 승인·병합하지 못하게 할 수 있다. - 해결되지 않은 치명적 취약점이 있는 병합 요청은 지정된 승인자가 승인할 때까지 차단된다. - 취약점 보고서와 보안 대시보드에서 각 취약점이 발견·무시·해결된 상태와 사유를 추적할 수 있다. ## 자동화된 감사 증거와 변경 이력 - SOC 2, PCI DSS, FedRAMP 같은 규정은 에이전트가 작성한 변경도 테스트·검토·승인됐다는 증거를 요구한다. - GitLab은 모든 병합 요청에서 스캔이 실행되도록 보장하고, 결과를 병합 요청과 취약점 보고서에 표시한다. - 파이프라인 로그, 승인 기록, 감사 이벤트를 통해 어떤 변경을 누가 또는 어떤 에이전트가 처리했는지 재현할 수 있다. - 규정 프레임워크별 요구사항에 보안 통제를 매핑할 수 있으며, 각 통제의 통과·대기·실패 상태를 보고서에서 확인할 수 있다. ## 모델로 전송되는 민감 데이터 통제 - 컨텍스트 제외 기능으로 인증 정보, 민감한 파일, 독점 로직, 규제 데이터를 모델에 보내지 않도록 설정할 수 있다. - 자체 관리 환경과 자체 호스팅 모델을 사용하면 코드와 추론 데이터를 조직 경계 안에 둘 수 있다. - 흐름별 허용 모델을 지정하고, 코드가 모델 학습에 사용되지 않도록 제한할 수 있다. - GitLab Duo의 프롬프트 가드레일은 모델에 전달되기 전 코드 제안에서 비밀정보를 탐지한다. - 프롬프트가 접근할 수 있는 콘텐츠를 제한해 프롬프트 인젝션 위험도 줄인다. ## 세션 단위 검사를 넘어선 전체 생명주기 보안 - 세션 기반 검사는 해당 시점의 코드만 다루므로, 이후 공개되는 의존성 취약점이나 이미 커밋된 비밀정보까지 발견하지 못할 수 있다. - GitLab은 다음 영역을 독립적으로 검사한다. - 의존성 취약점 - 컨테이너 이미지 - 인프라스트럭처 코드 - 비밀정보 유출 - 실행 중 애플리케이션에 대한 DAST - 결정론적 스캐너는 동일 코드에 대해 일관된 결과와 CWE 매핑을 제공해 감사에 적합하다. - 반면 비즈니스 로직 오류, 잘못된 권한 검사, 경쟁 조건처럼 일반 스캐너가 놓치기 쉬운 문제는 Security Review Flow가 코드의 의도를 분석해 보완한다. - 글은 Claude의 보안 검사를 인간 코드 리뷰와 다양한 보안 스캐너를 대체하는 수단이 아니라 보조 수단으로 규정한다. ## 사람과 에이전트에 동일한 보안 가드레일 적용 - Claude 플러그인은 Claude가 세션에서 작성·커밋한 코드에 집중한다. - 개발자가 셸에서 직접 작성하거나 세션 내 `!` 셸 이스케이프를 통해 실행한 변경은 플러그인 검토 범위를 벗어날 수 있다. - Claude Security는 개발자나 관리자가 필요할 때 전체 코드베이스 또는 사람이 작성한 코드도 검사할 수 있다. - GitLab의 스캔 실행 정책과 병합 승인 정책은 파이프라인에서 모든 변경에 적용된다. - 따라서 코드 작성자가 사람인지 에이전트인지, 개발자가 별도로 검사를 실행했는지에 관계없이 동일한 통제를 적용할 수 있다. ## 프로덕션에 도달하는 변경 통제 - Claude Security와 GitLab MCP 서버를 연결하면 기존 Claude 기반 개발 흐름을 유지하면서 GitLab의 정책·스캔·감사 기능을 활용할 수 있다. - 모든 기본 브랜치와 대상 프로젝트에 보안 스캔을 강제해 정책 우회를 어렵게 만든다. - 치명적 취약점, 미승인 변경, 누락된 검사 결과가 있는 코드는 배포 전에 차단할 수 있다. - 결과적으로 세션 안의 빠른 AI 보안 지원과 프로덕션 배포 전의 조직 차원 거버넌스를 하나의 흐름으로 결합한다. 실무에서는 Claude를 개발 중 취약점 탐지와 수정에 활용하되, GitLab에서 SAST·의존성·컨테이너·IaC·비밀정보·DAST 스캔과 승인 정책을 중앙 관리하는 구성이 권장된다. 특히 모델에 전송되는 파일을 사전에 제외하고, 에이전트와 사람 모두에게 동일한 승인·감사 규칙을 적용해야 한다.

gitlab

GitLab 패치 릴리스: 19.2.1, 19.1.3, 19.0.5 | GitLab 문서 (새 탭에서 열림)

2026년 7월 29일 GitLab은 CE/EE용 패치 버전 19.2.1, 19.1.3, 19.0.5를 출시했다. 이번 릴리스에는 다수의 보안 취약점과 버그 수정이 포함되어 있어, 영향을 받는 모든 자체 관리형 GitLab 설치 환경은 즉시 업그레이드하는 것이 권장된다. GitLab.com은 이미 패치가 적용됐으며, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 이번 패치 버전: - GitLab 19.2.1 - GitLab 19.1.3 - GitLab 19.0.5 - 대상: - GitLab Community Edition(CE) - GitLab Enterprise Edition(EE) - Omnibus, 소스 설치, Helm Chart 등 모든 배포 방식 - GitLab은 지원 중인 버전에서 최신 패치 릴리스를 유지할 것을 권장한다. - 일반 패치 릴리스는 매월 둘째·넷째 수요일에 제공되며, 심각도가 높은 취약점에는 별도 긴급 패치가 배포될 수 있다. - 보안 취약점의 상세 이슈는 패치된 릴리스 이후 90일이 지나면 공개된다. ## Workhorse 내부 요청 처리의 정보 노출 - **CVE-2026-6267** - 인증된 Developer 권한 사용자가 내부 요청 처리 과정의 접근 제어 미흡을 악용해 권한 없는 정보에 접근할 수 있었다. - CVSS 점수는 **8.5**로, 이번 릴리스에서 가장 심각한 취약점 중 하나다. - GitLab CE/EE의 10.1.0 이후 버전이 영향을 받으며, 19.0.5·19.1.3·19.2.1에서 수정됐다. ## Pipeline Schedule API의 대량 할당 취약점 - **CVE-2026-12436** - 파이프라인 스케줄 입력값 검증이 충분하지 않아, 인증된 사용자가 다른 사용자의 CI/CD 설정을 변경할 수 있었다. - CVSS 점수는 **8.4**다. - GitLab 18.0 이상 버전과 19.x의 이전 패치 버전이 영향을 받는다. ## Merge Request Discussions 기반 서비스 거부 - **CVE-2026-15975** - Merge Request 토론 처리 시 리소스 제한이 부족해, 인증되지 않은 공격자가 서비스 거부(DoS)를 일으킬 수 있었다. - CVSS 점수는 **7.5**다. - 11.8 이후 버전부터 수정 버전 이전의 19.0, 19.1, 19.2 계열이 영향을 받는다. ## Merge Request 승인 규칙 우회 - **CVE-2026-13113** - GitLab EE에서 승인 규칙 처리 중 발생하는 경쟁 조건(race condition)을 통해, 필요한 승인 없이 보호 브랜치에 코드를 병합할 수 있었다. - CVSS 점수는 **6.5**다. - 인증된 사용자가 공격을 수행할 수 있으며, 보호 브랜치와 승인 정책을 사용하는 조직에 특히 중요하다. ## Virtual Registries의 자격 증명 보호 미흡 - **CVE-2026-16553** - Virtual Registry가 업스트림 요청을 처리하는 과정에서 민감한 정보가 의도하지 않은 호스트로 전달될 수 있었다. - GitLab EE 18.8 이상 및 19.x의 이전 패치 버전이 영향을 받는다. - CVSS 점수는 **5.4**다. ## 프로젝트 가져오기 기능의 권한 검증 문제 - **CVE-2026-6336** - 프로젝트 가져오기 상태에서 인증되지 않은 사용자가 프로젝트 소스 정보를 확인할 수 있었다. - CVSS 점수는 **5.3**이다. - **CVE-2026-14341** - Maintainer 권한 사용자가 프로젝트 API의 권한 검증 미흡을 악용해 보호 브랜치 설정을 변경할 수 있었다. - CVSS 점수는 **4.9**다. ## 페이지네이션 화면의 XSS - **CVE-2026-3093** - 사용자 입력값이 충분히 정제되지 않아, 조작된 URL을 통해 다른 사용자의 브라우저에서 임의 JavaScript를 실행할 수 있었다. - CVSS 점수는 **4.7**이다. - 사용자가 악성 링크를 열어야 하는 조건이 포함되지만, 웹 인터페이스를 사용하는 환경에서는 패치가 필요하다. ## GitLab Duo 기능의 권한 우회 - **CVE-2026-15077** - Duo Code Review가 신뢰할 수 없는 콘텐츠를 처리하는 과정에서 프롬프트 인젝션이 발생할 수 있었다. - 공격자가 권한 없는 프로젝트의 정보에 접근할 가능성이 있었다. - GitLab EE 19.1 및 19.2의 초기 버전에 영향을 주며, CVSS 점수는 **4.3**이다. - **CVE-2026-15831** - Duo Workflows의 보안 토큰 생성 과정에서 권한 적용이 잘못되어, 관리자가 설정한 도구 거버넌스 정책을 우회할 수 있었다. - CVSS 점수는 **4.3**이다. ## 권장 대응 - 자체 관리형 GitLab은 사용 중인 메이저 버전에 맞춰 **19.0.5, 19.1.3 또는 19.2.1 이상**으로 즉시 업그레이드한다. - GitLab EE에서 보호 브랜치, Merge Request 승인 규칙, Virtual Registries, Duo 기능을 사용하는 경우 우선적으로 점검한다. - 업그레이드 전 백업과 운영 환경 검증을 수행하되, 보안 패치 적용을 불필요하게 지연하지 않는 것이 좋다.

gitlab

Cursor와 GitLab으로 Java 현대화하기 (새 탭에서 열림)

Java 8에서 21로의 현대화는 단순한 버전 업그레이드가 아니라 빌드·런타임·의존성·API·동시성·테스트·컨테이너·운영 동작을 함께 다루는 복합 작업이다. 따라서 Cursor로 모든 변경을 한 번에 수행하기보다, 작은 문제를 단계적으로 해결하고 GitLab의 이슈 계층, CI/CD, 보안 검사, 코드 리뷰, 영향 분석으로 안전성을 검증해야 한다. 글은 실패한 테스트 수정에서 시작해 품질 게이트를 마련하고, 특정 HTTP 연결 경계를 Java 21 방식으로 현대화하는 흐름을 제시한다. ## Cursor와 GitLab의 역할 분담 - Cursor는 코드베이스 안에서 다음과 같은 집중 작업에 적합하다. - 실패한 테스트의 원인 추적 - 구현 코드와 테스트 분석 - 제한된 범위의 수정안 작성 - 로컬 테스트 실행 - 브랜치와 머지 리퀘스트 생성 - GitLab은 AI가 만든 변경을 소프트웨어 개발 생명주기 안에서 검증하는 역할을 한다. - Epic과 하위 이슈로 현대화 계획을 지속적이고 검토 가능하게 관리 - GitLab MCP 서버로 이슈, 논의, 파이프라인, 의존성 등 프로젝트 문맥을 Cursor에 제공 - CI/CD, 보안 스캔, 코드 리뷰, 코드 소유자 승인, 영향 분석 수행 - Duo Agent Platform의 Code Review Flow와 Developer Flow로 프로젝트별 품질 기준 적용 - AI 에이전트의 속도 자체가 안전성을 보장하지 않으므로, 모든 에이전트 생성 머지 리퀘스트도 일반 변경과 동일한 검증 절차를 거쳐야 한다. ## 예제 시스템과 현대화 범위 - 대상은 Tanuki IoT Platform의 Java HTTP metrics collector다. - 이 컴포넌트는 다음 작업을 수행한다. - 상태 점검 및 유지보수 HTTP 엔드포인트에 `GET` 요청 - 응답 상태와 응답 시간 등의 메트릭 기록 - Rust 기반 metrics-store 백엔드에 `POST /api/metrics` 요청 - 백엔드의 HTTP 응답을 확인 - Java 애플리케이션과 Rust 백엔드 사이의 실제 HTTP 계약이 존재하므로, Java 런타임 현대화가 운영 경계에 미치는 영향을 테스트할 수 있다. - 환경에는 Java 8과 Java 21, Maven, Docker, Docker Compose, GitLab MCP 서버가 필요하다. - 저장소의 `AGENTS.md`에는 프로젝트 구조와 Maven 테스트 명령이 있어 Cursor가 로컬 개발 규칙을 따르는 데 활용된다. ## 실패한 엔드투엔드 테스트 수정 - 문제는 엔드포인트의 기대 HTTP 상태 코드 처리에서 발생한다. - 사용자는 특정 상태 코드를 기대하도록 설정할 수 있다. - 구현은 모든 `2xx` 응답만 성공으로 간주한다. - 따라서 `503`을 정상적인 기대값으로 설정해도 테스트가 실패한다. - 엔드투엔드 테스트는 이미 문제를 드러내고 있었지만 CI/CD 작업이 `allow_failure` 상태여서 실패가 지속적인 경고음으로만 남아 있었다. - Cursor에는 관찰 가능한 문제를 직접 설명하고 다음 순서로 작업하도록 요청한다. - 먼저 분석 작성 - 구현과 실패 테스트 추적 - 수정 적용 - 테스트 재실행 - Cursor는 엔드포인트 설정에서 `HttpCollector`와 실패한 엔드투엔드 테스트까지 경로를 추적해 불일치의 원인을 찾는다. - 집중 테스트와 전체 Maven 테스트가 통과한 뒤 브랜치와 머지 리퀘스트를 만든다. - 테스트가 결정적이고 안정적으로 통과하면, 기존에 실패를 허용하던 엔드투엔드 작업을 필수 검증 단계로 전환할 수 있다. ## 머지 리퀘스트 기반 검증 - 머지 리퀘스트 생성 후 자동으로 다음 검증이 실행된다. - 빌드 - 단위 및 통합 테스트 - 엔드투엔드 테스트 - 보안 스캔 - GitLab Duo Code Review는 프로젝트의 Java 전용 리뷰 지침에 따라 변경을 검토한다. - 리뷰에서 구체적인 문제가 발견되면 Developer Flow를 통해 수정한 뒤 병합한다. - 머지 리퀘스트는 단순한 결과물 제출 수단이 아니라 다음을 수행하는 협업·의사결정 공간이다. - 변경 의도 설명 - 테스트 및 파이프라인 결과 확인 - 리뷰 의견 처리 - 에이전트가 만든 코드의 품질 증거 축적 - 이 단계에서 실제 버그를 런타임 마이그레이션과 섞지 않고 먼저 수정함으로써, 이후 현대화 작업의 행동 기준선과 회귀 방지 테스트를 확보한다. ## Java 8에서 Java 21로 넘어가기 위한 품질 게이트 - Java 21 현대화는 앞선 테스트 버그 수정과 달리 훨씬 넓은 범위를 가진다. - 기존 Java modernization epic에는 다음과 같은 계획 문맥이 포함되어 있다. - 하위 작업 항목 - 팀 논의 - 조사 결과와 관련 머지 리퀘스트 - 과거 파이프라인 기록 - 의존성 정보 - 보안 취약점 및 관련 발견 사항 - 이러한 정보를 Cursor에 제공하면 단순히 소스 코드를 바꾸는 것이 아니라 프로젝트의 개발 이력과 운영 제약을 반영한 변경 계획을 세울 수 있다. - 글의 접근 방식은 전체 마이그레이션을 한 번에 수행하지 않고, 먼저 품질 게이트를 마련한 뒤 영향 범위가 명확한 경계부터 현대화하는 것이다. ## 실용적인 적용 순서 - 먼저 하나의 실패한 테스트나 제한된 버그를 선택한다. - Cursor로 원인 분석, 수정, 테스트 실행을 수행한다. - 변경을 작은 머지 리퀘스트로 제출하고 CI/CD와 자동 리뷰를 통과시킨다. - 그다음 Epic과 이슈, MCP를 통해 Java 21 마이그레이션의 전체 문맥을 연결한다. - 모든 테스트, 보안 검사, 코드 소유자 승인, 영향 분석 결과를 품질 게이트로 사용한다. - 마지막으로 HTTP 연결 처리처럼 하나의 경계를 골라 현대화하고, Java 애플리케이션과 Rust 백엔드 사이의 실제 계약이 유지되는지 검증하는 것이 안전하다.

gitlab

GitLab 19.2 릴리스 노트 | GitLab Docs (새 탭에서 열림)

GitLab 19.2는 GitLab Duo와 AI 에이전트 기능을 중심으로 개발·보안·운영 자동화를 강화한 릴리스입니다. Duo CLI와 커스텀 플로우가 정식 출시되었고, 정책 기반 예약 파이프라인과 Agentic Chat 연동이 추가되었습니다. 또한 의존성 취약점 자동 수정, 비기본 브랜치 취약점 추적, 하위 그룹 단위의 Duo 접근 제어가 베타 또는 정식 기능으로 제공됩니다. ## GitLab Duo CLI 정식 출시 - 터미널에서 GitLab Duo Agent Platform을 사용할 수 있습니다. - 코드베이스에 대한 복잡한 질문을 하거나 변경 작업을 자율적으로 수행하도록 요청할 수 있습니다. - 외부 AI 도구와 달리 GitLab 프로젝트, 파이프라인, 에이전트 설정을 문맥으로 활용합니다. - 주요 기능: - 대화형 모드와 CI/CD용 헤드리스 모드 - 모델 선택 및 세션 공유 - 도구 실행 승인 - MCP(Model Context Protocol) 연결 - 슬래시 명령어와 컨텍스트 사용량·압축 관리 - `AGENTS.md`와 스킬을 활용한 사용자 정의 - `glab`을 통해 설치하거나 독립 실행형 도구로 설치할 수 있습니다. - GitLab Self-Managed와 Dedicated에서는 관리자가 기능을 켜거나 끌 수 있습니다. ## GitLab Duo 커스텀 플로우 정식 출시 - 여러 단계로 구성된 AI 기반 작업 흐름을 YAML로 정의하고 재사용할 수 있습니다. - GitLab 이벤트에 따라 반복적인 개발·운영 작업을 자동 실행합니다. - 주요 기능: - 팀별 YAML 워크플로 - 복잡한 작업을 위한 멀티 에이전트 오케스트레이션 - 승인이나 피드백을 받는 HITL(Human-in-the-loop) 체크포인트 - 멘션, 담당자 지정, 파이프라인, 머지 리퀘스트 이벤트 트리거 - 프로젝트 또는 AI Catalog에서 플로우 생성·관리 - 공개·비공개 가시성 설정 - 서비스 계정과 복합 ID를 이용한 보안 실행 - 실행 전 YAML 검증 - GitLab CI/CD 안에서 실행되므로 별도 외부 자동화 플랫폼 없이 운영할 수 있습니다. ## 예약 파이프라인 실행 정책 정식 출시 - 보안 정책 프로젝트에서 일정을 한 번 정의하면 범위 내 여러 프로젝트에 강제 적용할 수 있습니다. - 각 프로젝트의 `.gitlab-ci.yml`을 직접 수정하지 않아도 됩니다. - 커밋 활동과 무관하게 일·주·월 단위로 다음 작업을 실행할 수 있습니다. - 컴플라이언스 검사 - 보안 스캔 - 의존성 취약점 점검 - 각 정책은 별도 파이프라인으로 실행됩니다. - 시간대, 실행 시간 분산 범위, 대상 브랜치를 설정할 수 있습니다. - 코드 변경이 드문 저장소에서도 새롭게 발견된 취약점을 주기적으로 탐지하는 데 유용합니다. ## Agentic Chat에서 기본 플로우 시작 - 기존에는 특정 UI 동작, 멘션, 담당자 지정 등을 통해 시작하던 기본 플로우를 Agentic Chat 대화 중에도 실행할 수 있습니다. - 요청 내용에 맞춰 전문 플로우로 넘길 수 있습니다. - Developer Flow: 코드 변경 또는 머지 리퀘스트 생성 - Code Review Flow: 머지 리퀘스트 검토 - Fix CI/CD Pipeline Flow: 실패한 파이프라인 진단 및 수정 - 사용자가 채팅에서 전환을 승인한 뒤, 대화창이나 **AI > Sessions**에서 진행 상황을 확인합니다. ## 의존성 스캔 자동 수정 베타 - 취약한 의존성을 자동으로 수정하는 두 가지 기능이 추가되었습니다. - 자동 의존성 버전 업데이트: - 취약한 의존성을 안전한 버전으로 올리는 머지 리퀘스트를 자동 생성합니다. - 기본적으로 패치 및 마이너 버전 업데이트를 대상으로 합니다. - Agentic Breaking Change Resolution: - 의존성 업데이트 후 파이프라인이 주요 변경 사항으로 실패하면 GitLab Duo가 원인을 분석합니다. - 파이프라인 오류, 의존성 변경 로그, 프로젝트의 실제 사용 방식을 함께 검토합니다. - 같은 머지 리퀘스트에 수정 사항을 커밋하고 파이프라인을 통과할 때까지 재실행합니다. - 활성화하면 메이저 버전 업데이트도 대상에 포함됩니다. - GitLab Credits를 사용합니다. - 결과적으로 GitLab이 수정 머지 리퀘스트를 생성하고, Duo가 복잡한 호환성 문제까지 해결하는 자동화된 보안 수정 흐름을 제공합니다. ## 비기본 브랜치 취약점 추적 베타 - 기본 브랜치 외에도 장기 유지되는 릴리스·배포 브랜치의 취약점을 추적할 수 있습니다. - 예시는 다음과 같습니다. - `project-qa` - `project-prod` - `project-iOS` - `project-android` - 보안 설정에서 추적 브랜치를 추가할 수 있으며, 네임스페이스 프로젝트 수의 최대 두 배까지 등록할 수 있습니다. - 취약점 보고서와 프로젝트 보안 대시보드에서 브랜치별 필터링을 지원합니다. - CVE를 포함한 모든 취약점 유형을 추적합니다. - 브랜치가 기본 브랜치에 병합될 때 취약점 상태 메타데이터를 일관되게 유지합니다. - 추적 브랜치의 취약점 상태도 갱신할 수 있습니다. - 사용 브랜치는 너무 많이 지정하기보다 환경별·플랫폼별 장기 브랜치로 제한하는 것이 권장됩니다. ## 하위 그룹별 GitLab Duo 접근 제어 - GitLab Dedicated 및 Dedicated for Government 관리자는 특정 하위 그룹에서 Duo와 Duo Agent Platform을 제한할 수 있습니다. - 기존에는 전체 인스턴스에서 비활성화하거나 모든 그룹에서 사용 가능하게 하는 방식만 제공되었습니다. - 이제 하위 그룹별 기본 거부(default-deny) 및 허용 목록(allowlist) 정책을 적용할 수 있습니다. - 특정 그룹을 **Always off**로 잠그면 하위 그룹과 프로젝트에서도 기능을 활성화할 수 없습니다. - 다른 그룹은 Owner 권한 사용자의 선택에 맡길 수 있습니다. - 잠금 설정과 해제는 관리자만 수행할 수 있으며, 영향을 받는 Owner에게는 상위 그룹 정책으로 기능이 잠겼다는 안내가 표시됩니다. - 조직의 규정 준수와 AI 기능 사용 범위에 대한 플랫폼 거버넌스를 세밀하게 관리할 수 있습니다. ## 실용적인 적용 방향 - 개발팀은 Duo CLI와 Agentic Chat을 코드 작성, 코드 리뷰, 실패한 파이프라인 수정에 활용할 수 있습니다. - 보안팀은 예약 파이프라인 정책과 의존성 자동 수정으로 지속적인 취약점 대응 체계를 구성할 수 있습니다. - 릴리스 브랜치를 운영하는 조직은 비기본 브랜치 추적을 제한적으로 적용하는 것이 좋습니다. - 규제 환경에서는 하위 그룹별 Duo 허용 정책을 사용해 AI 기능을 조직 단위로 통제하는 것이 적합합니다.

gitlab

버전 업으로 빌드가 깨졌을 때 GitLab이 해결해 줍니다 (새 탭에서 열림)

GitLab의 Dependency Scanning Auto-Remediation은 취약한 의존성을 자동으로 업그레이드하고, 버전 변경으로 빌드가 깨지면 AI가 코드까지 수정하는 기능이다. 수정 사항은 동일한 머지 리퀘스트에서 검토되며, 기존 승인 절차와 감사 기록을 그대로 따른다. 이를 통해 개발자가 보안 취약점 수정에 직접 많은 시간을 쓰지 않고도 컴플라이언스 기한 내에 대응할 수 있다는 것이 글의 결론이다. ## 의존성 보안 백로그가 증가하는 이유 - 취약하거나 오래된 외부 컴포넌트는 OWASP Top 10에 포함되는 대표적인 위험 요소다. - Maven 생태계 조사에 따르면 최신 릴리스에 유입되는 취약점의 약 63%가 직접 의존성이 아닌 전이적 의존성에서 발생했다. - 취약점 수정은 기능 개발과 경쟁하는 수작업이어서, 특히 PCI-DSS와 FedRAMP의 30일 기한을 넘기는 고위험 취약점이 생기기 쉽다. - 의존성 업데이트 8건 중 약 1건은 호환성이 깨지는 변경을 포함하며, “하위 호환”으로 표시된 업데이트도 실제 프로젝트의 빌드를 깨뜨릴 수 있다. - AI를 활용한 익스플로잇 개발과 무기화가 빨라지면서 취약점을 장기간 방치할 위험도 커지고 있다. ## 취약점 발견부터 수정까지 자동화 - SBOM 기반 의존성 스캐닝이 수정 가능한 취약점을 발견하면, GitLab이 가장 가까운 안전 버전으로 올리는 머지 리퀘스트를 자동 생성한다. - 적절한 수정 버전이 없으면 무리하게 변경하지 않고 취약점을 보고서에 유지한다. - 자동 생성된 머지 리퀘스트는 전용 서비스 계정으로 작성되어 변경 주체를 추적할 수 있다. - 취약점의 심각도, 허용할 업데이트 범위(패치·마이너·메이저)를 설정할 수 있다. - 특정 취약점에 대해서는 취약점 보고서에서 사용자가 직접 자동 수정을 실행할 수도 있다. ## AI 기반 breaking change 해결 - 버전 업그레이드 후 파이프라인이 실패하면 GitLab Duo Agent Platform이 자동으로 원인을 분석한다. - 분석 대상에는 다음이 포함된다. - 파이프라인 오류 메시지 - 의존성의 변경 로그 - 프로젝트 코드에서 해당 의존성을 사용하는 방식 - AI는 같은 머지 리퀘스트 안에서 필요한 애플리케이션 코드 수정 커밋을 추가한다. - 수정 후에도 파이프라인이 통과하지 않으면 자동으로 중단하고, 분석 결과를 머지 리퀘스트에 남겨 개발자가 이어서 처리할 수 있게 한다. - 지원 생태계는 Bundler, Maven, Gradle, 주요 Python 및 JavaScript/TypeScript 패키지 관리자이며, Rust와 Go 지원도 예정되어 있다. ## 검토와 감사 절차를 유지하는 자동화 - 자동 수정은 절대로 자체적으로 병합되지 않는다. - 모든 변경은 기존 리뷰어 승인과 브랜치 보호 규칙을 거친다. - 머지 리퀘스트에는 다음 정보가 명시된다. - 어떤 취약점을 해결하는지 - 어떤 버전으로 업데이트하는지 - 빌드를 통과시키기 위해 AI가 제안한 코드 변경 - 변경 내용, 승인자, 승인 과정이 감사 기록으로 남아 보안 및 규제 대응에 활용할 수 있다. - 자동화는 조직 자체의 파이프라인에서 실행되므로 기존 접근 제어와 승인 게이트를 상속한다. ## 자동화 폭주를 막는 안전장치 - 쿨다운 기간을 설정해 모든 파이프라인마다 새로운 수정 작업이 생성되는 것을 방지한다. - 닫힌 머지 리퀘스트는 더 최신 수정 버전이 등장하지 않는 한 다시 만들지 않는다. - 프로젝트 또는 그룹 단위 구성 프로필로 조직의 위험 허용 수준에 맞게 정책을 관리할 수 있다. - 기능은 현재 퍼블릭 베타이며 GitLab.com에서 제공되고, GitLab Self-Managed와 Dedicated에도 순차적으로 적용된다. - 자동 버전 업데이트는 GitLab Ultimate에 추가 비용 없이 포함된다. AI 기반 breaking change 해결은 GitLab Duo Agent Platform의 무료 체험 또는 Ultimate에 포함된 GitLab Credits로 이용할 수 있다. ## 실용적인 적용 권장 사항 - 먼저 패치·마이너 업데이트만 허용해 자동화 범위를 제한하고, 안정화 후 메이저 업데이트로 확대하는 것이 안전하다. - AI가 작성한 코드도 반드시 일반 코드 리뷰와 테스트를 거쳐야 한다. - PCI-DSS나 FedRAMP처럼 기한이 명확한 환경에서는 고위험 취약점과 전이적 의존성을 우선 대상으로 삼는 것이 효과적이다.

gitlab

그린 DevOps: 탄소 측정이 CI/CD 파이프라인에 포함되어야 하는 이유 (새 탭에서 열림)

CI/CD 파이프라인은 매일 상당한 컴퓨팅 에너지와 탄소를 소비하지만, 일반적인 파이프라인 지표에는 그 영향이 드러나지 않는다. 글은 GitLab에 Eco CI와 Carmen을 연동해 파이프라인·인프라·애플리케이션 수준의 탄소 배출량을 측정해야 한다고 주장한다. 측정만으로도 불필요한 테스트 실행, 의존성 재설치, 유휴 서비스 같은 낭비를 찾아 비용과 탄소 배출을 함께 줄일 수 있다. ## CI/CD 파이프라인에 탄소 측정이 필요한 이유 - 현대적인 개발 파이프라인은 하루에도 수백 개의 작업을 실행한다. - AI 기반 테스트, 코드 리뷰, 자동화 작업이 늘면서 과거보다 실행 작업과 에너지 소비가 증가했다. - 파이프라인 로그나 아키텍처 다이어그램에는 컴퓨팅에 따른 탄소 배출량이 표시되지 않는 경우가 많다. - 배출량을 줄이려면 먼저 파이프라인 실행별, 서비스별, 팟(pod)별 배출량을 측정해야 한다. - Green DevOps는 탄소 데이터를 엔지니어링 의사결정에 활용하는 실천 방식이다. ## 파이프라인 수준의 측정: Eco CI - Eco CI는 CI/CD 작업별 에너지 소비량과 탄소 배출량을 측정한다. - 별도 서버나 데이터베이스 없이 가벼운 Bash 스크립트로 실행할 수 있다. - 각 작업의 배출량을 확인하고, 자원 사용량이 큰 작업과 시간에 따른 추세를 파악할 수 있다. - README에 탄소 배출량을 보여주는 배지를 추가할 수도 있다. - 기존 GitLab 파이프라인에 몇 줄을 추가하는 방식이므로 도입 난도가 낮다. - 파이프라인 자체가 이미 관측 대상이므로, 초기 Green DevOps 도구로 적합하다. ## 인프라와 애플리케이션 수준의 측정: Carmen - Carmen(Carbon Measurement Engine)은 Green Software Foundation의 Impact Framework를 기반으로 한다. - Kubernetes에서 실행되는 가상 머신, 팟, 개별 애플리케이션 워크로드까지 측정한다. - 컴포넌트별 CSV 보고서를 생성하며 다음 탄소를 구분한다. - 운영 탄소: 전력 사용으로 발생하는 배출량 - 내재 탄소: 하드웨어 제조와 폐기 과정에서 발생하는 배출량 - 주요 출력 필드는 다음과 같다. - `EnergykWh`: 에너지 소비량 - `TotalCarbonGramsCO2eq`: CO₂ 환산 총 배출량 - 생성된 데이터는 Grafana, FinOps 대시보드, 사내 분석 도구에 직접 연결할 수 있다. - “어떤 서비스가 가장 많은 CO₂를 배출하는가?”, “API 게이트웨이와 데이터 처리 계층 중 어디가 더 큰가?” 같은 질문에 답할 수 있다. ## GitLab 파이프라인에 연동하는 방법 - Eco CI와 Carmen 모두 `.gitlab-ci.yml`에 직접 추가할 수 있다. - Carmen 예시는 다음 작업을 수행한다. - `python:3.12` 이미지 사용 - Node.js, npm, Git, `lsb-release` 설치 - Carmen 저장소를 Git으로 복제 - Impact Framework 관련 npm 패키지 설치 - Carmen을 Python 패키지로 설치 - `carbon-daemon` 실행 - 생성된 결과를 GitLab artifact로 보관 - 결과 artifact는 예를 들어 1주일 동안 보관한 뒤 다운로드해 첫 탄소 보고서로 활용할 수 있다. - Carmen 작업을 별도의 비차단(non-blocking) 작업으로 구성하면 기존 배포 경로를 지연시키지 않는다. ## 측정으로 발견할 수 있는 낭비 - 한 팀은 Eco CI 도입 후 통합 테스트가 전체 파이프라인 배출량에서 예상보다 큰 비중을 차지한다는 사실을 발견했다. - 원인은 테스트 코드가 아니라 매 실행마다 모든 의존성을 처음부터 다시 설치하는 설정이었다. - 의존성 캐시를 추가하면 다음 효과를 동시에 얻을 수 있다. - 테스트 실행 시간 단축 - CI 탄소 배출량 감소 - 개발자 대기 시간 감소 - CI 비용 절감 - Carmen을 스테이징 클러스터에 적용한 결과, 폐기된 기능의 데이터 처리 서비스가 유휴 상태로 계속 실행되고 있었다. - 해당 서비스를 제거함으로써 불필요한 운영 탄소와 내재 탄소 소비를 줄일 수 있었다. - 두 사례 모두 대규모 지속가능성 프로젝트가 아니라, 데이터 가시성에서 출발한 개선이었다. ## 낮은 도입 비용과 실질적인 효과 - Eco CI는 몇 줄의 설정과 Bash 스크립트만으로 추가할 수 있다. - 별도 인프라를 구축하지 않으며 파이프라인에 의미 있는 지연을 추가하지 않는다. - Carmen 역시 독립적인 작업으로 실행할 수 있어 기존 핵심 경로에 영향을 주지 않는다. - 측정 데이터는 향후 탄소 보고와 규제 대응을 위한 조직의 기준선(baseline)이 된다. - 탄소 배출이 적은 코드는 대체로 더 빠르고 저렴하다. - 의존성 캐시, 러너 규모 조정(right-sizing), 불필요한 서비스 제거는 환경 개선이면서 동시에 FinOps 최적화이기도 하다. ## 규제와 기업 요구사항 변화 - 탄소 인식형 엔지니어링은 선택적 활동에서 전문적인 개발 관행으로 자리 잡고 있다. - EU의 기업 지속가능성 보고 지침(CSRD)은 대기업에 클라우드 사용량을 포함한 가치사슬 전반의 배출량 공개를 요구한다. - 기업 고객도 공급업체 선정 과정에서 지속가능성 정책과 배출량 관리 여부를 확인하는 경우가 늘고 있다. - 법적 의무가 생긴 뒤 시작하기보다, 지금부터 작은 범위에서 측정 기준과 내부 운영 습관을 마련하는 편이 유리하다. Eco CI를 단일 GitLab 파이프라인에 먼저 적용해 작업별 탄소 배출량을 확인하고, 이후 Carmen으로 Kubernetes와 서비스 수준까지 범위를 확장하는 접근이 현실적이다. 특히 의존성 캐시, 유휴 리소스 제거, 러너 크기 조정처럼 비용과 성능도 함께 개선하는 항목부터 실행하는 것이 효과적이다.

gitlab

GitLab 패치 릴리스: 19.1.2, 19.0.4, 18.11.7 | GitLab 문서 (새 탭에서 열림)

2026년 7월 8일 GitLab은 CE/EE용 패치 버전 19.1.2, 19.0.4, 18.11.7을 출시했다. 이번 릴리스는 XSS·HTML 인젝션·권한 우회·자격 증명 노출 등 여러 보안 취약점과 버그를 수정했으며, 자체 호스팅 사용자는 즉시 업그레이드하는 것이 권장된다. GitLab.com은 이미 패치가 적용됐고, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 패치 릴리스는 정기 릴리스와 고위험 취약점에 대응하는 비정기 긴급 패치로 나뉜다. - 정기 패치는 매월 둘째·넷째 수요일에 배포된다. - 영향을 받는 모든 자체 관리형 설치 환경은 Omnibus, 소스 코드, Helm Chart 등 배포 방식과 관계없이 최신 패치 버전으로 업그레이드해야 한다. - 보안 취약점 상세 이슈는 수정 버전 출시 후 90일이 지나면 공개된다. ## 취약점: XSS와 HTML 인젝션 - **CVE-2026-6896** - GitLab EE의 취약점 증거 테이블 렌더러에서 사용자 입력 sanitization이 충분하지 않았던 문제다. - Developer 권한의 인증 사용자가 다른 사용자의 브라우저 세션에서 임의 스크립트를 실행할 수 있었다. - CVSS 8.7로 이번 릴리스에서 가장 심각한 취약점 중 하나다. - EE 13.11 이후 버전 중 18.11.7, 19.0.4, 19.1.2 이전 버전에 영향을 준다. - **CVE-2026-13320** - CE/EE의 Wiki 마크업 렌더링 과정에서 HTML 인젝션이 가능했던 문제다. - 인증 사용자가 다른 사용자의 브라우저 세션에서 스크립트를 실행할 수 있었다. - CVSS 7.3이며, 높은 권한과 특정 조건이 필요하다. - CE/EE 15.7 이후 버전 중 각 패치 버전 이전 릴리스가 영향을 받는다. ## 자격 증명 및 저장소 보안 문제 - **CVE-2026-11827** - EE 저장소 미러링 기능의 권한 검사가 부족했다. - Maintainer 권한 사용자가 다른 사용자의 저장된 자격 증명을 획득할 수 있었다. - CVSS 4.9이며, EE 9.5 이후 버전에 영향을 준다. - **CVE-2025-12506** - Git 태그·브랜치 이름 해석이 모호하게 처리되는 문제다. - 공격자가 웹 인터페이스에 표시되는 저장소 내용과 다운로드 가능한 실제 내용이 다르게 보이는 저장소를 만들 수 있었다. - CE/EE 16.5 이후 버전에 영향을 주며 CVSS는 3.5다. ## 권한 검증 및 정보 노출 문제 - **CVE-2026-8472** - EE Work Items 기능에서 비공개 프로젝트의 메타데이터 접근 권한 검사가 누락됐다. - 최소 권한을 가진 인증 사용자가 비공개 프로젝트의 Work Item 정보를 읽을 수 있었다. - CVSS 4.3이다. - **CVE-2026-7492** - 커밋 토론 표시와 프로젝트 간 참조 페이지에서 권한 검사가 제대로 이뤄지지 않았다. - 비인증 사용자가 비공개 프로젝트의 존재 여부를 추론할 수 있었다. - CE/EE에 영향을 주며 CVSS는 4.3이다. - **CVE-2026-13151** - EE 그룹 수준 설정에 대한 권한 검사가 부정확했다. - 인증 사용자가 자신의 권한 범위를 넘어 그룹 설정을 수정할 수 있었다. - CVSS 2.7이며 GitLab 내부에서 발견됐다. - **CVE-2026-6352** - EE의 컴플라이언스 위반 관리 GraphQL 작업에서 권한 검사가 부족했다. - Auditor 수준 사용자가 컴플라이언스 위반 기록을 수정할 수 있었다. - CVSS 2.7이다. ## 버그 수정 및 기술 변경 ### 19.1.2 - OAuth 애플리케이션 등록 및 생성 시 `organization_id`를 설정하도록 수정했다. - 제약 조건 검증 전에 `oauth_applications`의 `NULL organization_id` 값을 보완하는 백필을 추가했다. - Go 버전을 1.25.11로 업데이트했다. - 멀티 아키텍처 태그를 레거시 레지스트리 경로에서 처리할 때 발생하던 HTTP 500 오류를 수정했다. - 외부 에이전트 흐름에서 커밋 작성자와 커미터의 신원을 사용하도록 개선했다. - ClickHouse 23.x에서 `ci_finished_builds` 엔진 교체가 동작하도록 수정했다. - Duo Workflow 이벤트 조회를 최신 체크포인트로 제한하고 커서 페이지네이션을 적용했다. - Developer가 작성한 Merge Request의 승인 규칙 재정의 회귀 문제를 수정했다. - 커밋 설명을 지나치게 미리 가져오면서 발생하던 커밋 페이지 메모리 누수를 해결했다. - 더 이상 필요하지 않은 `ActiveUserCountThresholdWorker` cron 스케줄을 제거했다. - 레지스트리 인증, OAuth 처리, 빌더 이미지 리비전 등 관련 구성도 백포트 및 조정했다. ### 19.0.4 및 18.11.7 - 19.0.4에도 OAuth 애플리케이션 등록 시 `organization_id`를 설정하는 수정이 백포트됐다. - CI_JOB_TOKEN을 이용한 레지스트리 인증 방식과 같은 일부 수정 사항이 19.0 안정화 브랜치에 반영됐다. - 18.11.7은 위 보안 취약점들이 수정된 18.11 계열의 권장 패치 버전이다. ## 실용적인 권장 사항 자체 호스팅 GitLab 운영자는 현재 지원 중인 계열에 맞춰 **19.1.2, 19.0.4, 18.11.7 중 하나로 즉시 업그레이드**하는 것이 좋다. 특히 EE에서 저장소 미러링, Work Items, 컴플라이언스 관리, 취약점 증거 렌더링을 사용하는 환경은 패치 적용 전까지 권한과 외부 입력 처리 기능을 우선 점검해야 한다.

gitlab

제한된 액세스로 GitLab 좌석을 관리하세요 (새 탭에서 열림)

GitLab의 **Restricted access**는 구매한 라이선스 좌석이 모두 사용된 뒤 새로운 과금 대상 사용자가 추가되는 것을 막아 좌석 초과와 예기치 않은 비용을 줄이는 기능입니다. SAML·SCIM·LDAP 기반 프로비저닝, OIDC/SSO 재로그인, 휴면 사용자 재활성화까지 처리 방식이 개선되어 자동화된 사용자 관리 환경에서도 더 안정적으로 사용할 수 있습니다. 다만 기존 초과 사용자를 자동으로 정리하지는 않으므로, 이미 발생한 초과분은 관리자가 별도로 해결해야 합니다. ## Restricted access의 역할 - GitLab.com과 Self-Managed에서 사용할 수 있는 좌석 제어 기능입니다. - 라이선스 좌석이 모두 소진되면 새로운 **과금 대상 사용자(billable user)** 추가를 차단합니다. - 좌석 초과를 사후에 되돌리는 기능이 아니라, 앞으로 발생할 추가 초과를 예방하는 기능입니다. - 프로젝트나 그룹 접근 없이 인증만 필요한 사용자는 **Minimal Access** 역할로 지정할 수 있습니다. - Minimal Access 사용자는 인증은 가능하지만 유료 좌석을 소비하지 않습니다. ## 기존 과금 사용자는 소급 적용되지 않음 - Restricted access를 이미 좌석 한도 초과 상태에서 활성화해도 기존 사용자는 영향을 받지 않습니다. - 기존 멤버가 자동으로 강등되거나 제거되거나 접근 차단되지 않습니다. - 관리자는 초과된 과금 사용자를 제거하거나 추가 좌석을 구매해 사용량을 한도 이내로 되돌려야 합니다. - 사용량이 한도 이내로 내려간 뒤부터 Restricted access가 추가적인 좌석 초과를 방지합니다. ## ID 프로바이더 기반 프로비저닝 개선 - 좌석이 없을 때 SAML, SCIM, LDAP로 프로비저닝된 사용자는 과금 역할로 바로 추가되지 않습니다. - 대신 자동으로 비과금 역할인 Minimal Access가 할당됩니다. - 중앙 집중식 계정 동기화를 유지하면서도 즉시 라이선스 초과가 발생하는 것을 막을 수 있습니다. - GitLab을 OIDC 프로바이더로 사용하는 경우, 인증만 필요한 사용자를 최상위 그룹에서 Minimal Access로 지정하는 방식이 유용합니다. - Minimal Access 사용자와 해당 역할만 가진 사용자는 좌석이 없어도 재활성화할 수 있습니다. ## 휴면 사용자 재활성화 문제 해결 - GitLab은 일정 기간 활동이 없는 사용자를 자동 비활성화해 좌석을 회수할 수 있습니다. - 이전에는 해당 사용자가 OIDC나 SSO로 다시 로그인하면 과금 사용자로 조용히 재활성화되어 좌석 초과가 발생할 수 있었습니다. - 이제 좌석이 부족하고 Restricted access가 활성화된 경우, 휴면 사용자는 **관리자 승인 대기 상태**로 전환됩니다. - 기존 그룹·프로젝트 멤버십은 유지됩니다. - 좌석이 확보되면 관리자가 사용자를 승인해 재활성화할 수 있습니다. ## 경고와 운영 가시성 강화 - LDAP 동기화, SAML 그룹 연결, SCIM 프로비저닝 설정 시 Restricted access의 동작을 안내하는 경고가 표시됩니다. - 좌석 한도에 접근 중인 상태와 한도에 도달한 상태가 제품 내에서 구분됩니다. - 좌석 부족으로 사용자가 Minimal Access로 배정되면 그룹 소유자나 인스턴스 관리자에게 이메일 알림이 전송됩니다. - Minimal Access로 전환된 이벤트는 감사 로그에서 확인할 수 있습니다. - 단순히 사용자 추가를 차단하는 것을 넘어, 왜 그런 처리가 발생했는지 추적하고 관리할 수 있게 개선되었습니다. ## Self-Managed의 설정 캐시 - GitLab Self-Managed는 성능을 위해 애플리케이션 설정을 기본적으로 60초간 캐시합니다. - Restricted access와 user cap 사이를 전환한 직후에는 UI나 좌석 제어 동작이 즉시 반영되지 않을 수 있습니다. - 캐시는 자동으로 갱신되며, 갱신 후에는 설정이 일관되게 적용됩니다. - 필요하다면 관리자가 캐시 간격을 조정할 수 있습니다. ## Restricted access와 user cap의 차이 - **User cap** - 좌석 여유 여부와 관계없이 새 사용자를 승인 대기 상태로 보냅니다. - 관리자나 그룹 소유자가 모든 신규 사용자 추가를 검토하는 승인 제어 기능입니다. - **Restricted access** - 라이선스 좌석이 모두 사용된 경우에만 신규 과금 사용자 추가를 제한합니다. - 구매한 좌석 수를 기준으로 동작하는 좌석 한도 제어 기능입니다. - 두 기능은 동시에 활성화할 수 없습니다. - Restricted access를 활성화하면 user cap은 자동으로 비활성화됩니다. - GitLab.com에서 user cap에서 Restricted access로 전환할 때 기존 대기 멤버의 상태가 영향을 받을 수 있으므로 전환 전에 관련 동작을 확인해야 합니다. ## 활성화 방법 - **GitLab.com** - `Settings > General > Permissions and group features > Seat control > Restricted access` - 그룹 Owner가 설정할 수 있습니다. - **Self-Managed** - `Admin > Settings > General > New user account restrictions > Seat control > Restricted access` - 관리자만 설정할 수 있습니다. - GitLab.com에서는 최상위 그룹이 외부 그룹과 공유된 경우 Restricted access를 사용할 수 없습니다. 자동 프로비저닝과 SSO를 사용하는 조직이라면 Restricted access를 활성화해 좌석 초과를 예방하는 것이 좋습니다. 다만 활성화 전 이미 발생한 초과 사용자는 별도로 정리하고, user cap과의 차이 및 기존 대기 사용자 처리 방식을 검토해야 합니다.

gitlab

GitLab 패치 릴리스: 18.8.11 | GitLab 문서 (새 탭에서 열림)

2026년 7월 1일 공개된 GitLab 18.8.11은 Rails 7.2 업그레이드로 발생한 데이터베이스 연결 누수 문제를 해결하는 패치 릴리스입니다. 데이터베이스 로드 밸런싱을 사용하는 환경의 안정성을 높이기 위한 긴급 패치이며, 보안 수정이나 신규 마이그레이션은 포함하지 않습니다. 다중 노드 배포에서는 일반적으로 다운타임 없이 업그레이드할 수 있습니다. ### 데이터베이스 연결 누수 수정 - 데이터베이스 로드 밸런서를 사용할 때 연결이 커넥션 풀로 정상 반환되지 않는 회귀 버그를 수정했습니다. - 해당 문제는 Rails 7.2 업그레이드 이후 발생했습니다. - 연결 누수가 지속되면 사용 가능한 데이터베이스 연결이 고갈되어 GitLab 성능 저하나 장애로 이어질 수 있습니다. - GitLab 18.8 필수 업그레이드 구간의 안정성을 확보하기 위해 정식 일정 외 패치로 제공되었습니다. ### 업그레이드 영향 - 신규 데이터베이스 마이그레이션은 포함되지 않습니다. - 다중 노드 배포 환경에서는 일반적으로 서비스 중단이 필요하지 않습니다. - Omnibus 패키지는 업그레이드 규모와 관계없이 기본적으로 다음 작업을 수행합니다. - GitLab 중지 - 마이그레이션 실행 - GitLab 재시작 - 업그레이드 시 자동 재구성을 건너뛰려면 다음 파일을 생성할 수 있습니다. ```text /etc/gitlab/skip-auto-reconfigure ``` - 이 설정은 업그레이드 작업에만 적용됩니다. ### 버전 및 구독 안내 - 대상 버전: - GitLab Community Edition 18.8.11 - GitLab Enterprise Edition 18.8.11 - 이번 릴리스에는 보안 수정 사항이 없습니다. - 업데이트 절차는 GitLab 공식 업데이트 페이지를 따라야 합니다. - Premium 및 Ultimate 기능은 유료 구독이 필요하며, 별도로 GitLab.com을 이용할 수도 있습니다. 데이터베이스 로드 밸런싱을 사용하는 GitLab 18.8 환경이라면 연결 고갈 위험을 줄이기 위해 18.8.11로 업데이트하는 것이 권장됩니다. અપ그레이드 전에는 자동 재구성 및 재시작 정책을 확인하고, 운영 환경에서는 공식 업데이트 절차에 따라 진행하는 것이 안전합니다.

gitlab

GitLab 패치 릴리스: 19.1.1, 19.0.3, 18.11.6 | GitLab 문서 (새 탭에서 열림)

2026년 6월 24일 GitLab은 19.1.1, 19.0.3, 18.11.6 패치 릴리스를 공개했으며, 여러 보안 취약점과 버그를 수정했다. 자체 호스팅 CE/EE 사용자는 즉시 지원 버전의 최신 패치로 업그레이드해야 하며, GitLab.com은 이미 패치가 적용되었다. GitLab Dedicated 고객은 별도 조치가 필요하지 않다. ## 패치 릴리스와 권고 사항 - 대상 버전: - GitLab 19.1.1 - GitLab 19.0.3 - GitLab 18.11.6 - Omnibus, 소스 설치, Helm 차트 등 배포 방식과 관계없이 취약 버전은 영향을 받을 수 있다. - GitLab은 정기적으로 매월 둘째·넷째 수요일에 패치 릴리스를 제공하며, 고위험 취약점에는 비정기 긴급 패치를 배포한다. - 보안 취약점의 상세 이슈는 패치 릴리스 후 30일이 지나면 공개된다. ## 분석 대시보드 XSS - **CVE-2026-10086**, CVSS 8.7. - GitLab EE의 Analytics Dashboard에서 사용자 입력 sanitization이 충분하지 않았다. - 인증된 Developer 권한 사용자가 다른 사용자의 세션 컨텍스트에서 임의의 클라이언트 측 코드를 실행할 수 있었다. - GitLab EE 16.4 이상 중 다음 버전 이전이 영향받는다. - 18.11.6 - 19.0.3 - 19.1.1 ## Web IDE 자산 처리기의 XSS - **CVE-2026-10712**, CVSS 8.0. - Web IDE workbench의 경로 검증 오류를 악용하면 인증되지 않은 공격자가 사용자의 브라우저 세션에서 임의의 JavaScript를 실행할 수 있었다. - GitLab CE/EE의 다음 버전 이전이 영향을 받는다. - 18.11.6 - 19.0.3 - 19.1.1 - 네트워크를 통한 공격이 가능하지만, 특정 조건과 사용자 상호작용이 필요하다. ## Duo Workflows 정보 노출 - **CVE-2026-12053**, CVSS 7.7. - GitLab EE의 Duo Workflows가 출력 내용을 충분히 필터링하지 못했다. - 조건에 따라 사용자가 프로젝트에 이미 커밋된 민감한 정보를 열람할 수 있었다. - GitLab EE 19.1 계열에서 19.1.1 이전 버전이 영향받는다. ## Virtual Registry 권한 우회 - **CVE-2026-5309**, CVSS 5.4. - Virtual Registry Cleanup Policy API의 권한 검사가 잘못되어 있었다. - 인증된 사용자가 다른 그룹의 가상 레지스트리 정리 정책을 읽거나 수정할 수 있었다. - GitLab EE 18.6 이상 및 19.x의 특정 이전 버전이 영향을 받는다. ## Rapid Diffs의 부적절한 권한 검사 - **CVE-2026-2238**, CVSS 5.3. - 공개 프로젝트에서 인증되지 않은 사용자가 비공개 이슈 참조를 볼 수 있었다. - GitLab CE/EE 17.5 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 대상이다. ## DAST 사이트 프로필 비밀정보 노출 - **CVE-2026-11379**, CVSS 5.3. - DAST 사이트 프로필 관리 기능의 권한 오류로 Developer 권한 사용자가 사이트 프로필의 비밀정보를 탈취할 수 있었다. - GitLab EE 13.11 이상부터 영향을 받으며, 각 유지보수 계열의 최신 패치 이전 버전이 취약하다. ## CI/CD API 로그 정보 노출 - **CVE-2026-8330**, CVSS 4.4. - CI/CD API 엔드포인트의 필터링 부족으로 민감한 정보가 애플리케이션 로그에 기록될 수 있었다. - GitLab CE/EE 9.3 이후의 오래된 버전부터 이번 패치 이전 버전까지 영향을 받는다. - 로그에 노출된 토큰이나 비밀값이 있다면 업그레이드와 함께 해당 자격 증명을 교체해야 한다. ## Snippets 콘텐츠 은닉 - **CVE-2026-1606**, CVSS 4.3. - Snippets의 입력값 검증 오류로 인증된 사용자가 콘텐츠를 숨겨 표시할 수 있었다. - GitLab CE/EE 14.8 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 영향받는다. ## Maven 패키지 보호 규칙 우회 - **CVE-2026-5952**, CVSS 4.3. - Maven Package Registry의 권한 검사 오류로 Developer 권한 사용자가 보호된 Maven 패키지 메타데이터를 덮어쓸 수 있었다. - GitLab CE/EE 17.11 이상 중 최신 패치 이전 버전이 영향을 받는다. ## 그룹 패키지 API 접근 제어 오류 - **CVE-2026-5796**, CVSS 4.3. - Package Registry가 비활성화된 프로젝트의 패키지 메타데이터를 Reporter 권한의 그룹 사용자가 열람할 수 있었다. - GitLab CE/EE 13.6 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 대상이다. ## 권장 대응 - 자체 호스팅 GitLab은 가능한 한 즉시 18.11.6, 19.0.3, 19.1.1 중 지원 중인 계열로 업그레이드한다. - 업그레이드 전 백업과 복구 절차를 확인하고, 업그레이드 후 CI/CD, Package Registry, Web IDE, DAST, Duo Workflows를 점검한다. - 로그나 설정에서 민감정보 노출 가능성이 확인되면 토큰·비밀번호·패키지 자격 증명을 함께 교체한다. - GitLab.com은 이미 수정 버전이 적용되어 별도 조치가 필요하지 않다.

gitlab

거버넌스 및 운영을 위한 AI 카탈로그 업데이트 (새 탭에서 열림)

GitLab 19.1은 Duo Flows를 실제 GitLab 이벤트에 따라 자동 실행할 수 있게 하며, AI 자동화를 지속적이고 무인으로 운영할 기반을 제공합니다. 동시에 관리자용 에이전트·플로우 통제, 설정 사전 검증, 승인된 AI 모델 목록 관리 기능을 추가해 엔터프라이즈 환경의 보안성과 신뢰성을 강화합니다. 결과적으로 개발자는 반복적인 수동 실행에서 벗어나고, 관리자는 조직에서 실행되는 AI를 통제할 수 있습니다. ## 이벤트 기반 Duo Flows 자동 실행 - 기존 Duo Flow는 사용자가 GitLab UI에서 멘션, 할당, 리뷰어 지정 등을 직접 수행해야 실행할 수 있었습니다. - GitLab 19.1에서는 다음 이벤트를 트리거로 사용할 수 있습니다. - **머지 리퀘스트 코드 충돌 감지**: 충돌 발생 즉시 요약과 해결 제안 실행 - **Draft에서 Ready for review로 변경**: 자동 컴플라이언스 검사나 사전 병합 체크 실행 - **머지 리퀘스트 승인**: 배포 준비 상태 확인, 컴플라이언스 기록, 인수인계 알림 실행 - **Work item 생성**: 자동 분류, 라벨 지정, 담당 팀 라우팅 실행 - 파이프라인 이벤트는 성공, 실패, 취소 등 특정 상태만 필터링할 수 있습니다. - 실패 시 인시던트 생성 - 성공 시 아티팩트 승격 - 취소 시 별도 후속 처리 - 코드 충돌 감지와 Draft→Ready for review 트리거는 기본 활성화됩니다. - 로컬에서 에이전트를 사용할 때는 패턴 기반 승인 기능을 통해 세션 동안 특정 도구 사용을 일괄 승인할 수 있어, 반복적인 파일 수정이나 `npm install` 과정에서 재승인할 필요가 줄어듭니다. ## 승인되지 않은 에이전트와 플로우 차단 - 인스턴스 관리자와 최상위 그룹 소유자는 조직에서 실행 가능한 AI 콘텐츠의 범위를 제한할 수 있습니다. - **Disable custom agents and flows** - 사용자가 사용자 정의 에이전트와 플로우를 생성하거나 활성화하지 못하게 합니다. - 검토된 기본 제공 콘텐츠 중심으로 사용을 제한합니다. - **Restrict the AI catalog to your group hierarchy** - 자신의 네임스페이스 외부에서 제공되는 AI Catalog 항목을 활성화하지 못하게 합니다. - 커뮤니티 및 서드파티 플로우가 보안 검토 없이 도입되는 것을 방지합니다. - 두 설정을 함께 사용하면 AI 활용은 허용하면서도 검증되지 않은 에이전트가 운영 환경에 확산되는 문제를 통제할 수 있습니다. ## 저장 전에 플로우 설정 검증 - 사용자가 AI Catalog의 플로우를 저장하거나 수정하면 GitLab이 Duo Workflow Service를 통해 설정을 검증합니다. - 누락된 입력값이나 알 수 없는 도구 파라미터 같은 오류가 저장 전에 구조화된 형태로 UI에 표시됩니다. - 잘못된 플로우가 운영 중 처음 발견되는 대신, 설정 단계에서 즉시 수정할 수 있습니다. - 자동 트리거는 잘못 구성될 경우 반복 실행과 불필요한 알림을 일으킬 수 있으므로 사전 검증의 중요성이 큽니다. ## 승인된 AI 모델만 사용하도록 제한 - 공개 베타 기능으로 관리자는 조직에서 사용할 수 있는 AI 모델의 allowlist를 설정할 수 있습니다. - 조직 전체의 기본 모델도 지정할 수 있으며, 사용자는 허용된 범위 안에서 모델을 선택할 수 있습니다. - 데이터 레지던시 요건이나 사내 승인 절차를 통과한 제공업체만 사용하도록 제한할 수 있습니다. - 초기 적용 범위는 GitLab Duo Agentic Chat이며, 향후 다른 기능 영역으로 확대될 예정입니다. ## 운영 환경을 위한 AI 자동화 기반 - 이벤트 기반 실행으로 사람이 버튼을 누르지 않아도 반복적인 검토, 분류, 알림, 배포 후속 작업을 수행할 수 있습니다. - 관리자는 실행 가능한 에이전트·플로우·모델을 통제하고, 개발자는 자동화 설정 오류를 운영 장애 전에 발견할 수 있습니다. - 도입 시에는 먼저 승인된 모델과 콘텐츠 범위를 정한 뒤, 실패 파이프라인이나 머지 리퀘스트 준비 완료 같은 명확한 이벤트부터 플로우를 단계적으로 적용하는 것이 좋습니다.

gitlab

취약점 통합 관점: 스캐너 커버리지에서 AI 거버넌스까지 (새 탭에서 열림)

GitLab 19.1은 여러 보안 스캐너의 결과와 적용 범위를 하나의 취약점 화면에서 관리하고, 프로젝트 전체에 스캐너 정책을 강제할 수 있도록 한다. 또한 시크릿 탐지 정확도를 높이고, AI 에이전트의 도구 사용을 승인 절차와 감사 로그로 통제해 자동화와 보안을 함께 확보하는 것이 글의 핵심이다. 궁극적으로 목표는 검증 가능한 스캐너 적용 범위와 통제된 AI 에이전트 자율성이다. ## 서드파티 스캐너 적용 범위의 중앙 관리 - 기업에서는 프로젝트마다 서로 다른 보안 스캐너를 설정하는 경우가 많아, 어떤 프로젝트가 실제로 검사되고 있는지 파악하기 어렵다. - 신규 프로젝트가 스캐너 설정에서 빠지면 몇 주 동안 검사되지 않은 코드가 배포될 수 있다. - GitLab 19.1에서는 **SARIF 형식으로 결과를 출력하는 서드파티 스캐너**를 GitLab 정책에 따라 모든 프로젝트에 적용할 수 있다. - 각 스캐너의 결과는 GitLab의 단일 취약점 화면으로 통합되며, 동일한 정책과 규칙으로 관리된다. - 이를 통해 스캐너 적용 범위를 추정하는 대신 감사나 보고에서 입증할 수 있다. ## 서드파티 취약점의 자동 remediation - 서드파티 스캐너에서 발견한 취약점도 GitLab 네이티브 스캐너 결과와 동일한 자동화 흐름에 포함된다. - **SAST False Positive Detection**이 오탐 가능성을 분류해 실제 위험이 높은 이슈를 우선 처리한다. - **Agentic SAST Vulnerability Resolution**은 수정안을 생성하고 바로 병합할 수 있는 머지 리퀘스트를 자동으로 연다. - 결과적으로 취약점이 프로덕션에 도달하기 전에 자동 수정할 가능성이 높아진다. ## 시크릿 탐지 범위 확대와 오탐 감소 - 기존에는 새 브랜치에서 최신 커밋만 검사했기 때문에, 이전 커밋에 포함된 비밀 정보가 탐지되지 않을 수 있었다. - 이제 새 브랜치의 **모든 커밋을 검사**해 시크릿이 처음 도입된 지점을 놓칠 가능성을 줄인다. - 정식 출시된 **Secret False Positive Detection**은 각 탐지 결과에 신뢰도 점수와 설명을 제공한다. - 테스트용 자격 증명, 예시 토큰, 플레이스홀더 값과 실제 유출된 비밀 정보를 구분하는 데 도움을 준다. - 개발자는 오탐을 정리하는 데 쓰는 시간을 줄이고 실제 자격 증명 노출에 집중할 수 있다. ## AI 에이전트의 도구 사용 통제 - 코딩 에이전트는 머지 리퀘스트 생성, 도구 호출, 코드 커밋 등을 수행할 수 있지만, 승인 후에는 파일 작성·삭제·푸시까지 자동으로 실행할 위험이 있다. - 조직은 에이전트가 행동하기 전에 허용 범위를 정하고, 행동 이후에는 무엇을 했는지 증명할 수 있어야 한다. - 베타 기능인 **Agent tool approval guardrails**를 사용하면 관리자마다 에이전트 도구를 다음처럼 설정할 수 있다. - 자동 실행 - 사람의 승인 후 실행 - 실행 차단 - 파일 작성이나 리소스 삭제처럼 민감한 작업은 담당자의 승인 전까지 보류할 수 있다. ## AI 감사 이벤트와 책임 추적 - 베타 기능인 **AI audit event streaming**은 에이전트의 모든 활동을 감사 이벤트로 기록하고 기존 감사 로그 저장소로 스트리밍한다. - 사람이 승인하거나 거부한 결정도 감사 이벤트로 남는다. - 사고 대응이나 감사 시 에이전트가 언제 어떤 도구를 사용했고, 어떤 변경을 수행했는지 확인할 수 있다. - 이를 통해 에이전트가 완전히 제한되는 것이 아니라, 사전에 정한 경계 안에서 자율적으로 작업하는 **통제된 자율성(governed autonomy)**을 구현한다. ## 실용적인 적용 방향 조직은 먼저 모든 프로젝트에 SARIF 기반 스캐너 정책을 강제해 보안 검사 공백을 제거하고, 통합 취약점 화면에서 결과를 관리하는 것이 좋다. 이후 시크릿 탐지와 오탐 분류를 활성화하고, AI 에이전트에는 파일 삭제·코드 푸시 등 고위험 작업에 사람 승인과 감사 로그를 적용하는 방식이 적절하다.