codeql

당신의 코드는 얼마나 노출되어 있나요? 단 몇 분 만에 무료로 확인해 보세요 (새 탭에서 열림)

대부분의 코드베이스에는 아직 발견되지 않은 보안 취약점이 존재하며, 수동 검토나 제한적인 도구만으로는 이를 파악하기 어렵다. GitHub는 조직의 활성 저장소를 몇 분 안에 점검하는 무료 **Code Security Risk Assessment**를 공개했다. 이 assessment는 CodeQL로 취약점을 찾고, 위험도와 언어·저장소별 분포, Copilot Autofix 적용 가능성까지 보여줘 보안 대응 우선순위를 정하도록 돕는다. ## Code Security Risk Assessment의 기능 - GitHub의 정적 분석 엔진인 **CodeQL**을 사용해 조직에서 가장 활발한 저장소 최대 20개를 검사한다. - 별도 라이선스 구매나 설정 없이 원클릭으로 실행할 수 있다. - 다음 정보를 대시보드로 제공한다. - 전체 취약점 수와 심각도별 분류: Critical, High, Medium, Low - 프로그래밍 언어별 취약점 분포 - 발견된 보안 규칙과 해당 규칙의 영향 저장소 수 - 취약점이 가장 많은 저장소 - Copilot Autofix로 자동 수정할 수 있는 취약점 수 - GitHub Enterprise Cloud 및 GitHub Team 플랜의 조직 관리자와 보안 관리자가 사용할 수 있다. - 스캔에 사용된 GitHub Actions 실행 시간은 사용량 할당량에서 차감되지 않는다. ## 시크릿과 코드 취약점을 함께 파악 - 기존의 **Secret Risk Assessment**는 저장소에 노출된 인증 정보와 자격 증명을 파악하는 기능이다. - Code Security Risk Assessment는 소스 코드 자체의 취약점을 분석한다. - 두 assessment는 하나의 진입점과 탭 기반 화면에서 함께 실행할 수 있다. - 이를 통해 조직은 다음 두 가지 위험을 통합적으로 확인할 수 있다. - 유출된 시크릿 및 자격 증명 - 애플리케이션 코드의 보안 취약점 - GitHub는 2025년에 Secret Protection 사용 고객들이 약 20억 건의 push를 검사하고, 약 1,900만 건의 시크릿 노출을 차단했다고 설명한다. ## 취약점 발견에서 수정까지 - 취약점을 찾는 것만으로는 충분하지 않으며, 실제 수정 속도가 위험 감소에 중요하다. - GitHub Code Security와 Copilot Autofix는 개발자가 작업하는 pull request 안에서 취약점을 수정하도록 지원한다. - GitHub가 제시한 2025년 수치는 다음과 같다. - Copilot Autofix로 수정된 보안 경고: **460,258건** - pull request에서 직접 해결된 취약점 경고: **50%** - 평균 해결 시간: - Copilot Autofix 사용: **0.66시간** - 수동 수정: **1.29시간** - assessment 결과에서 Copilot Autofix를 적용할 수 있는 취약점 수를 확인하고, 결과 화면에서 GitHub Code Security를 바로 활성화할 수 있다. ## 어떤 조직에 유용한가 - 보안 스캔을 아직 도입하지 않은 조직이 현재 위험 수준을 빠르게 파악할 수 있다. - 기존 보안 도구를 사용하는 조직도 다른 관점에서 코드베이스 전체를 점검할 수 있다. - 여러 팀과 언어로 구성된 조직에서 취약점이 집중된 저장소와 기술 영역을 식별하는 데 유용하다. - 평가 결과를 바탕으로 어떤 제품이나 보안 기능을 도입할지 판단할 수 있다. - Secret Protection: 자격 증명 유출 방지 - Code Security: 코드 취약점 탐지 및 수정 우선 무료 assessment를 실행해 조직의 취약점 분포와 우선순위를 확인하는 것이 좋다. 이후 반복적인 스캔과 pull request 기반 수정 프로세스를 도입하면 일회성 점검을 지속적인 보안 관리로 발전시킬 수 있다.

GitHub 전반의 오픈 소스 공급망 보안 강화 (새 탭에서 열림)

공격자들은 GitHub Actions 워크플로를 침해해 API 키 같은 비밀을 탈취한 뒤, 악성 패키지를 배포하고 더 많은 프로젝트로 공격을 확산시키고 있다. 이에 대응하려면 Actions 워크플로를 CodeQL로 점검하고, 서드파티 액션을 커밋 SHA로 고정하며, 장기 비밀 대신 OIDC 기반 인증과 trusted publishing을 사용해야 한다. GitHub는 npm 악성코드 탐지와 Actions·npm 보안 로드맵을 강화하고 있지만, 오픈소스 생태계 전반의 지속적인 협력이 필요하다고 강조한다. ## GitHub Actions 워크플로가 공격의 출발점 - 최근 오픈소스 공급망 공격은 GitHub Actions 워크플로의 취약점을 찾는 방식으로 시작되는 경우가 많다. - 공격자는 워크플로에서 API 키, 토큰, 배포 자격 증명 등의 비밀을 탈취한다. - 탈취한 자격 증명으로: - 공격자가 통제하는 환경에서 악성 패키지를 배포하고 - 해당 패키지를 이용해 다른 프로젝트와 계정으로 공격을 확산한다. ## 지금 적용할 수 있는 Actions 보안 조치 - 공개 저장소에서 무료로 사용할 수 있는 **CodeQL의 GitHub Actions 분석 기능**을 활성화한다. - 워크플로 구현상의 보안 취약점과 보안 모범 사례 위반을 점검할 수 있다. - `pull_request_target`을 사용하지 않는다. - 외부 기여자의 코드가 높은 권한의 워크플로 컨텍스트에서 실행될 위험이 있다. - 서드파티 GitHub Actions를 전체 길이의 커밋 SHA로 고정한다. - 태그나 브랜치는 이후 다른 코드로 변경될 수 있지만, SHA 고정은 특정 코드 버전을 보장한다. - 이 변경은 저장소 관리자나 Dependabot이 수행해야 하며, 외부 Pull Request가 액션 버전 고정을 바꾸려 하면 주의해야 한다. - 사용자 입력을 셸 명령이나 스크립트에 직접 삽입하지 않는다. - 이 방식은 스크립트 인젝션으로 이어질 수 있다. - 침해된 의존성은 GitHub Advisory Database에서 확인한다. - Dependabot을 사용해 악성 또는 취약한 의존성에 대한 알림을 받는다. ## 비밀 대신 OIDC와 trusted publishing 사용 - 워크플로에 장기 보관되는 비밀을 넣는 대신, **OpenID Connect(OIDC) 토큰**을 사용할 수 있다. - OIDC 토큰에는 실행 중인 워크로드의 신원이 포함되므로, 클라우드 제공업체·패키지 저장소·호스팅 서비스가 해당 워크플로를 검증하고 권한을 부여할 수 있다. - GitHub와 OpenSSF는 이를 패키지 저장소의 **trusted publishing**으로 확산하고 있다. - 현재 npm, PyPI, NuGet, RubyGems, Crates 등 여러 저장소에서 지원된다. - trusted publishing의 장점: - 빌드 파이프라인에서 장기 비밀을 제거한다. - 패키지가 어떤 신뢰된 워크플로에서 배포됐는지 확인할 수 있다. - 패키지가 갑자기 trusted publishing을 중단하면, 탈취된 자격 증명을 이용한 공격 가능성을 조사하는 신호가 된다. ## npm의 악성 패키지 탐지 - npm에서는 매일 3만 개가 넘는 패키지가 배포된다. - GitHub는 모든 npm 패키지 버전을 악성코드 관점에서 검사한다. - 탐지 규칙은 공격 방식의 변화에 맞춰 지속적으로 개선된다. - 매일 수백 개의 신규 배포 패키지에서 악성 코드가 발견될 수 있으며, 실제 조치 전에는 사람이 양성 여부를 검토한다. - 오탐률이 1%만 되어도 매일 수백 개의 정상 패키지 배포가 중단될 수 있으므로, 자동 탐지와 사람의 검증 사이 균형이 중요하다. ## Shai-Hulud 이후의 보안 로드맵 - 2025년 말 발생한 Shai-Hulud 공격은 npm 보안 로드맵을 재정비하는 계기가 됐다. - GitHub는 다음 작업을 가속했다. - npm trusted publishing 확대 - 악성코드 탐지 및 제거 기능 강화 - 오픈소스 유지관리자와의 보안 요구사항 논의 - 보안 변경은 기존 워크플로를 수정하게 만들거나 하위 호환성을 깨뜨릴 수 있으므로, GitHub는 생태계가 원활하게 전환할 수 있도록 지원할 계획이다. - 최근 공격을 계기로 GitHub Actions 보안 로드맵도 재검토하고, 이미 진행 중인 보안 기능의 출시를 앞당기고 있다. ## 오픈소스 생태계의 공동 대응 - 오픈소스는 전 세계가 공유하는 공공재인 만큼 공격이 앞으로도 계속될 가능성이 높다. - GitHub는 npm과 GitHub Actions를 비롯해 향후 등장할 새로운 공격 경로까지 방어 범위를 확대하겠다고 밝혔다. - 효과적인 보안 기능을 만들기 위해 유지관리자와 커뮤니티의 피드백이 중요하다. 실무적으로는 먼저 CodeQL로 Actions를 검사하고, `pull_request_target` 제거·커밋 SHA 고정·스크립트 인젝션 점검을 진행하는 것이 좋다. 이후 가능하면 OIDC와 trusted publishing으로 배포 인증을 전환해, 탈취 가능한 장기 비밀 자체를 줄여야 한다.

깃허브, AI 기반 탐지 기능으로 애플리케이션 보안 범위 확장 (새 탭에서 열림)

GitHub는 AI 기반 보안 탐지를 도입해 CodeQL만으로는 충분히 다루기 어려운 언어와 프레임워크까지 애플리케이션 보안 범위를 확장한다. 이 기능은 풀 리퀘스트에서 취약점을 탐지하고 Copilot Autofix로 수정안까지 제안해, 코드 병합 전에 위험을 발견·해결하는 것을 목표로 한다. 공개 프리뷰는 2026년 2분기 초에 제공될 예정이다. ## CodeQL과 AI 탐지를 결합한 보안 검사 - CodeQL은 지원 언어에 대해 깊은 의미 분석을 제공하는 기존 정적 분석 엔진이다. - 현대 저장소에는 Shell/Bash 스크립트, Dockerfile, Terraform(HCL), PHP 등 다양한 생태계의 코드가 함께 포함된다. - GitHub는 CodeQL과 AI 기반 탐지를 결합한 하이브리드 모델로 이러한 영역까지 보안 검사 범위를 넓힌다. - AI 탐지는 전통적인 정적 분석으로 지원하기 어려운 코드에서 잠재적 취약점과 수정 제안을 찾아낸다. - 내부 테스트에서 30일 동안 17만 건 이상의 결과를 처리했으며, 개발자 긍정 피드백 비율은 80%를 넘었다. - 이 기능은 보안·코드 품질·코드 리뷰를 지원하는 GitHub의 에이전트형 탐지 플랫폼을 기반으로 한다. ## 풀 리퀘스트에서 취약점 조기 발견 - 풀 리퀘스트가 생성되면 GitHub Code Security가 변경 사항에 적합한 방식을 자동으로 선택해 분석한다. - 지원 언어에는 CodeQL 정적 분석을 사용한다. - 추가 생태계에는 AI 기반 보안 탐지를 적용한다. - 결과는 기존 코드 스캐닝 결과와 함께 풀 리퀘스트 안에 표시된다. - 탐지 대상에는 다음과 같은 문제가 포함된다. - 안전하지 않은 문자열 결합 방식의 SQL 쿼리나 명령어 - 취약한 암호화 알고리즘 - 민감한 리소스를 노출하는 인프라 구성 - 개발자는 별도 보안 도구로 이동하지 않고 코드 리뷰 과정에서 위험을 확인할 수 있다. ## Copilot Autofix를 통한 수정 자동화 - 취약점을 찾는 것뿐 아니라 빠르고 안전하게 수정하는 것도 보안 운영의 핵심이다. - Copilot Autofix는 탐지 결과를 바탕으로 개발자가 검토·테스트·적용할 수 있는 수정안을 제안한다. - 2025년 Autofix는 46만 건 이상의 보안 경고 해결에 사용됐다. - Autofix를 사용한 경우 평균 해결 시간은 0.66시간으로, 사용하지 않은 경우의 1.29시간보다 짧았다. - 탐지와 자동 수정 제안을 연결해 취약점 발견부터 해결까지의 시간을 줄인다. ## 병합 시점의 보안 정책 적용 - GitHub는 코드가 검토되고 승인되는 병합 지점에서 보안 결과를 통제할 수 있도록 한다. - 보안 탐지, 수정 제안, 정책 집행을 풀 리퀘스트에 통합하면 배포 이후가 아니라 병합 전에 위험을 차단할 수 있다. - 팀은 개발자가 기존 워크플로를 벗어나지 않으면서 보안 기준을 적용할 수 있다. - 장기적으로는 정적 분석의 정확성과 AI의 맥락 이해를 결합한 더 발전된 탐지 체계로 확장될 예정이다. 실무에서는 CodeQL이 지원하는 핵심 언어뿐 아니라 Shell, Docker, Terraform, PHP 등을 사용하는 저장소에도 해당 기능을 검토할 만하다. 다만 AI가 제안한 수정안은 반드시 개발자가 코드 의도와 테스트 결과를 확인한 뒤 병합하는 것이 좋다.

GitHub Security Lab의 오픈 소스 (새 탭에서 열림)

GitHub Security Lab은 오픈 소스 AI 프레임워크인 **Taskflow Agent**와 웹 보안 감사용 taskflow를 활용해 80건 이상의 취약점을 발견했으며, 그중 상당수는 인증 우회와 민감 정보 노출처럼 영향도가 높은 취약점이었다고 설명합니다. 이 방식은 대형 단일 프롬프트 대신 여러 단계의 작업을 YAML로 정의하고, LLM의 분석 결과를 데이터베이스로 전달해 반복적·구조적인 보안 감사를 수행합니다. 프레임워크와 taskflow는 공개되어 있어 GitHub Copilot 사용자는 자신의 저장소에서도 실행할 수 있습니다. ## 오픈 소스 AI 보안 감사의 성과 - 새로운 taskflow는 웹 애플리케이션 취약점 탐색에 특화되어 있습니다. - 지금까지 80건 이상의 취약점을 보고했으며, 작성 시점에 약 20건이 공개되었습니다. - 발견된 취약점의 상당수는 다음과 같은 고위험 유형입니다. - 인증 또는 권한 우회 - 다른 사용자로 로그인할 수 있는 문제 - 다른 사용자의 비공개 데이터에 접근하는 정보 노출 - 글에서 제시한 사례로는 다음이 언급됩니다. - 전자상거래 애플리케이션의 장바구니에서 개인식별정보(PII) 접근 - 채팅 애플리케이션에서 어떤 비밀번호를 사용해도 로그인 가능한 문제 - 연구자들은 기존에 악용 가능성이 불분명한 후보를 검증하는 데 쓰던 시간을 줄이고, 실제 결과를 수동 검증하고 보고하는 데 더 집중할 수 있게 되었다고 설명합니다. ## 자신의 저장소에서 실행하는 방법 - `GitHubSecurityLab/seclab-taskflows` 저장소에서 Codespace를 시작합니다. - 초기화가 끝난 뒤 다음 명령을 실행합니다. ```bash ./scripts/audit/run_audit.sh myorg/myrepo ``` - 중간 규모 저장소에서는 실행에 한두 시간이 걸릴 수 있습니다. - 완료되면 SQLite 뷰어가 열리고, `audit_results` 테이블에서 `has_vulnerability` 열이 체크된 행을 확인합니다. - 실행에는 GitHub Copilot 라이선스가 필요하며, 프리미엄 모델 요청 할당량을 많이 사용할 수 있습니다. - LLM 결과는 비결정적이므로 같은 코드베이스를 여러 번 검사하는 것이 권장됩니다. - 서로 다른 모델을 사용하면 결과가 달라질 수 있습니다. - 예시로 GPT 5.2와 Claude Opus 4.6을 각각 사용할 수 있습니다. - 비공개 저장소도 지원하지만, Codespace 설정을 수정해 접근 권한을 별도로 부여해야 합니다. ## Taskflow의 구조 - Taskflow는 LLM에 수행시킬 작업 목록을 YAML로 정의한 파일입니다. - `seclab-taskflow-agent`가 다음 기능을 담당합니다. - 작업을 순차적으로 실행 - 앞선 작업의 결과를 다음 작업에 전달 - 여러 구성 요소에 같은 작업을 비동기적으로 반복 실행 - 템플릿 프롬프트에 구성 요소별 정보를 삽입 - 저장소 감사는 일반적으로 다음 단계로 나뉩니다. - 저장소를 기능별 구성 요소로 분할 - 각 구성 요소의 진입점, 신뢰할 수 없는 입력, 요구 권한, 역할 등을 분석 - 분석 결과를 `repo_context.db` 같은 데이터베이스에 저장 - 저장된 컨텍스트를 사용해 취약점 후보를 생성 - 후보별로 세부 검증을 수행 - 현재는 각 구성 요소에 대해 일반적인 보안 문제를 제안하는 작업과, 제안된 문제를 정밀하게 검증하는 작업이 사용됩니다. - 특정 취약점 유형에 집중하는 별도의 taskflow도 추가할 수 있습니다. ## 하나의 거대한 프롬프트 대신 여러 작업을 사용하는 이유 - LLM의 컨텍스트 창에는 한계가 있습니다. - 복잡한 작업을 하나의 프롬프트에 모두 넣으면 일부 단계가 누락되거나 제대로 수행되지 않을 수 있습니다. - 작업을 분리하면 다음과 같은 장점이 있습니다. - 각 단계의 결과를 개별적으로 확인 가능 - 실패하거나 잘못된 단계를 디버깅하기 쉬움 - 이전 분석 결과를 후속 작업의 컨텍스트로 재사용 가능 - 여러 코드 구성 요소에 동일한 분석을 일관되게 적용 가능 - 더 큰 컨텍스트 창을 지원하는 모델에서도, 작업 흐름을 통제하고 검증하기 위해 taskflow 방식이 유용하다고 설명합니다. ## 일반 보안 코드 감사에서의 과제 - 초기에는 CodeQL 경고 분류처럼 범위와 판단 기준이 명확한 작업에 Taskflow Agent를 사용했습니다. - 이후 특정 경고에 한정하지 않고 일반적인 취약점까지 찾는 방식으로 확장했습니다. - LLM에 더 많은 자유를 주면 다음 문제가 커집니다. - 환각 - 오탐 - 검증하기 어려운 취약점 보고 - CodeQL 경고 분류가 효과적이었던 이유는 지시와 판정 기준이 엄격하고, 각 단계에서 결과가 요구사항을 충족하는지 확인할 수 있었기 때문입니다. - 따라서 목표는 LLM이 다양한 취약점을 자유롭게 탐색하게 하면서도 taskflow 설계와 프롬프트 엔지니어링으로 환각과 오탐을 통제하는 것입니다. ## 실용적인 권장 사항 실제 프로젝트에 적용할 때는 한 번의 실행 결과를 확정적인 보안 보고서로 취급하지 말고, 여러 모델과 반복 실행으로 후보를 수집한 뒤 사람이 재현 가능성과 악용 가능성을 검증하는 것이 좋습니다. 또한 저장소 전체를 한 번에 분석하기보다 기능별 구성 요소와 단계별 taskflow로 나누면 결과를 추적하고 수정하기 쉽습니다.