GitLab/sast

10 개의 포스트

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

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

취약점 통합 관점: 스캐너 커버리지에서 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 에이전트에는 파일 삭제·코드 푸시 등 고위험 작업에 사람 승인과 감사 로그를 적용하는 방식이 적절하다.

gitlab

에이전트 코딩은 컨텍스트만큼만 훌륭하다 (새 탭에서 열림)

코딩 에이전트의 성능과 신뢰성은 코드 작성 능력보다 프로젝트 생명주기 전반의 맥락을 얼마나 활용하느냐에 달려 있다. 저장소만 보는 에이전트는 컴파일되는 코드를 만들 수 있지만, 이슈 요구사항·CI 규칙·보안 정책·리뷰 기준까지 반영하기 어렵다. GitLab처럼 이슈, 파이프라인, 보안 스캔, 머지 리퀘스트를 연결하면 에이전트가 조직의 가드레일 안에서 작업하고, 리뷰 라운드와 머지까지 걸리는 시간을 줄일 수 있다. ## 저장소만 보는 에이전트의 한계 - 에이전트는 로컬 파일과 사용자가 입력한 프롬프트를 기반으로 코드를 수정하고 빌드를 실행한다. - 코드가 컴파일되더라도 다음 정보를 알지 못할 수 있다. - 이슈의 인수 조건과 구현 메모 - 비기능 요구사항 - CI 설정에 정의된 린터·테스트·품질 기준 - 조직의 코드 리뷰 규칙과 보안 정책 - 결과적으로 “동작하는 코드”와 “팀이 실제로 요구한 변경” 사이에 차이가 생긴다. - 이슈 링크 누락, 새로 추가된 린터 규칙 위반, 승인되지 않은 의존성 추가 같은 재작업이 발생할 수 있다. ## GitLab 이슈를 연결했을 때의 변화 - GitLab MCP 서버를 연결하면 에이전트가 코딩 전에 관련 이슈를 조회할 수 있다. - 이슈의 요구사항, 구현 메모, 라벨, 마일스톤을 확인해 계획에 맞는 수정이 가능해진다. - 예를 들어 Codex는 머지 리퀘스트 설명에 `Closes #32`를 추가해 코드 변경과 이슈의 관계를 명시한다. - Claude Code는 `get_issue`로 버그 리포트를 가져오고, `create_merge_request`로 적절한 참조가 포함된 MR을 생성한다. - 즉, 에이전트의 작업이 단순한 코드 수정에서 프로젝트 계획과 연결된 변경으로 확장된다. ## 머지 리퀘스트 안에서 수행하는 리뷰와 수정 - MR이 생성되면 GitLab의 Code Review Flow가 자동으로 리뷰 피드백을 게시한다. - 에이전트는 MR 내부의 외부 에이전트로 호출되어 다음과 같은 후속 작업을 수행할 수 있다. - 누락된 테스트 추가 - 문서 주석 보완 - 리뷰에서 발견된 검증 로직의 공백 수정 - 수정 사항은 MR 브랜치에 직접 커밋된다. - 새 커밋마다 CI/CD 파이프라인이 자동 실행되므로, 에이전트의 수정 결과를 즉시 검증할 수 있다. - 사람은 다른 도구로 전환하지 않고 MR에서 변경 내용과 파이프라인 결과를 검토한다. - 이 흐름은 리뷰 반복 횟수와 머지까지 걸리는 시간을 줄이는 데 기여한다. ## 플랫폼 전체 맥락과 조직의 가드레일 - 플랫폼 팀은 조직 내 AI 개발 방식에 대해 다음을 결정한다. - 허용할 에이전트 - 에이전트가 접근할 수 있는 도구와 데이터 - 결과물을 검증하는 방법 - 사람의 승인과 판단이 필요한 지점 - DevSecOps 플랫폼에는 에이전트가 필요로 하는 생명주기 정보가 모여 있다. - 이슈 트래커: 요구사항과 우선순위 - CI/CD 설정: 품질 기준과 자동 검증 - 코드 리뷰 지침: 스타일과 개발 표준 - 보안 스캐너: 취약점 정책 - MR: 자동화와 최종적인 사람의 승인 - IDE나 터미널 기반 에이전트가 아무리 뛰어나도 제공된 파일 중심으로만 판단한다. - 반면 플랫폼은 이슈부터 파이프라인, 보안 정책, 배포 대상, 승인 규칙까지 전체 흐름을 볼 수 있다. - 따라서 안전하게 배포되는 결과물은 에이전트 자체의 능력뿐 아니라 플랫폼이 제공하는 가시성과 통제에 좌우된다. ## AI가 코드를 더 많이 만들 때의 보안 영향 - 코드 생성 속도가 빨라지면 새 취약점, 보안 스캔 결과, 수정용 MR도 함께 증가한다. - 기존에는 보안팀이 취약점을 탐지·분류한 뒤 개발자에게 수정 요청을 보내고 기다리는 과정이 병목이었다. - 에이전트가 수정까지 빠르게 수행하면 병목은 “무엇을 고칠까”에서 “어떤 AI 생성 수정 MR을 먼저 사람이 승인할까”로 이동한다. - 우선순위를 정하려면 다음과 같은 전체 맥락이 필요하다. - 프로젝트 전체 코드 - 데이터 흐름 - 실제 배포 환경 - 조직에 적용되는 보안 정책 - 이런 맥락이 있으면 단순한 심각도 점수가 아니라 실제 환경에서의 노출 가능성을 기준으로 취약점을 우선순위화할 수 있다. - GitLab 보안 계층은 프로젝트 맥락을 활용해 오탐을 걸러내고 확인된 취약점을 식별한다. - 확인된 취약점에 대해서는 agentic SAST vulnerability resolution이 취약 코드와 주변 코드를 분석해 수정 MR을 자동 생성한다. - 이후 파이프라인이 수정 사항을 검증하고, 최종 머지 여부는 사람이 결정한다. - 즉, 에이전트가 수정 작업을 담당하더라도 승인과 거버넌스는 사람에게 남는다. ## `AGENTS.md`를 활용한 프로젝트별 지침 - 두 튜토리얼 모두 저장소에 `AGENTS.md` 파일을 두고 에이전트의 행동 지침으로 활용한다. - 이 파일에는 다음과 같은 내용이 포함될 수 있다. - 프로젝트 구조 - 실행해야 할 명령어 - 코드 품질 기준 - 수정해서는 안 되는 파일이나 영역 - Codex와 GitLab 튜토리얼에서는 Rust 에디션, 비동기 동시성 패턴, CI 이미지 고정 정책 등이 정의되어 있었다. - 이를 통해 에이전트가 매번 프롬프트로 설명받지 않아도 프로젝트의 기술적 규칙과 변경 범위를 일관되게 준수할 수 있다. 플랫폼 팀은 에이전트를 단독 코딩 도구로 도입하기보다 이슈·`AGENTS.md`·CI/CD·보안 스캔·MR 리뷰를 연결한 workflow 안에 배치하는 것이 좋다. 에이전트가 더 많은 작업을 자동화할수록 자동 검증은 강화하고, 최종 승인과 책임은 사람에게 남겨야 한다.

gitlab

몇 분 만에 코드베이스 전체의 보안 스캐너 검사 완료 (새 탭에서 열림)

GitLab 19.0의 보안 구성 프로필은 프로젝트별 `.gitlab-ci.yml` 수정 없이 조직 전체에 보안 스캐너를 중앙에서 적용할 수 있게 한다. 이를 통해 SAST, 의존성 스캐닝, 비밀 탐지를 수백~수천 개 프로젝트에 몇 분 안에 배포하고, AI로 빨라진 개발 속도에 따른 보안 적용 누락을 줄일 수 있다. GitLab Ultimate 사용자는 보안 인벤토리에서 여러 프로젝트에 기본 프로필을 일괄 적용해 일관된 보안 검사 범위를 확보할 수 있다. ## 수동 스캐너 설정의 한계 - 프로젝트마다 `.gitlab-ci.yml`을 직접 수정하는 방식은 규모가 작을 때만 관리하기 쉽다. - 조직과 저장소가 늘어나면 다음과 같은 설정 드리프트가 발생한다. - 팀마다 서로 다른 SAST 규칙을 사용한다. - 새 프로젝트에는 의존성 스캐닝을 추가하지만 기존 프로젝트에는 적용하지 않는다. - 파이프라인 수정 과정에서 실수로 보안 스캐너 설정이 삭제된다. - 중앙 현황판이 없으면 어떤 프로젝트가 검사 중인지, 어떤 프로젝트가 누락됐는지 파악하기 어렵다. - AI를 활용한 코드 생성과 빠른 배포로 프로젝트·파이프라인 수가 증가하면서 보안 적용 범위의 격차가 더 커지고 있다. ## 보안 구성 프로필의 개념 - 보안 구성 프로필은 스캐너의 종류와 실행 조건을 중앙에서 정의하는 설정 묶음이다. - 그룹 수준에서 프로필을 한 번 설정한 뒤 여러 프로젝트에 일괄 적용할 수 있다. - 프로젝트별 YAML 파일에 SAST, 비밀 탐지, 의존성 스캐닝을 각각 추가할 필요가 없다. - GitLab은 권장 설정을 반영한 스캐너별 기본 프로필을 제공한다. - 따라서 YAML을 직접 작성하지 않고도 몇 분 안에 조직 전체의 스캐닝을 시작할 수 있다. ## 스캔 트리거와 보안 범위 기본 프로필은 스캐너별로 여러 실행 트리거를 활성화한다. - **머지 리퀘스트 파이프라인** - 열린 머지 리퀘스트 브랜치에 새 커밋이 푸시될 때 자동 실행된다. - 해당 머지 리퀘스트에서 새로 유입된 취약점에 초점을 맞춘 결과를 제공한다. - 기존 취약점으로 인한 불필요한 경고를 줄이고 개발자가 수정해야 할 문제를 명확히 한다. - **기본 브랜치 파이프라인** - 변경 사항이 기본 브랜치에 병합되거나 직접 푸시될 때 실행된다. - 보안 팀이 기본 브랜치의 전체적인 보안 상태를 지속적으로 확인할 수 있다. - **비밀 탐지의 푸시 보호** - 비밀 탐지는 위 두 트리거에 더해 푸시 보호를 제공한다. - 파이프라인 완료를 기다리지 않고 `git push` 과정에서 API 키나 토큰 등을 실시간으로 검사한다. - 비밀이 저장소에 들어가기 전에 푸시를 차단한다. - 이벤트 기반 기능이므로 보안 인벤토리에 일반적인 스캔 날짜가 표시되지 않는다. ## 실제 활용 사례 - **대규모 프로젝트의 검사 범위 표준화** - 보안 팀은 보안 인벤토리에서 모든 프로젝트의 스캐너 적용 여부와 실패 상태를 한눈에 확인할 수 있다. - 여러 프로젝트를 선택한 뒤 기본 프로필을 일괄 적용할 수 있다. - 개별 `.gitlab-ci.yml`을 수정하지 않고도 머지 리퀘스트와 기본 브랜치에서 SAST, 비밀 탐지, 의존성 스캐닝을 실행할 수 있다. - **코드 취약점의 조기 발견** - 개발자가 API 구현 중 안전하지 않은 역직렬화 패턴을 추가하면 SAST가 머지 리퀘스트 파이프라인에서 이를 탐지한다. - 코드가 승인·배포되기 전에 수정할 수 있어 사고 대응보다 훨씬 적은 비용으로 문제를 해결할 수 있다. - **감염된 의존성 차단** - 잠금 파일에서 의존성 버전을 업데이트하면 의존성 스캐닝이 변경된 패키지를 검사한다. - 악성 코드가 포함된 패키지 버전을 병합 전에 탐지해 빌드 서버나 운영 환경에 확산되는 것을 막는다. - **비밀 정보의 저장소 유입 방지** - 개발자가 디버깅 중 API 키를 커밋하려 하면 푸시 보호가 실시간으로 푸시를 차단한다. - 보안 티켓 생성이나 사후 자격 증명 교체가 필요해지기 전에 문제를 해결할 수 있다. ## 적용 방법과 상태 확인 - 보안 구성 프로필은 GitLab Ultimate의 GitLab.com, Self-Managed, Dedicated 환경에서 사용할 수 있다. - 적용 절차: 1. 그룹에서 **Secure > Security inventory**로 이동한다. 2. 적용할 프로젝트를 선택하거나 전체 프로젝트를 선택한다. 3. **Bulk Action > Manage security scanners**를 선택한다. 4. **Apply default profile to all**을 선택한다. - 적용 후 **Tool Coverage** 열에서 상태를 확인할 수 있다. - 녹색 막대: 스캐너가 완전히 활성화됨 - 부분 막대: 일부 트리거만 활성화됨 - 회색 막대: 아직 설정되지 않음 - 기존 `.gitlab-ci.yml` 설정과 프로필 기반 설정은 함께 사용할 수 있다. - 두 설정이 병존하는 전환 기간에는 보안 인벤토리의 상태 표시가 실제 결합 상태를 정확히 반영하지 않을 수 있으므로, 개별 프로젝트의 **Security Configuration** 페이지에서 프로필 상태를 확인하는 것이 권장된다. 조직 규모가 크거나 프로젝트 생성 속도가 빠르다면, 프로젝트별 YAML 관리보다 보안 구성 프로필을 기본값으로 적용하는 편이 효율적이다. 우선 보안 인벤토리에서 적용 누락 프로젝트를 확인한 뒤 기본 프로필을 일괄 적용하고, 이후 부분 적용·실패 상태를 정기적으로 점검하는 방식이 실용적이다.

gitlab

정책으로 오해를 불러일으키는 취약점 심각도를 수정하는 5가지 방법 (새 탭에서 열림)

CVSS는 취약점의 이론적 특성만 평가하므로, 실제 배포 환경과 노출 정도를 충분히 반영하지 못한다. GitLab의 취약점 관리 정책을 사용하면 CVE·CWE·파일 경로·디렉터리 조건에 따라 심각도를 자동 조정해 조직의 실제 위험 모델에 맞출 수 있다. 이를 통해 대규모 스캔 결과를 수동으로 분류하는 부담을 줄이고, 중요한 취약점에 대응 우선순위를 일관되게 부여할 수 있다. ## GitLab 심각도 재정의 정책의 작동 방식 - 정책은 기본 브랜치의 파이프라인이 실행될 때마다 취약점 결과에 적용된다. - 다음 조건으로 취약점을 선택할 수 있다. - CVE ID - CWE ID - 특정 파일 경로 - 특정 디렉터리 - 제공되는 심각도 조정 방식은 세 가지다. - **Set Severity**: `info`, `low`, `medium`, `high`, `critical` 중 하나로 고정 - **Increase Severity**: 한 단계 상향 - **Decrease Severity**: 한 단계 하향 - 권한이 있는 사용자가 직접 변경한 심각도는 정책보다 우선한다. - 정책으로 변경된 내역은 취약점 이력과 감사 이벤트에 기록되어 변경 이유를 추적할 수 있다. ## 내부 서비스의 낮은 노출 위험 반영 내부 관리자 도구, 개발자용 유틸리티, 배치 작업처럼 외부 트래픽을 받지 않는 서비스는 동일한 CVE라도 공개 API보다 실제 위험이 낮을 수 있다. - `internal/**/*` 같은 내부 서비스 디렉터리를 대상으로 정책을 적용한다. - 특정 CVE가 해당 디렉터리에서 발견되면 심각도를 한 단계 낮춘다. - 예를 들어 `Critical`은 `High`, `High`는 `Medium`으로 조정된다. - 전체 심각도를 무조건 낮추지 않고 상대적인 우선순위를 유지하는 방식이다. - 조직이 내부 배포 환경에서 위험이 낮다고 판단한 CVE 목록으로 값을 교체해 사용해야 한다. ## 운영 코드의 인젝션 취약점 상향 XSS와 SQL 인젝션은 실제 공격에 자주 악용되는 대표적인 취약점이므로, 운영 소스 코드에서 발견되면 기본 CVSS보다 엄격하게 처리할 수 있다. - `CWE-79`(Cross-Site Scripting)와 `CWE-89`(SQL Injection)를 조건으로 지정한다. - `src/**/*` 등 운영 코드 디렉터리에서 발견된 경우 심각도를 `Critical`로 고정한다. - CWE와 경로를 함께 조건으로 사용해 테스트 코드나 비운영 영역의 불필요한 상향을 줄인다. - Critical 취약점에 보안팀 승인을 요구하는 머지 리퀘스트 승인 정책과 결합하면: - 취약점 보고서에서 우선순위가 상향되고 - 검토 없이 해당 코드가 프로덕션에 병합되는 것을 방지할 수 있다. ## 여러 스캐너 간 심각도 통일 SAST, 의존성 스캔, 컨테이너 스캔 등은 같은 CVE를 서로 다른 심각도로 보고할 수 있다. 이 차이는 대응 기준과 승인 임계값을 혼란스럽게 만든다. - 조직이 특정 CVE를 항상 같은 수준으로 처리해야 한다고 판단하면 심각도를 고정한다. - 예를 들어 Log4j 관련 CVE인 `CVE-2021-44228`, `CVE-2021-45046`, `CVE-2021-45105`를 모두 `High`로 설정할 수 있다. - 어떤 스캐너가 발견했는지와 관계없이 동일한 기준을 적용할 수 있다. - 여러 종류의 보안 스캔을 운영하는 조직에서 보고서와 승인 절차를 일관되게 만드는 데 유용하다. ## 실제 악용 정보에 따른 상향 CVSS는 정적인 점수이므로 취약점이 실제 공격에 사용되기 시작했는지 즉시 반영하지 못한다. 이를 보완하기 위해 EPSS와 CISA KEV 같은 위협 인텔리전스를 정책 조건에 활용할 수 있다. - CISA KEV 카탈로그에 등록된 CVE는 실제 악용 사례가 확인된 것으로 보고 `Critical`로 상향할 수 있다. - EPSS가 높은 취약점, 예를 들어 악용 가능성이 `0.5`를 넘는 CVE도 더 높은 우선순위로 처리할 수 있다. - 글에서는 `CVE-2024-3094`, `CVE-2023-4966`, `CVE-2023-22515` 등을 KEV 기반 상향 예시로 제시한다. - 다만 제공된 글 내용은 이 네 번째 예시의 정책 설정 중간에서 끝나 있어, 다섯 번째 방법과 이후 세부 내용은 확인할 수 없다. ## 적용 시 권장 사항 - 심각도 조정은 CVSS를 임의로 왜곡하기보다 배포 위치, 공격 노출도, 실제 악용 여부를 반영하는 조직별 위험 모델로 사용한다. - 디렉터리 조건을 함께 지정해 내부·테스트·운영 코드를 구분한다. - 정책 변경 이력과 수동 재정의 우선순위를 고려해 정기적으로 정책을 검토한다. - Critical 상향 정책은 머지 승인 정책과 연계해 보고서 분류뿐 아니라 배포 통제까지 자동화하는 것이 좋다.

gitlab

AI 보조 코딩 시대에 맞춰 파이프라인 경계를 강화하세요 (새 탭에서 열림)

AI 지원 개발로 사람·에이전트·외부 코드가 빠르게 결합하면서, 기존의 문서 중심 보안 정책만으로는 파이프라인을 보호하기 어려워졌다. 글은 GitLab Ultimate이 보안을 별도 포털이 아닌 개발 플랫폼의 통제 영역에 통합해, 모든 변경을 **보고(See)·강제하고(Enforce)·수정하는(Fix)** DevSecOps 제어면을 제공한다고 주장한다. 이 세 요소를 결합해야 AI가 생성하는 코드의 속도와 보안 요구를 함께 충족할 수 있다는 결론이다. ## 모든 프로젝트와 보안 활동을 가시화 - 그룹 보안 대시보드에서 다음 스캐너의 결과를 여러 저장소에 걸쳐 통합해서 확인한다. - SAST - SCA - 시크릿 탐지 - 컨테이너 스캔 - IaC 스캔 - DAST - 퍼징 테스트 - 프로젝트별 위험 추세, 사업부·노출 수준별 위험, 보안 인벤토리를 한 화면에서 확인할 수 있다. - 한 번도 스캔되지 않아 보안 등급이 없는 프로젝트도 식별해 보이지 않는 사각지대를 줄인다. - Credentials Inventory는 인스턴스 전체 토큰의 소유자, 권한 범위, 만료일을 보여준다. - 손상된 토큰이나 아직 활성화된 토큰을 필터링해 사고 중 즉시 폐기할 수 있다. - Token Lifetime Enforcement로 토큰이 관리자가 정한 최대 수명을 넘겨 사용되지 않도록 강제한다. - Audit Event Streaming은 토큰 생성, 권한 변경, MR 승인, 역할 변경 등의 이벤트를 구조화된 타임스탬프와 함께 SIEM으로 실시간 전송한다. - 그룹 단위 SBOM을 이용해 전체 프로젝트 포트폴리오에서 오픈소스 의존성 노출 여부를 검색한다. ## 정책을 파이프라인에서 자동으로 강제 - 문서로만 존재하는 정책은 개발자가 매번 기억하고 설정해야 하므로, 사람이 만든 변경뿐 아니라 AI 에이전트가 만든 변경에도 일관되게 적용하기 어렵다. - Scan Execution Policies는 운영 환경을 대상으로 하는 모든 파이프라인에 SAST, SCA, 시크릿 탐지 작업을 자동 삽입한다. - 프로젝트별 설정이 필요 없다. - 개발자가 보안 작업을 임의로 제거할 수 없다. - `[skip ci]`로 우회할 수 없다. - Pipeline Execution Policies(PEP)는 플랫폼이 관리하는 CI 템플릿을 강제한다. - 팀이 별도로 만든 이른바 섀도 파이프라인도 동일한 접근 권한과 신뢰 수준으로 실행되는 문제를 줄인다. - 프로젝트의 CI 설정에 보안 작업이 빠져 있어도 필수 검사를 실행한다. - MR Approval Policies로 보호 브랜치, 최소 승인자 수, 코드 소유자 승인 요건을 자동화한다. - Compliance Center는 정책을 SOC 2, ISO 27001, NIST, PCI DSS 등의 기준과 연결하고, 실시간 대시보드와 변경 이력 보고서를 제공한다. - Secret Push Protection은 pre-receive hook 단계에서 비밀정보가 Git 이력에 들어가기 전에 푸시를 차단한다. - 문제가 된 파일과 줄, 탐지된 시크릿 유형을 표시한다. - 우회 시도도 기록한다. ## 개발 흐름 안에서 취약점 수정 - MR 보안 위젯은 코드가 기본 브랜치에 병합되기 전에 diff 내부에 SAST, SCA, 컨테이너, IaC, 시크릿 탐지 결과를 표시한다. - 개발자는 별도 보안 포털로 이동하지 않고 현재 MR에서 다음 정보를 확인할 수 있다. - 새로 발생한 취약점 - 취약점이 존재하는 코드 위치 - 수정 방법 - Advanced SAST는 여러 함수와 파일을 가로지르는 데이터 흐름을 분석해, 공격자가 입력값을 추적하는 방식으로 오염된 입력이 최종 사용 지점까지 도달하는 경로를 보여준다. - GitLab Duo Agent Platform은 오탐 가능성을 평가하고 판단 근거를 설명해 불필요한 수동 분류 작업을 줄인다. - GitLab Duo Security Analyst Agent는 CVSS 점수만 보지 않고 악용 가능성, 외부 노출 정도, 비즈니스 맥락을 고려해 취약점의 우선순위를 정한다. - Agentic Vulnerability Resolution은 영향이 큰 SAST 취약점에 대해 수정 MR을 자동으로 생성한다. - 관련 코드 맥락이 함께 포함된다. - 개발자가 변경 내용을 검토하고 기존 승인 절차에 따라 병합한다. - 탐지부터 수정·배포까지 같은 워크플로 안에서 완료할 수 있다. ## AI 시대의 파이프라인 보안 전략 - AI 에이전트가 코드를 생성하고 MR을 열며 변경 사항을 배포하는 속도는 기존 보안 검토보다 빠르다. - 따라서 보안 검사를 개발자에게 맡기거나 별도 대시보드에 의존하기보다, 그룹·플랫폼 수준에서 자동 적용해야 한다. - 효과적인 통제면은 다음 세 요소를 함께 제공해야 한다. - **가시화:** 모든 프로젝트, 토큰, 의존성, 보안 이벤트 확인 - **강제:** 파이프라인과 MR마다 정책을 자동 적용 - **수정:** 코드 변경 지점에서 우선순위화와 자동 수정 수행 실무적으로는 먼저 그룹 단위 보안 대시보드와 SBOM으로 사각지대를 파악한 뒤, 필수 스캔·승인·시크릿 차단 정책을 플랫폼 수준에서 강제하는 접근이 권장된다. 이후 AI 기반 오탐 분류와 자동 수정 MR을 도입하면 개발 속도를 크게 떨어뜨리지 않으면서 보안 부채를 줄일 수 있다.

gitlab

바로 병합 가능한 AI 코드 수정으로 조치 자동화하기 (새 탭에서 열림)

GitLab 18.11은 AI 기반의 '에이전틱 SAST 취약점 해결(Agentic SAST Vulnerability Resolution)' 기능을 정식 출시하며 보안 병목 현상을 획기적으로 개선했습니다. 이 시스템은 취약점을 자동으로 분석하고 테스트를 거친 수정 코드를 제안함으로써, 개발자가 보안 이슈 해결을 위해 컨텍스트를 전환하거나 수동으로 연구하는 시간을 대폭 줄여줍니다. 결과적으로 보안 취약점이 운영 환경에 도달하기 전에 선제적으로 대응할 수 있는 자율적인 보안 파이프라인 구축이 가능해졌습니다. ### 에이전트 기반 자동 수정 및 개발 흐름 최적화 * **자율적 취약점 해결:** GitLab Duo 에이전트가 취약점의 맥락을 분석하여 근본 원인을 해결하는 코드를 자동 생성하고, 자동화된 테스트를 통해 검증까지 마친 '병합 준비 완료(ready-to-merge)' 상태의 MR을 제공합니다. * **신뢰도 점수 제공:** 개발자는 에이전트가 제안한 수정 사항과 함께 제공되는 신뢰도 점수를 확인하여 신속하고 정확한 의사결정을 내릴 수 있습니다. * **증분 스캐닝(Incremental Scanning):** 전체 스캔이 완료될 때까지 기다릴 필요 없이 변경된 코드 부분에 대한 보안 결과를 즉시 확인할 수 있어 파이프라인의 속도가 향상되었습니다. ### 비즈니스 리스크 중심의 스마트한 우선순위 지정 * **CVSS 4.0 적용:** 최신 산업 표준인 CVSS 4.0을 도입하여 실제 환경에서의 악용 가능성을 더욱 정교하게 반영한 취약점 점수를 제공합니다. * **정책 기반 심각도 재정의:** AppSec 팀은 CVE, CWE, 특정 파일 경로 등의 신호를 바탕으로 취약점 심각도 점수를 자동으로 조정하는 정책을 설정하여, 단순 스캐너 출력값이 아닌 실제 비즈니스 위험도에 따라 업무 우선순위를 정할 수 있습니다. * **실질적 위험 차단:** 알려진 악용 취약점(KEV) 상태나 악용 예측 점수 시스템(EPSS) 임계값을 기준으로 병합(Merge)을 차단하거나 경고하는 승인 정책을 구성할 수 있습니다. * **보안 대시보드 강화:** 새로운 'Top CWEs' 차트를 통해 프로젝트 전반에서 가장 빈번하게 발생하는 취약점 클래스를 파악하고 시스템적인 리스크를 관리할 수 있습니다. ### 보안 거버넌스 강화 및 운영 부담 완화 * **보안 관리자(Security Manager) 역할 도입:** 코드 수정이나 배포 권한 없이도 보안 정책을 설정하고 취약점 조치 워크플로우를 관리할 수 있는 전용 역할이 추가되어, 권한 분리 및 보안 전문성 강화가 가능해졌습니다. * **SAST 구성 프로필:** 개별 프로젝트마다 YAML 파일을 수정할 필요 없이, 단일 위치에서 그룹 내 모든 프로젝트에 일관된 보안 스캔 설정을 한 번에 적용할 수 있습니다. * **운영 효율성 제고:** 개발자에게 일일이 스캐너 설정을 요청하거나 각 프로젝트의 커버리지 격차를 수동으로 확인할 필요가 없어 보안 팀의 운영 오버헤드가 크게 줄어듭니다. --- 보안 팀이 개발 속도를 따라잡지 못해 고민이라면, GitLab 18.11의 에이전틱 보안 기능을 도입해 볼 것을 권장합니다. 특히 **GitLab Ultimate** 사용자라면 'Agentic SAST Vulnerability Resolution'을 통해 보안 부채를 자동으로 탕감하고, 개발자는 코드 작성에만 집중할 수 있는 환경을 구축할 수 있습니다.

gitlab

GitLab 18.11 릴리스 노트 | GitLab 문서 (새 탭에서 열림)

GitLab 18.11 버전부터 GitLab Duo 에이전트 플랫폼을 통한 '에이전틱 SAST 취약점 해결(Agentic SAST Vulnerability Resolution)' 기능이 정식 출시되었습니다. 이 기능은 SAST 스캔 과정에서 발견된 보안 취약점을 AI 에이전트가 자율적으로 분석하고, 코드 수정안이 포함된 머지 리퀘스트(MR)를 자동으로 생성하여 개발자의 보안 조치 속도를 획기적으로 높여줍니다. 특히 치명적(Critical) 및 높음(High) 심각도의 취약점에 대해 즉각적인 해결책을 제시함으로써 보안 부채를 효율적으로 관리할 수 있게 돕습니다. ### AI 기반의 자율적 취약점 분석 및 수정 * **문맥 중심 분석:** 단순한 패턴 매칭을 넘어, AI 에이전트가 취약점 주변의 코드 문맥을 스스로 파악하고 논리적으로 추론하여 최적의 해결책을 도출합니다. * **자동 수정 제안:** 분석 결과를 바탕으로 즉시 검토 및 반영이 가능한 머지 리퀘스트(MR)를 자동으로 생성하여 개발자의 수동 작업 부담을 줄여줍니다. * **유연한 실행 시점:** 전체 SAST 스캔 프로세스의 일부로 실행되거나, 오탐지 감지 단계 이후, 또는 특정 취약점 상세 페이지에서 사용자가 수동으로 트리거하여 실행할 수 있습니다. ### 신뢰도 높은 보안 워크플로우 제공 * **품질 평가 지표:** AI가 제안한 해결 방안에 대해 품질 평가(Quality assessments) 결과를 함께 제공하여, 리뷰어가 제안된 코드의 신뢰도를 신속하게 판단할 수 있도록 지원합니다. * **직관적인 관리:** 취약점 상세 정보 페이지에서 분석 내용을 확인하고, 제시된 해결책을 즉시 적용할 수 있는 통합된 사용자 경험을 제공합니다. * **우선순위 대응:** 보안 위협이 큰 치명적(Critical) 및 높음(High) 등급의 SAST 취약점을 우선적으로 처리하는 데 특화되어 있습니다. ### 서비스 이용 환경 및 대상 * **지원 대상:** 이 기능은 GitLab Ultimate 플랜 고객에게 제공됩니다. * **배포 환경:** GitLab.com(SaaS), Self-Managed, GitLab Dedicated 환경에서 모두 사용할 수 있습니다. 대규모 코드베이스에서 보안 취약점을 일일이 분석하고 수정하는 과정은 많은 시간과 비용이 소모됩니다. 이번에 정식 출시된 에이전틱 SAST 기능을 활용하면 보안 전문가의 개입 없이도 초동 조치가 가능해지므로, 개발팀은 보안 사고 예방 속도를 높이고 보다 고도화된 비즈니스 로직 개발에 집중할 것을 추천합니다.

gitlab

GitLab 18.10, AI 네이티브 트리아지 및 문제 해결 기능 도입 (새 탭에서 열림)

GitLab 18.10은 AI 기반의 보안 기능을 강화하여 취약점 관리의 효율성을 획기적으로 높였습니다. GitLab Duo Agent 플랫폼을 통해 보안 탐지 결과의 노이즈를 줄이고 실제 위험에 집중하게 함으로써, 개발자가 보안 전문가가 아니더라도 신속하고 정확하게 취약점을 해결할 수 있는 환경을 제공합니다. 특히 정적 응용 프로그램 보안 테스트(SAST) 및 기밀 정보 탐지에서의 지능형 분석과 자동 수정 제안 기능이 핵심입니다. ### SAST 오탐 감지 및 분석 (정식 출시) * 기존 SAST 스캐너는 코드의 실행 맥락을 이해하지 못해 실제 위협이 아닌 코드도 경고를 띄우는 '오탐(False Positive)' 문제가 빈번했습니다. * GitLab Duo Agent는 LLM 기반의 추론을 통해 감지된 취약점이 실제 위협인지 아니면 안전한 코드인지를 분석합니다. * 취약점 리포트에 신뢰도 점수, AI가 작성한 판단 근거 설명, "오탐 가능성 높음/낮음"을 나타내는 시각적 배지를 제공하여 보안 팀이 중요한 문제에 먼저 집중할 수 있도록 돕습니다. ### 에이전트 기반 취약점 자동 수정 (베타) * 식별된 취약점을 확인하는 단계에서 더 나아가, AI가 직접 코드 수정안을 포함한 병합 요청(Merge Request)을 자동으로 생성합니다. * AI 에이전트가 코드 저장소의 주변 문맥을 읽고 고품질의 패치를 생성한 뒤, 자동화된 테스트를 통해 수정 사항이 안전한지 검증합니다. * 생성된 병합 요청에는 구체적인 코드 변경 사항과 함께 변경 이유에 대한 AI의 설명이 포함되어 개발자의 검토 및 반영 속도를 높여줍니다. ### 기밀 정보(Secret) 탐지의 정확도 향상 (베타) * 테스트용 자격 증명이나 예시 토큰과 같은 더미 데이터가 실제 보안 위협으로 분류되어 발생하는 리포트 노이즈를 제거합니다. * 기본 브랜치에서 스캔을 실행할 때 각 발견 항목을 분석하여 실제 노출된 기밀인지 아니면 테스트용 값인지를 구분하고 신뢰도 점수를 부여합니다. * 개발자는 취약점 리포트에서 수동으로 '오탐 확인'을 요청하여 보안 위험이 없는 항목을 빠르게 정리하고 실제 유출 사고에 즉각 대응할 수 있습니다. GitLab 18.10의 새로운 AI 보안 기능은 취약점의 탐지부터 해결까지의 전체 워크플로우를 자동화하여 개발 주기를 단축합니다. GitLab Ultimate 사용자는 GitLab Duo Agent 플랫폼을 통해 보안 검증 시간을 줄이고 코드의 안전성을 강화할 수 있으며, 무료 트라이얼을 통해 이러한 지능형 보안 워크플로우를 직접 경험해 보는 것을 추천합니다.