GitHygiene

TetraFourge가 Hacktoberfest Hack Day — Coimbatore 2026을 위해 구축했습니다.

INIT CLUB × iDEA CLUB × MLH

프로젝트를 진행하다 보면 보안 스캐너를 실행해서 다음과 같은 결과를 얻는 지점이 있습니다:

47개의 취약점 발견.

훌륭합니다.

이제 어떻게 해야 할까요?

어떤 취약점들이 실제로 애플리케이션에 영향을 미치나요?

세 개의 의존성 깊이에 묻혀 있는 취약점들은 어떤 것들인가요?

실제로 사용되고 있는 취약점들은 무엇인가요?

안전하게 무시해도 되는 취약점은 어떤 것들이 있나요?

그리고 가장 중요한 것은, 무엇을 먼저 고쳐야 할까요?

이것이 바로 우리가 해결하고자 했던 문제입니다.

아이디어

현대적인 애플리케이션은 수백 개의 패키지 위에 구축됩니다.

당신의 코드는 하나의 패키지에 의존합니다.

그 패키지는 또 다른 패키지에 의존합니다.

그 패키지는 또 다른 패키지에 의존합니다.

금세, 당신은 자신이 본 적도 없는 코드에 대한 책임을 지게 됩니다.

이 사슬의 어느 곳에서 문제가 발생하면, 전통적인 스캐너는 그것이 깨졌다는 것을 알려주는 데 능숙합니다. 하지만 당신의 애플리케이션이 실제로 취약한 부분에 도달하는지 여부를 알려주는 것은 훨씬 덜 유용합니다.

여기에 우리가 GitHygiene을 구축하기 시작했습니다.

그래서 무엇을 하나요?

GitHygiene은 GitHub 저장소에 연결하여 의존성, 취약점, 그리고 실제로 그들을 사용하는 코드로 이루어진 지도를 만듭니다.

package.json, package-lock.json, requirements.txt를 스캔하고, 의존성 트리를 구축하며, OSV.dev와 패키지를 비교하고, 오래되거나 사용 중단된 의존성을 찾습니다.

하지만 우리는 다음에서 멈추고 싶지 않았습니다:

저희 게이트웨이는 해당 취약점 표면과 관련된 임포트(imports), 심볼(symbols), 호출 지점을 실제 레포지토리에서 검색합니다.

마지막으로: 또 다른 Gemma 4 모델이 어드바이저리 정보와 레포지토리에서 발견된 증거를 종합하여 도달 가능성 평가(reachability assessment)를 수행합니다.

결과는 다음 네 가지 결과 중 하나입니다:

reachable

likely_reachable

not_evidenced

unused

이 구분이 중요합니다.

의존성 트리의 어딘가에 있는 취약한 패키지가, 여러분의 애플리케이션에 의해 실행되는 취약한 코드와 반드시 같은 것은 아닙니다.

그리고 저희는 AI를 위한 규칙을 추가했습니다

AI가 무언가를 어디서 얻었는지 증명할 수 없다면, 보여주지 않습니다.

모델이 인용하는 모든 파일은 정적 분석(static analysis) 중에 수집된 증거에 존재해야 합니다.

만약 모델이 저희가 검증할 수 없는 스키마를 반환하거나, 증거에 없던 것을 인용한다면, 그 결과는 거부됩니다.

조작된 파일 경로는 없습니다.

상상의 증거도 없습니다.

'나 믿어봐(trust me)'식 보안 분석은 없습니다.

시스템은 잘못된 확신에 찬 답변을 제공하기보다는 AI 분석 불가라고 말하는 것을 선호합니다.

그리고 의존성 그래프가 있습니다

하나의 취약한 패키지가 반드시 하나의 레포지토리에 영향을 미치는 것은 아닙니다.

다음과 같은 상황일 수 있습니다:

repo-a
   \
    package-x
...

그래서 저희는 Neo4j를 사용하여 의존성 관계를 모델링했습니다.

이제 패키지가 어드바이저리에 의해 영향을 받을 때, 저희는 의존성 그래프를 추적하여 해당 문제를 상속받는 레포지토리를 확인할 수 있습니다.

이것이 바로 저희의 블래스트 반경(blast radius) 뷰입니다.

레포지토리들을 하나하나 조사하는 대신, 동일한 의존성 문제가 프로젝트 전반에 걸쳐 어떻게 퍼져나가는지 볼 수 있습니다.

취약점을 찾는 것이 끝은 아닙니다

GitHygiene이 발견 사항을 식별하면, 이를 처리하는 방법도 제시할 수 있습니다.

의존성이 직접적인지 간접적인지에 따라 복구 권장 사항(remediation recommendations)을 생성하고, 직접 업그레이드 또는 오버라이드를 제안하며, 잠재적인 호환성 문제(breaking changes)를 플래그 지정하고, 발견 사항을 스캔 증거와 함께 초안 GitHub 이슈로 변환할 수 있습니다.

그러면 워크플로우는 다음과 같이 진행됩니다:

찾기 → 이해하기 → 결정하기 → 수정하기.

다음과 같지 않습니다:

47가지 취약점을 찾고 → 대시보드를 쳐다보다가 → 포기하는 것.

우리가 구축한 것

최종 시스템은 몇 가지 부분으로 나뉘어 있습니다:

React 19 + TypeScript
        |
        v
...

게이트웨이가 애플리케이션 컨텍스트와 데이터베이스 접근 권한을 소유합니다.

AI 서비스는 특정 분석에 필요한 정보만 받고, 데이터베이스 자격 증명은 보유하지 않습니다.

이러한 분리는 AI 계층이 스캐너 자체를 다운시키지 않고도 교체되거나, 모의 테스트(mocked)되거나, 오프라인으로 전환될 수 있음을 의미합니다.

AI 서비스가 사용 불가능하더라도 여전히 스캔할 수 있습니다.

Neo4j가 사용 불가능하더라도 여전히 스캔할 수 있습니다.

핵심 기능이 단지 '똑똑해 보이는' 상자 중 하나가 컨디션 난조를 겪었다는 이유만으로 무너져서는 안 됩니다.

GitHygiene가 다른 점은 무엇인가요?

대부분의 의존성 스캐너는 다음 질문에 답합니다:

"무엇이 취약한가?"

GitHygiene는 세 가지 더 유용한 질문에 답하려고 노력합니다:

"내 코드가 실제로 그것에 도달하는가?"

"어떤 저장소들이 영향을 받는가?"

"무엇을 해야 하는가?"

이것이 우리가 탐구하고자 했던 방향입니다.

보안 스캐너를 대체하는 것이 아닙니다.

발견된 문제를 실제로 수정해야 하는 사람들에게 그 출력을 더 유용하게 만드는 것입니다.

우리가 배운 것

가장 어려웠던 부분은 LLM이 보안 판정(security verdict)을 생성하도록 만드는 것이 아니었습니다.

그것은 그 판정이 신뢰받을 가치가 있도록 만드는 것이었습니다.

우리는 근거 기반(grounding)이 영리한 프롬프팅보다 더 중요하다는 것, 정적 분석(static analysis)이 유용하지만 안전성의 증거는 아니라는 것, 그리고 not_evidenced가 결코 조용히 safe로 변해서는 안 된다는 것을 배웠습니다.

또한 해커톤 기간 동안 구축하는 현실적인 문제들—구조화된 모델 응답(structured model responses), 엣지 케이스 파싱(parsing edge cases), Python 호환성, 개별 AI 단계를 테스트하고 모든 조각들이 전체 애플리케이션을 다운시키지 않으면서 독립적으로 실패할 수 있도록 만드는 것—을 처리하는 데 상당한 시간을 할애했습니다.

Hacktoberfest 해커데이에서 구축된 내용

여기에 있는 모든 것은 Hacktoberfest 해커데이 — Coimbatore 2026의 일환으로 구축되었습니다.

GitHub 인증 및 레포지토리 가져오기.

의존성 추출.

OSV 취약점 스캐닝.

보안 점수 산정.

정적 분석 (Static analysis).

Gemma 기반 도달 가능성 분석 (reachability analysis).

Neo4j 의존성 그래프.

크로스-레포지토리 폭발 반경 (blast radius).

개선 계획 수립 (Remediation planning).

GitHub 이슈 생성.

그리고 이 모든 것을 하나로 묶는 대시보드.

정말 많은 구성 요소들입니다.

단 하나의, 약간 강박적인 목표가 있습니다:

의존성 보안을 이해하기 쉽게 만드는 것.

링크

GitHub: https://github.com/Tetra4ge/GitHygiene

실시간 앱: https://git-hygiene.vercel.app/

Devpost: https://devpost.com/software/githygiene

팀 TetraFourge

G Prajwal Priyadarshan
Rahul LS
Kishore B
Kabilan

2026년 Hacktoberfest 해커 데이 — 코임배토어에서 제작됨.