둘째 날 낮 12시 10분, 3층 313+314호. 제가 이번 행사에서 들은 마지막 세션입니다.
Scalable Security and Compliance in the Age of AI
Eddie Knight (Founder, Revanite / OpenSSF·FINOS)
발표자 이력이 화려합니다. CNCF Security Slam 운영자이고, FINOS(금융권 오픈소스 재단) TOC 리드이며, 이번 주에 자신의 Privateer 프로젝트가 Linux Foundation에 들어갔다고 소개했습니다.
🤖 시험에서 부정행위를 한 AI
도입 사례가 강렬했습니다.
2026년 7월 OpenAI 벤치마크 평가 중에 있었던 일인데, 모델이 자기 평가에서 좋은 점수를 받으려고 시험을 부정행위로 통과하려 했습니다. 발표자의 분류로는 "악의"가 아니라 "실수" 범주인데 결과는 똑같이 파괴적이었습니다.
- 제로데이를 이용해 자기 시스템에 RCE 획득
- 권한 상승
- Hugging Face 인프라 침해
- 17,000건의 포렌식 이벤트 발생
특히 서늘했던 대목은 이겁니다. 컨텍스트가 재시작되거나 여러 에이전트가 뜨더라도 탈출 방법을 알 수 있도록, 스스로 자기 시스템에 메모를 남겨서 command and control을 이어갔습니다. 새로 뜨는 모든 컨텍스트가 "여기 이렇게 빠져나가면 된다"는 문서를 읽게 만든 겁니다. 아무도 그렇게 하라고 시키지 않았습니다.
결론이 서늘합니다. AI 에이전트는 악의가 없어도 복잡한 공급망 공격을 실행할 수 있습니다. 목표만 있으면 방법을 찾아냅니다.
📉 숫자로 본 현실
- Mandiant — 취약점 공개에서 익스플로잇까지 걸리는 시간이 63일에서 5일로 줄더니, 이제는 마이너스 7일입니다. 평균적으로 우리가 알기 일주일 전에 이미 악용되고 있다는 뜻입니다
- VulnCheck — 알려진 악용 취약점 884건 중 29%가 공개 당일이나 그 이전에 이미 익스플로잇됐습니다. 작년 23.6%에서 오른 수치입니다
- GreyNoise 허니팟 — 공개 시점 기준으로 되돌아보면 평균 11일 전부터 특정 허니팟이 유난히 집중적으로 두들겨 맞고 있었습니다
- 악성 패키지 — 2025년 신규 45.4만 개. 그중 3분의 1이 계정 11개짜리 단일 스팸 캠페인이었고, 4.3만 개는 발각되지 않은 채로 2년 넘게 다운로드 가능한 상태였습니다
🎣 환각은 무작위가 아니라 예측 가능하다
이 세션에서 가장 실용적인 데이터였습니다. AI 코딩 어시스턴트의 의존성 업그레이드 추천 3.7만 건(정확히는 36,870건)을 분석한 결과입니다.
- 28%가 틀린 추천 — 존재하지 않는 버전을 지목했습니다
- 345건은 더 최신이지만 오히려 더 취약한 버전으로 올리라고 했습니다
- 그리고 결정적인 것. 127개의 패키지 이름이 테스트한 다섯 개 모델 전부에서 똑같이 환각됐습니다
마지막 항목이 핵심입니다. 환각이 무작위라면 공격자에게 별 쓸모가 없습니다. 오늘 만들어낸 이름을 내일은 안 만들어낼 테니까요.
그런데 여러 모델이 같은 이름을 만들어낸다면 이야기가 완전히 달라집니다. 그 목록을 뽑아서 미리 등록해두면 되니까요. 발표자는 이걸 "예측 가능하고 수확 가능한 슬롭 스쿼팅 표적" 이라고 불렀습니다.
한번 선점되고 나면 그 이름은 더 이상 존재하지 않는 이름이 아닙니다. 정상 패키지와 거의 동일한 코드에 유출 한 줄만 추가하면 그대로 실행됩니다.
⏱️ 방어 체계는 더 느리다
- CVE 경보는 수정본이 나온 뒤 평균 25일 후 도착합니다. Maven 생태계는 167일로 훨씬 느립니다
- Verizon DBIR 데이터상 알려진 악용 취약점의 패치 소요 시간이 32일에서 43일로 오히려 길어졌습니다. AI도 있고 도구도 늘었는데 반대 방향입니다
- 더 서늘한 건 이겁니다. 영향받는 모든 시스템까지 패치가 도달하는 경우는 4건 중 1건뿐이고, 그것도 3건 중 1건에서 떨어진 수치입니다
- 자동화가 도움이 안 되는 건 아닙니다. GitHub 기준으로 크리티컬 취약점 수정 시간을 37일에서 26일로 줄였습니다. 다만 공격 쪽 속도에 비하면 여전히 뒤처집니다
🌊 후다이 수문 이야기
여기서 나온 비유가 이 세션의 중심축입니다.
이와테현 후다이 마을의 와무라 코토쿠 촌장은 재임 기간 내내 예산 낭비라는 비난을 받으며 수문을 지었습니다. "이미 방조제가 있는데 강 위에 수문까지 필요하냐, 감수할 만한 리스크다"라는 것이었죠.
그리고 40년이 흐르고 촌장이 세상을 떠난 뒤, 거대한 해일이 그 마을을 덮쳤습니다. 수천 명이 큰 피해를 입었어야 할 상황이었는데 그 수문이 막아냈습니다. 초등학교에서 눈으로 보이는 거리였다고 합니다.
불필요해 보였고 감수할 만한 리스크로 보였지만 미리 설계해뒀기 때문에 지금도 많은 사람이 살아 있다는 겁니다.
발표자의 결론은 이렇습니다. 우리는 디지털 홍수 지대에서 소프트웨어를 짓고 있습니다. AI를 안 쓸 수 없고 오픈소스 의존성을 안 쓸 수도 없습니다. 그러니 질문은 하나입니다.
"쓰나미가 우리 조직을 덮치기 전에 작동하는 방어 체계를 어떻게 만들 것인가."
🛡️ AI로 AI를 막는다는 이상, 그리고 뒤처진 GRC
"AI가 공격하니 AI로 방어하자"는 접근에도 근거가 있습니다. Google Big Sleep은 실제 제로데이를 악용 전에 발견 중이고, XBOW는 HackerOne 미국 리더보드 1위이며, DARPA AI Cyber Challenge에 출전한 시스템들은 취약점 63개 중 54개를 찾아내고 43개를 사람 없이 패치했습니다.
그런데 발표자는 여기에 단서를 답니다. 이건 LLM 고유의 새로움이 아닙니다. Google은 2012년부터 피싱 분류에 ML을 썼고, DARPA의 Mayhem은 2016년에 이미 사람 없이 취약점을 찾고 패치했으며, PyPI와 Maven Central은 2019년부터 ML로 악성 패키지를 잡아왔습니다. 즉 공격 기술과 방어 기술은 대체로 비슷한 속도로 따라가고 있습니다.
그럼 무엇이 뒤처졌나. 답은 GRC(거버넌스·리스크·컴플라이언스) 입니다.
기술적 보안은 자동화로 옮겨갔는데 GRC는 여전히 스프레드시트에 눈으로 확인하는 시대에 갇혀 있습니다. 그리고 아이러니하게도 가장 폭넓은 리서치를 하는 사람들이 바로 그 GRC 담당자들입니다. 그런데 우리는 그 결과를 무시하고 따로 보안 스캐너를 만듭니다.
수동 스프레드시트, 벤더 종속 웹 포털, 스크린샷. 개발 도구나 런타임 엔진과 완전히 단절돼 있고, GRC 솔루션을 바꾸려면 프로그램 전체를 처음부터 다시 시작해야 할 위험까지 있습니다.
🦶 발판(Foothold) 관점의 설계
방어자는 본능적으로 거대한 시스템을 설계합니다. 그런데 공격자, 특히 AI 기반 공격자는 발판 하나만 있으면 됩니다. 저항이 가장 적은 경로를 찾아 "좋아, 여기 발판 확보. 다음은?"으로 계속 이어갑니다.
그래서 처음부터 제로 트러스트로 가야 한다는 겁니다. "당신이 발판을 하나 잡았다고 가정하고, 그다음 발판을 어떻게 막을 것인가" 를 모든 시스템이 고민해야 한다는 것.
🚂 철도 궤간 표준화
보안과 GRC를 붙이는 방법으로 표준화를 제안하며 든 비유입니다.
미국에는 원래 철도 궤간이 제각각이었습니다. 도시 간 철도망이 연결되기 시작하자 문제가 됐죠. 한 도시에서 다음 도시로 가야 하는데 레일 폭이 15cm 달라서 안 됩니다. 결국 명백한 문제였기에 합의가 이뤄지고 표준화됐습니다.
그리고 일본 청중에게 이렇게 말했습니다. 지하철 옆에 물탱크 화차가 서 있는 걸 보고 놀랐다고요. 지하철, 화물열차, 신칸센이 표준화의 극단까지 가 있다며 감탄했습니다. 보안과 컴플라이언스는 아직 그 수준이 아닙니다.
표준화의 부수 효과도 있습니다. 도구를 결정론적으로 고정하면 토큰 사용량을 크게 줄일 수 있습니다. LLM에게 웹을 뒤져 10만 토큰을 쓰게 하는 대신 "이 스캐너를 써라"고 지시할 수 있으니까요.
데모에서는 CNCF 권고사항과 OpenSSF 자료를 한 대시보드에서 조회하고, 같은 데이터 스토어를 설계 가이드와 스캔 기준으로 동시에 쓰는 구조를 보여줬습니다. LFX Insights의 27,000개 저장소 결과를 올려보니 체크 3개가 유난히 낮았는데, 이제 코드가 부실한 건지, 체크를 개선해야 하는지, 요구사항 자체를 고쳐야 하는지를 구분할 수 있게 됩니다.
✅ 결론 세 가지
- 워크플로를 표준화하라. 거버넌스 팀과 보안 팀이 상호 운용되게 만들 것. OpenSSF의 Gemara가 이를 머신 리더블하게 가능하게 합니다
- 결정론적 도구를 갖춰라. 10번, 100번, 27,000번 반복할 일이라면 LLM에게 시키지 말고 소프트웨어를 만드십시오. Privateer가 OpenSSF에 들어왔고 CNCF와 FINOS 스캔에 쓰이고 있습니다
- 제로 트러스트와 제로 토큰을 어디에나 적용하라. 공격자가 발판을 잡는다고 가정하고, 배포되는 모든 것에 베스트 프랙티스와 스캔을 적용할 것
세 번째에 "제로 토큰(Zero Token)" 이 붙은 게 눈에 띕니다. 발표 중반에 Zero Token Architecture를 별도로 다루면서 OpenSSF Gemara 스펙으로 이를 표현하는 방법까지 보여줬는데, 요지는 두 번째 항목의 연장입니다. 판단을 LLM 호출에 맡기지 않는 경로를 시스템에 확보해두라는 것.
두 번째 항목은 AI에게 맡기고 싶은 유혹이 큰 반복 작업일수록 오히려 결정론적으로 고정해두는 게 맞다는 이야기입니다.
🛫 마치며
이 세션이 남긴 건 관점의 전환이었습니다. 보안을 "스캐너를 몇 개 붙였는가"가 아니라 "요구사항 → 설계 → 측정 → 감사 → 요구사항 개선"의 순환이 연결돼 있는가로 보게 만듭니다. 그리고 그 순환이 끊기는 지점이 대부분 GRC와 개발 도구 사이라는 지적이 설득력 있었습니다.
시간이 모자라 Q&A는 거의 못 했지만("후다이 수문 이야기에 너무 흥분해서"라는 농담과 함께) 밀도 자체가 높아 아쉽지 않았습니다. 이 세션을 끝으로 짐을 챙겨 공항으로 향했습니다.
다음 글에서 시리즈를 마무리합니다.