AI가 오픈소스 개발 속도를 높이는 동시에, 유지관리자가 감당해야 할 보안 문제도 빠르게 늘리고 있다. 익숙하지 않은 기여 코드를 검토하고, 새 공격 표면을 파악하며, 제한된 시간 안에 취약점과 노출된 비밀 정보를 처리해야 하기 때문이다. GitHub Secure Open Source Fund의 네 번째 세션은 이 문제를 도구 하나로 해결하려 하지 않았다. AI 보조 워크플로, 유지관리자의 전문성, GitHub 보안 기능, 보안 전문가의 조언, 자금 지원을 함께 묶어 50개 프로젝트의 보안 개선을 시도했다.
가장 중요한 결론은 단순하다. AI는 조사와 우선순위 결정, 대응 속도를 높일 수 있지만 무엇을 실제로 배포할지 판단하고 그 결과를 책임지는 주체는 여전히 사람이라는 것이다. 개인 프로젝트든 대규모 오픈소스든, AI가 생성한 수정안을 곧바로 병합하는 것보다 사람이 프로젝트의 구조와 위협 모델을 바탕으로 검증하는 과정이 더 중요해졌다.
50개 프로젝트에서 확인된 변화
네 번째 세션에는 22개국의 유지관리자 71명이 참여했고, 50개 프로젝트에 총 50만 달러가 넘는 비희석성 자금이 GitHub Sponsors를 통해 지원됐다. 참여 프로젝트의 92%는 프로그램을 마칠 때 핵심 GitHub 보안 기능을 활성화한 상태였다. 원문이 핵심 기능으로 제시한 항목은 시크릿 스캐닝, 코드 스캐닝, 보호된 브랜치, 비공개 취약점 신고, Dependabot이다.
중요한 점은 기능을 켠 것 자체보다 이를 프로젝트 운영 절차에 연결했다는 데 있다. 취약점이 발견됐을 때 누가 확인하고, 어느 경로로 신고받으며, 수정 브랜치를 어떻게 보호하고, 의존성 업데이트를 언제 병합할지 정하지 않으면 보안 경고는 쌓이기만 한다. 반대로 책임자와 처리 기준이 명확하면 자동 탐지 도구와 AI가 유지관리자의 시간을 실제로 절약할 수 있다.
프로그램 전체 세션과 2026년 8월까지의 후속 기간을 합치면 42개국에서 188개 프로젝트와 유지관리자 290명이 참여했다. GitHub와 Microsoft, 외부 자금 지원 파트너가 제공한 금액은 총 188만 달러이며, 참여 프로젝트는 새 CVE 533건을 찾아 공개하고 Dependabot 보안 업데이트를 1,500건 넘게 수행했으며 노출된 비밀 정보 650건 이상을 해결했다. 2026년 7월까지의 최근 6개월 동안에는 참여 프로젝트와 수료 프로젝트가 CodeQL 경고 4,210건을 수정하고 비밀 정보 119건의 노출을 차단했다.
이 수치는 모든 오픈소스 프로젝트가 같은 결과를 얻는다는 보장이 아니다. 전문가 지원, 교육, 자금, 전용 커뮤니티가 결합된 프로그램의 성과이기 때문이다. 자신의 저장소에 적용할 때는 숫자를 목표로 복제하기보다 탐지부터 검토, 수정, 공개까지 이어지는 운영 구조를 참고하는 편이 적절하다.
AI가 맡기 좋은 일과 사람이 남겨야 할 판단
참여 프로젝트들은 GitHub Copilot 같은 도구를 취약점 분류, 위협 모델링, 코드 리뷰, 수정 작업에 활용할 가능성을 탐색했다. 이런 작업은 반복적인 정보 수집과 후보 정리에 AI를 붙이기 좋다. 예를 들어 경고의 관련 코드와 의존성을 찾거나, 예상 공격 경로를 정리하거나, 수정 후보와 테스트 항목을 제안받는 방식이다.
그러나 AI가 제안한 결과는 프로젝트 맥락을 완전히 반영하지 못할 수 있다. 공개 API의 호환성, 지원 중인 런타임, 릴리스 일정, 실제 배포 환경, 사용자가 의존하는 비공식 동작까지 고려하려면 유지관리자의 판단이 필요하다. 보안 수정처럼 영향 범위가 큰 변경에서는 그럴듯한 패치보다 검증 가능한 근거가 우선이다.
| 작업 | AI에 기대할 수 있는 역할 | 사람이 확인할 기준 |
|---|---|---|
| 취약점 분류 | 관련 파일과 호출 경로를 찾고 경고를 요약 | 실제 악용 가능성, 노출 범위, 대응 우선순위 |
| 위협 모델링 | 자산, 진입점, 공격 시나리오 후보를 정리 | 운영 환경과 신뢰 경계가 정확히 반영됐는지 검토 |
| 코드 리뷰 | 위험 패턴과 누락된 검증 로직을 제안 | 오탐 여부, 호환성, 테스트 범위, 회귀 가능성 |
| 수정안 작성 | 패치와 테스트 초안을 생성 | 근본 원인 해결 여부와 우회 경로, 롤백 가능성 |
| 보안 공지 | 영향 범위와 대응 절차를 구조화 | 공개 시점, CVE 정보, 사용자에게 필요한 조치의 정확성 |
OpenClaw 사례에서 볼 수 있는 운영 단위
GitHub는 빠르게 성장한 오픈소스 프로젝트인 OpenClaw를 네 번째 세션에 초대했다. 유지관리자들은 프로그램이 끝날 때까지 사고 대응 계획을 만들고, GitHub 보안 도구의 사용 범위를 넓히며, GitHub Actions 워크플로를 감사했다. 보안 문제를 식별하고 대응하는 절차도 강화했다.
이 사례에서 개인 개발자와 소규모 팀이 가져올 수 있는 핵심은 거대한 보안 체계를 한 번에 구축하는 것이 아니다. 먼저 사고가 발생했을 때의 연락 경로와 판단 책임자를 정하고, 자동화 워크플로가 가진 권한을 점검한 뒤, 탐지된 문제를 처리하는 흐름을 문서화하는 것이다. 특히 GitHub Actions는 저장소 쓰기 권한, 배포 자격 증명, 외부 액션과 연결될 수 있으므로 단순한 빌드 설정 파일로 취급해서는 안 된다.
프로젝트 유형에 따라 달라지는 우선순위
참여 대상에는 AI·머신러닝 시스템뿐 아니라 빌드 도구, 공급망 및 릴리스 도구, 프로그래밍 언어와 런타임, 기반 라이브러리, 개발 생산성 도구가 포함됐다. LangChain, ONNX, OpenClaw 같은 AI 관련 프로젝트부터 browserslist, CycloneDX Python Library, golangci-lint, JReleaser, core-js, Pyodide, htmx, Pillow, Hoppscotch, Vuetify, Yjs 등 서로 다른 역할의 프로젝트가 함께 참여했다.
프로젝트가 맡는 역할에 따라 먼저 살펴볼 위험도 달라진다.
- AI·자동화 프로젝트: 모델이나 에이전트가 호출할 수 있는 도구의 권한, 외부 입력 처리, 프롬프트를 통한 간접 명령, 데이터 유출 경로를 확인한다.
- 빌드·릴리스 도구: 패키지 생성과 서명, 게시 권한, CI 토큰, 외부 액션 및 의존성 고정 여부를 우선 점검한다.
- 언어·런타임·기반 라이브러리: 작은 변경이 많은 하위 프로젝트에 전파될 수 있으므로 호환성 테스트와 보안 공지 절차를 강화한다.
- 개발자 도구와 협업 플랫폼: 사용자 입력, 인증 정보, 플러그인이나 확장 기능, 외부 API 연결에서 신뢰 경계를 찾는다.
내 저장소에 적용할 때 확인할 순서
- 보호할 자산을 먼저 적는다. 소스 코드만이 아니라 패키지 게시 권한, CI 자격 증명, 배포 키, 사용자 데이터, 보안 제보자의 정보도 포함한다.
- 저장소 권한을 확인한다. 기본 브랜치의 직접 푸시와 병합 조건, 관리자 우회 권한, 외부 기여자의 워크플로 실행 범위를 살펴본다.
- 자동 탐지 기능의 적용 범위를 확인한다. 시크릿 스캐닝, 코드 스캐닝, Dependabot, 비공개 취약점 신고를 현재 저장소와 계정에서 사용할 수 있는지 공식 문서에서 확인한다. 공개·비공개 저장소나 계정 유형에 따라 조건이 다를 수 있으므로 기능 이름만 보고 적용 가능하다고 단정하면 안 된다.
- GitHub Actions를 별도로 감사한다. 워크플로 권한이 필요한 최소 수준인지, 외부 액션이 변경 가능한 참조를 사용하지 않는지, 비밀 정보가 로그나 포크 기반 실행에 노출될 가능성이 없는지 검토한다.
- 경고 처리 기준을 정한다. 심각도만 보지 말고 실제 접근 가능성, 사용 중인 코드 경로, 배포 환경, 수정에 따른 회귀 위험을 함께 평가한다.
- 비공개 신고 경로와 사고 대응 계획을 마련한다. 제보 접수, 재현, 영향 분석, 수정, 배포, 공개, 사후 점검의 담당자와 순서를 기록한다.
- 작은 범위에서 AI 보조 흐름을 시험한다. 실제 비밀 정보나 민감한 연구 자료를 넣기 전에 공개 코드나 테스트 저장소에서 결과 품질, 오탐, 수정 횟수, 재현 가능성을 확인한다.
개인 사용자·학생·연구자가 놓치기 쉬운 점
개인 저장소라고 해서 공급망 위험이 작은 것은 아니다. 한 사람이 관리하는 패키지도 다른 프로젝트의 직접 또는 간접 의존성이 될 수 있다. 저장소가 유명하지 않더라도 패키지 게시 토큰이나 클라우드 키가 노출되면 피해 범위가 저장소 밖으로 확대될 수 있다. 최소한 기본 브랜치 보호, 자동 의존성 경고, 비밀 정보 탐지, 복구 가능한 배포 절차를 검토할 이유가 있다.
학생은 실습 편의를 위해 토큰을 코드에 넣거나 과도한 권한을 가진 워크플로를 복사하기 쉽다. 예제 저장소라도 커밋 기록에 남은 자격 증명은 파일을 지우는 것만으로 해결되지 않을 수 있으므로 해당 자격 증명의 폐기와 재발급 여부까지 확인해야 한다.
연구자는 아직 공개하지 않은 데이터와 논문 자료, 실험용 API 키를 다룰 수 있다. AI 코드 도구를 도입하기 전에는 입력 데이터의 처리와 보존 조건, 조직 계정의 정책, 저장소 접근 권한을 확인해야 한다. 제공된 원문은 개별 도구의 데이터 보존 정책이나 요금 조건을 설명하지 않으므로, 실제 적용 조건은 사용하는 서비스의 최신 공식 문서에서 별도로 검증해야 한다.
도입 효과를 판단하는 기준
보안 도구의 가치는 경고 수가 늘어나는 데 있지 않다. 발견된 문제를 검토하고 해결할 수 있어야 한다. 먼저 저장소 하나나 워크플로 하나를 대상으로 시험하고, 도입 전후의 탐지 누락, 오탐, 검토 시간, 수정 완료 시간, 재발 여부를 기록하는 방식이 현실적이다.
AI 기능도 같은 기준으로 평가할 수 있다. 취약점 설명을 빠르게 요약했더라도 사람이 사실관계를 다시 조사하는 시간이 더 늘었다면 효과가 제한적이다. 반대로 관련 코드 탐색이나 테스트 후보 작성 시간을 줄이고, 유지관리자가 더 중요한 판단에 집중하게 했다면 반복 가능한 워크플로로 확장할 가치가 있다.
GitHub의 프로그램은 3주간의 집중 과정과 총 12개월의 참여 기간으로 구성된다. 보안 기초, 위협 모델링과 안전한 코딩, AI 보안과 취약점 관리가 교육 주제에 포함되며, 이후 보안 점검과 전문가 상담, 커뮤니티 지원이 이어진다. 이는 보안 개선이 기능을 한 번 켜는 작업이 아니라 학습, 적용, 확인을 반복하는 과정이라는 점을 보여준다.
적용 전 최종 체크포인트
- AI가 만든 분석이나 패치를 승인할 사람과 책임 범위가 정해져 있는가?
- 기본 브랜치와 릴리스 작업에 필요한 최소 권한이 적용돼 있는가?
- 시크릿·코드·의존성 경고가 발생했을 때 확인할 담당자와 처리 기한이 있는가?
- 외부 기여와 자동화 워크플로가 자격 증명에 접근하는 경로를 점검했는가?
- 비공개 취약점 신고를 받고 안전하게 소통할 절차가 있는가?
- 수정안을 병합하기 전에 재현 테스트와 회귀 테스트를 실행할 수 있는가?
- 사용하려는 보안 및 AI 기능이 현재 계정 유형과 저장소에 제공되는지 확인했는가?
- 민감한 코드와 데이터의 처리·보존·공유 조건을 공식 문서에서 검증했는가?
이번 사례가 보여주는 방향은 “AI가 보안을 대신한다”가 아니다. 자동화와 AI가 탐색 범위를 넓히고 반복 작업을 줄이는 동안, 유지관리자는 프로젝트 맥락에 맞는 우선순위를 정하고 결과를 검증해야 한다. 도구, 전문가 지원, 자금, 동료 커뮤니티가 함께 작동했을 때 보안 기능이 실제 운영 개선으로 이어졌다는 점이 50개 프로젝트에서 얻을 수 있는 가장 실용적인 교훈이다.
출처와 검증
프로그램 구성, 참여 규모, 지원 금액과 보안 성과는 2026년 8월 13일 공개된 GitHub Blog의 What 50 open source projects taught us about security in the AI era를 기준으로 정리했다. 기능 제공 범위와 계정별 조건은 변경될 수 있으므로 실제 적용 전 GitHub의 최신 공식 문서를 함께 확인해야 한다.