AI로 생성된 코드가 취약점 관리 모델을 깨뜨리는 이유

AI 코드 생성기는 몇 년간의 DevOps 도구를 사용해도 달성하지 못한 것을 이루었다. 즉, 몇 주가 걸리던 기능을 몇 일 안에 출시할 수 있게 되었다. 그러나 문제는 속도가 취약점에도 동일하게 적용된다는 것이다.

나의 사이버 보안 분야에서의 경력 동안, 나는 조직이 동일한 반응적인 패턴을 반복하는 것을 보았다. 즉, 취약점을 발견하고, 그 범위를 이해하기 위해 애쓰고, 수정을誰에게 할당할지에 대해 논쟁하고, 몇 주나 몇 개월 후에 수정한다. AI는 이 패턴을 변경하지 않았다. 그러나 이 패턴을 이전보다 더 빠른 속도로 진행하게 만들었다. 중요한 CVE의 평균 MTTR은 60일을 넘는다. AI 지원 개발은 60일을 주지 않는다. 매 스프린트마다 새로운 코드베이스를 제공한다.

의존성 문제는 이제 AI 문제이다

96%의 기업 애플리케이션에는 오픈 소스 구성 요소가 포함되어 있다. 대부분이 엄격하게 검토되지 않았고, 그냥 공용 레지스트리에서 가져온 것이다. 보안 팀은 이 문제를 몇 년 동안 다루어왔지만, AI 코딩 어시스턴트가 나타나면서 상황이 더 어려워졌다.

개발자가 수동으로 코드를 작성할 때, 의존성에 대한 의도적인 선택을 한다. 그러나 AI 모델이 코드를 생성할 때, 그것은 훈련 데이터에서 가져온다. 즉, 의존성 트리에서 몇 층 아래에 숨겨진, 누구도 의도적으로 피하지 않은 알려진 CVE가 포함될 수 있다. 코드는 깨끗해 보이지만, 실제로는 위험이 내재되어 있다.

나는 보안 검토 회의에서 팀이 이전에 승인한 패키지의 전이적 의존성에 중요한 CVE가 발견된 것을 보았다. 패키지는 괜찮았지만, 그것이 가져온 것은 그렇지 않았다. 이 동적은现在 hundreds개의 개발자들이 사용하는 AI 툴링에서 일어난다. 이 툴링은 조직의 보안态勢를 이해하지 못한다.

事後 스캔은 전략이 아니다

오픈 소스 소프트웨어 보안의 일반적인 모델은 스캔-패치 모델이다. 즉, 스캐너를 실행하고, 결과를 분류하고, 티켓을 할당하고, 기다린다. 이 모델은 항상 반응적인 것이었지만, AI 가속 개발 환경에서는 완전히 뒤처진다.

스캐너는 코드에 이미 존재하는 문제를 발견한다. 취약점이 도입된 후 발견되기까지의 시간 간격이 노출된다. AI가 코드를 대규모로 생성할 때, 이 간격이 더 길어지고, 결과의 양이 수동으로 수정할 수 있는 팀의 속도보다 더 빠르게 증가한다. 결과는 CVE 백로그가 무한히 증가하고, 우선순위가 추측이 되고, 개발자가 비즈니스 가치가 없는 작업에 4~8시간을 소비한다.

거기에 거버넌스 붕괴가 따라오면 상황은 더 나쁘게 된다. 수정의 소유권은 종종 불분명하다. 보안 팀이 CVE를 플래그하면, 엔지니어링 팀은 구성 문제라고 하고, 운영 팀은 코드 문제라고 한다. 나는 20년 전에도 이 패턴을 보았고, 아직도 사라지지 않았다. AI는 이 모호성의 결과를 더 어렵게 만든다.

실제로 작동하는 전환: 무엇이 들어가는지 제어한다

이 문제를 앞서가는 조직들은 스캔을 통해 안전을 유지하려고 하는 것을 중단하고, 대신 개발자와 AI 툴이 소비할 수 있는 것을 처음부터 제어하기 시작했다. 메커니즘은 소스에서 구축된, 정책에 의해 거버넌스되는 오픈 소스 구성 요소의 카탈로그이다. 이것은 PyPI, npm, 또는 Maven과 같은 공용 에코시스템에서 직접 가져오는 것을 대체하는 사내 레지스트리이다.

이 접근법은 보안을 가장 문자적인 의미에서 왼쪽으로 이동시킨다. 취약점은 빌드 파이프라인에 들어가기 전에 차단된다. 개발자는 동일한 툴을 사용한다. AI 코딩 어시스턴트는 동일한 거버넌스된 소스에서 의존성을 해결한다. 보안 팀은 정책을 한 번 설정하고, 그것이 모든 곳에 적용된다. 즉, 2시_without에 사람의 검토 없이 생성된 코드에도 적용된다.

실제로 어떻게 작동하는지

이 문제를 해결하는 보안 리더들에게 몇 가지 중요한 점이 있다.

1. AI 채택을 확대하기 전에 승인된 구성 요소 세트를 정의한다. AI 코딩 툴이 공용 레지스트리에서 의존성을 해결한다면, 승인 프로세스는 종이 위에만 존재한다. 거버넌스된 내부 레지스트리를 설정하고, 모든 것을 그곳으로 라우팅하고, 구성 요소가 소스에서 구축되고 검증 가능한 출처를 갖도록 요구한다.
2. 수정을 관리되는 프로세스로 처리한다. CVE 부채를 앞서가는 조직들은 수동 수정을 더 빠르게 하는 것이 아니다. 그들은 수동 수정을 방정식에서 제거했다. 커뮤니티에서 승인된 패치가 있을 때, 그것은 자동으로 카탈로그에 재구축된다. 개발자는 다음에 가져갈 때 업데이트를 받는다.誰도 티켓을 할당하지 않는다.誰도 60일을 기다리지 않는다.
3. AI 툴체인을 컴플라이언스義務에 매핑한다. 나는 팀이 몇 개월 동안 AI 툴링을 구축했지만, 고객이 FedRAMP 정렬이나 SOC 2 증거를 요구할 때 벽에 부딪혔다는 것을 보았다. 거버넌스된 카탈로그는 또한 컴플라이언스 감사 트레이이다. SBOM과 출처 기록은 모든 구성 요소와 함께 제공되어야 하며, 기한 압력下에서 후퇴적으로 조립되어서는 안 된다.
4. 거버넌스 레이어에서 명확한 소유권을 할당한다. 수정을 가장 빠르게 하는 팀은 가장 많은 개발자를 둔 팀이 아니다. 보안 팀이 정책을 소유하고, 플랫폼 팀이 배달을 소유하며, 어느 쪽도 다른 쪽이 행동하기를 기다리지 않는 팀이다.

보안이 차단하는 것이 아니라 가능하게 한다

보안과 개발 속도가 근본적으로 충돌한다는 믿음이 있다. 그러나 보안이 프로세스에 설계된 경우, 나는 이것이 사실이 아니라는 것을 발견했다. 거버넌스된 구성 요소 세트에서 작업하는 개발자는 실제로 더 빠르게 움직인다. 왜냐하면, 그들은 승인을 의심하거나, 보안 검토를 기다리거나, 업스트림에서 차단할 수 있는 취약점을 청소하지 않기 때문이다.

AI 주도 개발 없이 지속 불가능한 보안 부채를 축적하지 않는 조직은 가장 많은 스캐너를 실행하는 것이 아니다. 그들은 소프트웨어 공급 체인에 무엇이 들어가는지 처음부터 관리하기로 결정한 조직이다. 이 결정은 리더십에 속한다. 이 결정을 실행하는 툴이 오늘날 존재한다.