AI 코딩 시대, 패키지 공급망은 ‘검증 카탈로그’로 막자는 액티브스테이트

AI 코딩 도구보다 의존성 경로가 더 위험해짐

• 액티브스테이트가 생성AI 코드와 오픈소스 공급망 위험을 줄이기 위한 큐레이티드 카탈로그 지원을 확대함

  • 대상은 커서(Cursor), 클로드 코드(Claude Code), 깃랩 듀오(GitLab Duo), 탭나인(Tabnine), 윈드서프(Windsurf), 젯브레인스 AI(JetBrains AI) 같은 AI 코딩 도구들임
  • 핵심은 AI 도구별 보안 플러그인을 붙이는 게 아니라, 패키지를 가져오는 경로 자체를 기업이 통제하는 구조임

• 문제는 AI 코딩 도구가 코드를 만들면서 공개 레지스트리의 패키지와 의존성을 자동으로 끌고 온다는 점임

  • 프롬프트 하나가 새 의존성 요청으로 이어질 수 있음
  • 그 요청이 기업 보안 기준을 거치지 않은 공개 저장소를 통과하면, 공격 표면이 기계 속도로 늘어남

• 액티브스테이트의 주장은 꽤 현실적임. 개발자는 하나의 AI 코딩 도구만 쓰지 않음

  • 지금은 커서를 쓰다가, 나중엔 클로드 코드나 다른 도구로 넘어갈 수 있음
  • 그래서 보안 계층은 특정 AI 도구가 아니라 의존성 소비 지점에 붙어야 한다는 논리임

검증 카탈로그가 하는 일

• 큐레이티드 카탈로그는 AI 코딩 도우미가 패키지를 요청할 때 공개 레지스트리 대신 기업 정책으로 관리되는 검증 카탈로그에서 가져오게 만듦

  • 보안 거버넌스를 코드 작성 후 스캔 단계가 아니라 의존성 소비 단계에 배치하는 방식임
  • 개발자가 어떤 AI 도구를 쓰든, 실제 패키지 유입 경로를 공통 통제 지점으로 잡는 셈

• 규모도 작지 않음. 액티브스테이트는 12개 언어, 7900만 개 이상 구성 요소를 제공한다고 밝힘

  • 각 구성 요소는 SLSA 레벨 3을 준수하는 인프라 안에서 소스 코드 기반으로 빌드됨
  • 공개 레지스트리에서 이미 만들어진 패키지를 그대로 가져오는 방식과 다르게, 출처와 빌드 절차, 변경 이력을 남기는 구조임

• 기존 기업 개발 환경과의 호환성도 강조함

  • JFrog Artifactory, Sonatype Nexus, GitHub Packages, AWS CodeArtifact, GitLab Package Registry, Google Artifact Registry, Azure Artifacts 등과 함께 쓸 수 있음
  • 새 개발 도구나 CI/CD 환경을 통째로 바꾸지 않고도 검증된 구성 요소를 공급할 수 있다는 얘기임

sequenceDiagram
    participant 개발자
    participant AI코딩도구
    participant 패키지관리자
    participant 검증카탈로그
    participant 기업저장소

    개발자->>AI코딩도구: 기능 구현 요청
    AI코딩도구->>패키지관리자: 필요한 의존성 요청
    패키지관리자->>검증카탈로그: 기업 정책에 맞는 패키지 확인
    검증카탈로그->>기업저장소: 검증된 아티팩트 제공
    기업저장소-->>패키지관리자: 승인된 패키지 반환
    패키지관리자-->>개발자: 통제된 의존성 설치

CVE 대응을 SLA로 묶는 게 포인트

• 액티브스테이트는 취약점 대응 시간을 계약상 서비스수준협약(SLA)으로 제시함

  • 중요 CVE는 5영업일 이내
  • 심각도 높음 CVE는 10일 이내
  • 그 외 모든 CVE는 30일 이내 해결한다고 밝힘
  • 기사에서는 업계 평균 해결 시간이 60일 이상으로 지연되는 상황과 비교함

• 이건 단순히 취약점 목록을 보여주는 것과 다름

  • 오픈소스 커뮤니티에서 수정 사항이 나오면 액티브스테이트가 업데이트된 구성 요소를 자동으로 빌드하고 게시하는 구조임
  • 보안팀이 CVE 백로그를 들고 개발팀을 쫓아다니는 부담을 줄이겠다는 방향임

국내 기업에도 바로 꽂히는 이유

• 국내 기업도 AI 코딩 도구 도입은 빠르게 늘고 있지만, 오픈소스 의존성 관리 수준은 조직마다 차이가 큼

  • 금융, 공공, 제조, 플랫폼 기업은 개발 속도와 보안 검증, 규제 대응을 동시에 요구받음
  • AI가 코드를 빨리 만들어도 패키지 출처와 취약점 대응을 설명하지 못하면 보안팀과 감사팀에서 막힐 수 있음

• 이 사례가 주는 메시지는 생성AI 코드 보안을 ‘AI 도구 보안’으로만 보면 안 된다는 것임

  • 중요한 건 개발자가 어떤 도구를 쓰든 승인된 패키지와 감사 가능한 빌드 체계를 적용하는 것임
  • SBOM, 출처 증명, 감사 추적, 취약점 해결 SLA가 앞으로 기업 개발 환경의 기본 체크리스트가 될 가능성이 큼

• 결국 보안 통제의 초점이 코드 작성 도구에서 의존성 공급망으로 이동하고 있음

  • AI가 만든 코드의 품질도 중요하지만, 그 코드가 호출하는 오픈소스 구성 요소가 더 큰 리스크가 될 수 있음
  • “AI 코딩 허용할 거냐”보다 “AI가 가져오는 의존성을 어디서 통제할 거냐”가 더 실전적인 질문이 됨

기술 맥락

• 이 기사에서 중요한 선택은 AI 코딩 도구를 직접 통제하려 하지 않고, 패키지가 들어오는 길목을 통제하는 거예요. 왜냐하면 개발자가 쓰는 도구는 계속 바뀌지만, 의존성은 결국 패키지 관리자와 아티팩트 저장소를 통해 들어오거든요.

• SLSA 레벨 3 기반 소스 빌드를 강조하는 이유는 패키지 출처를 설명해야 하기 때문이에요. 공개 레지스트리에서 받아온 바이너리를 그대로 믿는 대신, 어떤 소스에서 어떤 절차로 빌드됐는지 추적할 수 있어야 공급망 사고 때 방어 논리가 생겨요.

• CVE SLA가 중요한 건 보안팀의 병목을 줄이기 위해서예요. AI 코딩 도구가 의존성을 빠르게 늘리면 취약점 목록도 같이 늘어나는데, 사람이 매번 우선순위를 정하고 패치 요청을 돌리는 방식은 속도를 못 따라가요.

• 기존 Artifactory나 Nexus 같은 저장소와 붙는다는 점도 현실적인 선택이에요. 기업 입장에서는 보안 때문에 개발 파이프라인 전체를 갈아엎기 어렵고, 이미 쓰는 저장소 흐름 안에서 정책을 강제하는 쪽이 도입 저항이 낮거든요.

• 국내 기업에선 이 접근이 특히 감사와 규제 대응에 연결돼요. 생성AI가 만든 코드가 실제 서비스에 들어갈수록, 코드 자체뿐 아니라 그 코드가 끌어온 오픈소스의 출처와 패치 상태까지 설명해야 하는 상황이 늘어날 수 있어요.