GitGalaxy

문서 · 시각화 도구

1회 스캔 · 97가지 구조 신호 · 50개 이상 언어 · 컴파일 불필요
19가지 위험 노출 점수 · 6가지 최종 보고서 · 의존성 0개 · pip install gitgalaxy

어떤 문제를 해결하나?

GitGalaxy는 반복적으로 발생하는 하나의 문제를 위해 존재합니다: 깨끗하게 컴파일되지 않는 대규모의 실제 다중 언어 코드베이스를 이해하는 것 — 대부분의 정적 분석 도구가 가정하는 깨끗한 단일 언어 입력이 아니라, 대부분의 프로덕션 저장소가 실제로 처해 있는 상태입니다.

• 한 번의 패스로 50개 이상 언어에 걸친 전체 시스템 스캔. 언어별 툴체인이 필요 없고, 성공적인 빌드도 필요 없습니다. Go, YAML, Shell, Python이 섞여 있는 폴리글랏 저장소는 다섯 번의 개별 도구 호출이 아니라 하나의 시스템으로 스캔됩니다.
• 컴파일은 절대 불필요. 깨진 의존성, 누락된 패키지, 단절된 vendor 코드, 절반만 마이그레이션된 레거시 모듈 — 이 모든 것이 깨끗한 저장소와 동일한 방식으로 스캔됩니다. 여기서는 아무것도 먼저 빌드할 필요가 없기 때문입니다.
• 모든 커밋에서 실행할 수 있을 만큼 빠름. 대부분의 저장소는 1분보다 훨씬 짧은 시간에 스캔됩니다 — Kubernetes는 Go, YAML, JSON, Shell, Proto에 걸친 139만 줄을 처음부터 끝까지 50.83초 만에 스캔합니다. 스캔 시간은 599개 저장소 배치에서 두 개의 구간으로 피팅됩니다 — 약 4,258 LOC 이하에서는 평평한 오버헤드, 그 이상에서는 time(s) ≈ 3.36e-05 × LOC^0.969 (R²=0.88, 거의 선형, 큰 입력에서도 저하되지 않음) — 반올림된 헤드라인만이 아니라 차트와 유도 과정은 주장만이 아닌 증명을 참조하세요.
• 독립형 보고서가 아닌 CI 네이티브 출력. 모든 스캔은 SARIF 파일(GitHub/GitLab 보안 대시보드에 바로 연동), CycloneDX SBOM(의존성 컴플라이언스), 그리고 파일·폴더·저장소별 0–100 위험 노출 점수를 생성합니다. 각 항목의 실제 검증 가능한 예시는 벤치마크를 참조하세요.

이것은 CodeQL, Semgrep 또는 SonarQube와 경쟁하는 취약점 스캐너가 아닙니다. 그 도구들은 코드가 컴파일된 이후에 깊고 정밀한 분석을 수행하며, 보통 한 번에 한 언어씩 다룹니다. GitGalaxy는 그보다 먼저 다른 질문에 답합니다 — 이 전체 시스템이 실제로 어떻게 생겼는지, 위험이 어디에 집중되어 있는지 — 더 깊은 도구들이 작업할 빌드를 확보하기도 전에 저장소의 모든 언어를 동시에 살펴봅니다. 각 도구의 역할이 정확히 어디서 시작되고 끝나는지는 아래의 "아키텍처 관점에서 어떻게 비교되는가"를 참조하세요.

Gitgalaxy는 50개 이상의 서로 다른 언어가 혼합된 전체 저장소를 평가하고, 아키텍처를 매핑하며, 우선순위가 매겨진 리팩토링 대상(핫스팟, 버스 팩터 위험, 하중 지지 파일)과 함께 위험 노출을 표면화하여 어디에 먼저 집중해야 할지 알려줍니다. 아래 그래프는 Apollo-11 1969년 비행 소프트웨어부터 현대 기술 스택에 이르는 샘플 코드 파일이 포함된 골든 테스트 저장소를 gitgalaxy로 한 번 스캔한 워크플로우입니다. 벤치마크

아키텍처 인텔리전스 — 하나의 그래프 위에 구축된 보안, 코드 탐색, 레거시 현대화

Gitgalaxy의 핵심 출력은 단 하나입니다: 저장소 전체의 결정론적 구조 그래프. 보안 감사, 리팩토링 우선순위 지정, 레거시-현대 언어 번역(아래 엔터프라이즈 코드베이스 도구 및 사용 사례 참조)은 모두 별도의 엔진을 가진 별도 제품이 아니라 동일한 그래프의 소비자입니다 — 그래서 이것은 단일 목적의 취약점 스캐너라기보다 아키텍처 인텔리전스 플랫폼에 더 가깝게 읽히는 이유입니다.

대부분의 코드 인텔리전스 엔진은 tree-sitter와 같은 AST를 사용하는데, 이는 저장소를 지나치게 세분화된 관점으로 보여주고(집을 이해하려 하는데 벽돌과 유리창 하나하나의 목록을 받는 것과 같음) 스캔할 수 있는 언어와 파일을 제한합니다. 현대 저장소는 다중 언어입니다. 많은 저장소에는 제대로 된 AST가 없는 오래된 코드가 있습니다. 이를 우회하기 위해 Gitgalaxy는 상단에 통계 레이어를 얹은 맞춤형 정규식/어휘 구조 분석 엔진을 사용합니다 — 함수의 경계, 제어 흐름, I/O, 상태 변이, 그리고 수십 가지의 기타 구조적·보안 관련 동작을 표시하는 약 97개 정규식 "신호" 범주에서 파일별 특징 벡터를 구축하고, 저장소별로는(import 해석 + PageRank/중심성 기반 의존성 그래프) 구축한 다음, sigmoid 함수를 통해 이러한 원시 카운트를 정규화된 0–100 위험 점수로 변환하고 그 결과를 6가지 형식으로 내보냅니다.

Gitgalaxy는 AST 수준의 정밀도를 수 배의 속도와 보편적인 언어 커버리지로 맞바꿉니다. 이는 BLAST가 유전체학에서 Smith-Waterman의 완전 탐색 정렬을 휴리스틱 속도로 맞바꾼 것과 같은 정신입니다. 출력에는 단일 스캔 패스로 생성된 SARIF, CycloneDX SBOM, 쿼리 가능한 SQLite 지식 그래프, LLM에 최적화된 아키텍처 브리프, 3D 시각화 데이터가 포함됩니다 — 막연한 형용사 대신 실제 스캔 시간 수치를 보려면 위의 "어떤 문제를 해결하나?"를 참조하세요.

그 결과는 코드를 컴파일할 것을 요구하지 않고 구축된 저장소의 결정론적 지식 그래프입니다. 테스트 코드와 핵심 로직의 비율을 계산하고, 의존성 그래프를 통해 각 파일의 다운스트림 "블래스트 반경"을 매핑하며, 라인 단위 린터가 완전히 놓치는 프로젝트 구조 신호를 표면화합니다. 파일별 신호 추출은 코드베이스 크기에 선형적인 시간으로 실행됩니다. 저장소 수준 그래프 메트릭(중심성, 커뮤니티 탐지)은 매우 큰 그래프에 명시적 샘플링 경계가 있는 표준 네트워크 분석 알고리즘을 사용합니다.

구조 그래프를 git 히스토리와 교차시키면 두 가지 구체적이고 우선순위가 매겨진 리팩토링 신호도 표면화됩니다: 버스 팩터 위험(거의 전적으로 한 명의 기여자가 소유한 하중 지지 파일)과 리팩토링 핫스팟(높은 변경 빈도, 높은 복잡성, 높은 기술 부채를 동시에 가진 파일 — 리팩토링 노력이 실제로 효과를 보는 위치를 알려주는 표준 신호)입니다. 둘 다 단순한 점수가 아니라 이름이 지정된 파일 수준 대상입니다.

blAST 엔진으로 Apollo-11 스캔하기

GitGalaxy가 찾아내는 것 — 그리고 주장하지 않는 것

GitGalaxy는 서로 다른 두 종류의 출력을 생성하며, 이 둘은 다르게 읽어야 합니다.

위험 노출 점수는 19개 범주(시크릿, 인젝션 표면, 메모리 손상 등)에 걸친 0–100 밀도 정규화 신호로, 함수에서 파일, 폴더, 저장소 순으로 집계됩니다. 높은 점수는 이것이 먼저 주목할 가치가 있다는 의미입니다 — 이는 평결이 아니라 우선순위 신호입니다. 두 파일이 완전히 다른 이유로 동일한 점수를 가질 수 있습니다: 실제 문제이거나, 표면적으로는 동일해 보이는 정당한 패턴일 수 있습니다. 암호화된 멀웨어와 잘 테스트된 암호화 루틴 모두 높은 엔트로피를 생성합니다. GitGalaxy는 어떤 것을 찾았는지 알려줄 수 없습니다 — 단지 다시 살펴볼 가치가 있는 무언가가 거기에 있다는 것만 알려줍니다.

**파인딩(Findings)**은 개별 라인 수준 플래그입니다: 위험 임계값을 넘은 특정 구조적 시그니처. 이것들은 검토할 증거이지 확인된 취약점이 아닙니다. GitGalaxy는 코드를 실행하거나 런타임 데이터플로우를 추적하거나 악용 가능성을 검증하지 않습니다 — 텍스트에 패턴이 존재한다는 것을 이 정확한 라인에서 알려주고, 직접 판단할 수 있는 컨텍스트를 넘겨줄 뿐입니다.

이것은 의도된 설계이지, 숨기고 있는 한계가 아닙니다. GitGalaxy는 정밀도보다 재현율을 선택하는 쪽으로 설계되었습니다: 더 많이 플래그하고, 인간이나 더 깊은 도구가 목록을 좁히도록 하는 것입니다. 실제 문제에 대해 침묵할 위험을 감수하기보다는 말입니다. 오탐은 그 트레이드오프의 예상 비용이며, 읽은 코드를 실행하지 않는 모든 정적 분석기에게 동일하게 적용되는 비용입니다.

이는 또한 GitGalaxy가 특정 부류의 문제에 가장 강하다는 것을 의미합니다 — 적대적 회피가 아닌 과실. 누군가 제거하는 것을 잊은 하드코딩된 키, 안전하지 않은 레지스트리, 명백히 위험한 eval() 호출 — 이들의 반대편에는 스캐너를 피하려는 사람이 없습니다. 정적 시그니처 기반 탐지가 어떻게 작동하는지 아는 특별한 동기를 가진 공격자는 엔트로피 임계값 같은 개별 신호를 큰 노력 없이 회피할 수 있습니다. GitGalaxy를 손으로 읽기에는 너무 큰 코드베이스에 대한 빠른 1차 패스로 취급하십시오 — 무언가가 안전한지에 대한 최종 판정이 아닙니다.

알려진 CVE만이 아닌 약점 클래스

대부분의 의존성 스캐너는 조회 테이블로 작동합니다: 누군가 취약점을 발견하고 신고하여 이제 피드에 CVE 번호가 있기 때문에 취약점이 존재한다는 것을 압니다. 이는 유용하지만 필연적으로 반응적입니다 — 이런 방식으로 구축된 스캐너는 아직 발견되고 공개되지 않은 모든 것에 대해 장님이며, 신고된 사례와 약간 다르게 보이는 알려진 위험 패턴의 단순 변형조차 볼 수 없습니다.

GitGalaxy는 다른 접근 방식을 취합니다: 알려진 사례를 매칭하는 대신 약점 클래스를 매칭합니다. 파인딩은 CVE ID가 아닌 CWE(Common Weakness Enumeration)로 태그됩니다 — 하드코딩된 자격 증명, 동적 코드 실행, 안전하지 않은 역직렬화. "오염된 입력의 동적 실행"에 대한 구조적 시그니처는 어떤 변수 이름, 어떤 특정 배치에서든 그 패턴이 나타나는 모든 곳을 포착합니다 — 누군가 이미 신고서를 제출한 하나의 사례만이 아니라.

동일한 철학이 SBOM 레이어에도 확장됩니다. "이 패키지 버전이 취약점 데이터베이스에 나타나는가"라고 묻는 대신, GitGalaxy는 "디스크에 있는 이 패키지의 실제 콘텐츠가 정당한 버전의 모습과 구조적으로 일치하는가"라고 묻습니다 — 엔트로피, 구조적 지문, 동작 이상 플래그. 그렇게 해서 변조된 의존성은 누구도 아무것도 발견하거나 공개하기 전인 첫날에 잡힙니다. 기다릴 CVE가 없기 때문입니다.

이것은 CVE 피드 도구(Snyk, Dependabot, OSV-Scanner)에 대한 보완이지 대체가 아닙니다 — 그 도구들은 "이 정확한 알려진 버그가 존재하는가"에 대한 올바른 답입니다. GitGalaxy는 더 넓은 그물에 대한 올바른 답입니다: 누군가 특정 사례를 먼저 발견하고 신고할 것을 요구하지 않는 약점 클래스와 물리적 이상입니다.