보안 에이전트(security agent)가 스캐너 경고(scanner alert)를 종료할 수는 있지만, 여전히 보안 프로세스를 더 취약하게 만들 수 있습니다.

이것이 GitHub의 새로운 에이전틱 오토픽스 (agentic autofix) 프리뷰에서 나타나는 불편한 변화입니다. 이 시스템은 단순히 패치를 제안하는 것에 그치지 않습니다. 저장소(repository)를 탐색하고, 코드를 수정하며, 원래의 분석을 다시 실행하고, 필요한 경우 반복(iterate)한 뒤, 초안 풀 리퀘스트(draft pull request)를 생성합니다.

이러한 루프(loop)는 유용합니다. 하지만 팀들은 여기서 "검증됨(verified)"에 대한 정의를 옮겨야 합니다. 깨끗한 CodeQL 결과는 한 가지 질문에만 답합니다. "원래의 쿼리(query)가 여전히 이 경고를 보고하는가?" 이것은 해당 동작이 올바르다거나, 익스플로잇(exploit)이 불가능하다거나, 혹은 변경 사항이 인접한 경로를 망가뜨리지 않았다는 것을 증명하지는 않습니다.

이것이 제가 그 주변에 구축하고자 하는 리뷰 워크플로우(review workflow)입니다.

프리뷰가 실제로 수행하는 작업

GitHub은 에이전틱 오토픽스(agentic autofix)가 CodeQL 및 제3자 코드 스캐닝 경고와 함께 작동한다고 밝히고 있습니다. Copilot에 경고를 할당하면 다음과 같은 에이전트 세션이 시작됩니다:

1. 코드베이스 전반에 걸쳐 관련 파일을 탐색합니다.
2. 수정 사항을 제안합니다.
3. CodeQL을 다시 실행하여 경고가 종료되었는지 확인합니다.
4. 필요한 경우 반복합니다.
5. 요약 및 검증 단계가 포함된 초안 풀 리퀘스트(draft pull request)를 생성합니다.

이 기능은 퍼블릭 프리뷰(public preview) 상태입니다. 이를 사용하려면 GitHub Code Security 또는 Advanced Security와 클라우드 에이전트가 활성화된 Copilot 라이선스가 필요합니다. 실행 시 AI 크레딧(AI Credits)과 GitHub Actions 분(minutes)이 소모됩니다.

이러한 제약 사항은 중요합니다. 이것은 무료로 "모든 것을 수정하는" 버튼이 아니며, 보안 리뷰(security review)를 대체하는 것도 아닙니다.

출처: GitHub Changelog: Agentic autofix for code scanning alerts

스캐너 재검증을 첫 번째 관문으로 취급하십시오

자동 CodeQL 재실행은 작업을 트리거한 경고에 대한 루프를 닫아주기 때문에 가치가 있습니다. 그 결과를 유지하되, 다음과 같은 특정 주장에 대한 증거로 저장하십시오:

검증 시점에 원래의 스캐너 조건이 더 이상 감지되지 않았다.

이를 단순히 "취약점이 수정되었다"라고 묵인하며 홍보해서는 안 됩니다. 패치는 데이터 흐름 경로 (data-flow path)를 억제하거나, 입력 형태 (input shape)를 변경하거나, 원래의 쿼리가 커버하지 않는 다른 곳으로 동작을 옮길 수 있습니다.

유용한 초안 PR (Pull Request)은 다음과 같은 증거를 가시화해야 합니다:

• 경고 규칙 (alert rule) 및 심각도 (severity);
• 원래 위치 및 변경된 파일들;
• 전후의 CodeQL 결과;
• 추가되거나 변경된 테스트;
• 수정된 의존성 (dependencies) 및 설정 (configuration);
• 남아있는 가정 또는 검증되지 않은 경로.

만약 PR에 이러한 컨텍스트가 포함되어 있지 않다면, 리뷰어는 로그로부터 에이전트의 추론 과정을 재구성해야만 합니다.

스캐너가 제공할 수 없는 동작 테스트 (behavioral test) 추가

코드 스캐닝은 정적 신호 (static signal)입니다. 이를 보안 속성 (security property)에 대한 테스트와 결합하십시오.

예를 들어, 경고가 경로 탐색 (path traversal)에 관한 것이라면, 구현 세부 사항뿐만 아니라 경계 조건 (boundary)을 테스트하십시오:

from pathlib import Path

def safe_read(root: Path, user_path: str) -> bytes:
...

중요한 테스트는 단순히 "일반적인 파일을 읽을 수 있다"가 아닙니다. 다음과 같은 것들을 포함해야 합니다:

• ../ 탐색 (traversal);
• 절대 경로 (absolute paths);
• 심볼릭 링크 탈출 (symlink escapes);
• 입력이 URL 경계를 넘는 경우 인코딩된 구분자 (encoded separators);
• 파일 누락 및 권한 오류.

정확한 케이스는 경고 내용에 따라 달라집니다. 원칙은 변하지 않습니다: 에이전트는 보고된 조건을 수정해야 하며, 여러분의 테스트는 신뢰 경계 (trust boundary)에서의 의도된 동작을 단언 (assert)해야 합니다.

에이전트가 생성한 변경 사항으로서 패치를 리뷰하기

초안 PR은 인간이 확인하는 좋은 체크포인트이지만, 리뷰어가 차이점 (diff) 너머를 볼 때만 유효합니다.

저는 다음 네 가지 질문을 던질 것입니다:

1. 수정 사항이 기능을 축소했는가, 아니면 단순히 경로를 숨겼는가?

보안 패치는 일반적으로 입력, 신원 (identity), 또는 도구 (tool)가 할 수 있는 범위를 좁혀야 합니다. 만약 단순히 쿼리 형태를 변경하거나, 억제 (suppression)를 추가하거나, 예외 (exception)를 광범위하게 포착하는 것에 그친다면, 리뷰를 중단해야 합니다.

2. 에이전트가 권한 부여 (authorization) 또는 목적지 로직을 변경했는가?

권한 확인 (permission checks), URL 구성 (URL construction), 파일 시스템 루트 (filesystem roots), 셸 명령 (shell commands), 패키지 설치 (package installation), 그리고 직렬화 (serialization)에 대한 변경 사항은 집중적인 검토가 필요합니다. 이러한 부분들은 "작은" 패치가 서비스 전체의 도달 가능한 동작 (reachable behavior)을 변경할 수 있는 지점들입니다.

3. 에이전트가 테스트하지 않은 것은 무엇인가?

검증 요약 (validation summary)을 보증이 아닌 경계선으로 읽으십시오. "CodeQL 통과"는 "통합 테스트 (integration tests) 통과"와 같지 않으며, 이 중 어느 것도 취약점 공격 가능성 검토 (exploitability review)와 같지 않습니다.

4. 결과를 재현할 수 있는가?

경고 식별자 (alert identifier), 에이전트 세션 또는 실행 링크, 커밋 (commit), 도구 출력 (tool output), 그리고 테스트 명령어를 유지하십시오. 패치를 설명하거나 다시 실행 (replay)할 수 없다면, 나중에 감사 (audit)하기 어렵습니다.

실질적인 머지 정책 (merge policy)

심각도가 높거나 외부에서 접근 가능한 발견 사항(findings)의 경우, 다음과 같은 순서를 사용하겠습니다:

경고 할당 (alert assigned)
  -> 에이전트가 초안 PR (draft PR) 생성
  -> 스캐너 (scanner) 재실행 성공
...

위험도가 낮은 발견 사항의 경우, 일부 단계는 더 가볍게 진행할 수 있습니다. 하지만 정책은 여전히 명시적이어야 합니다. "에이전트가 확인했다"는 정책이 아닙니다.

또한 실험을 시작하기 전에 예산을 설정하십시오. GitHub에 따르면 에이전트 기반 자동 수정 (agentic autofix)이 실행될 때 AI 크레딧 (AI Credits)을 소비하며, 해당 활동은 Actions 분 (minutes)을 소비합니다. 명확한 검토 전략을 공유하는 경고들만 일괄 처리(Batch)하십시오. 관련 없는 초안 PR이 대량으로 쌓이면 취약점 부채 (vulnerability debt)를 줄이는 속도보다 검토 부채 (review debt)가 더 빠르게 증가할 수 있습니다.

유용한 멘탈 모델 (mental model)

에이전트 기반 자동 수정 (Agentic autofix)은 하나의 내장된 오라클 (oracle), 즉 원래의 스캐너를 가진 패치 생성 루프로 이해하는 것이 가장 좋습니다. 이는 일회성 제안 (one-shot suggestion)보다 의미 있는 개선이지만, 여전히 단 하나의 오라클일 뿐입니다.

가장 안전한 워크플로우는 세 가지 독립적인 질문을 결합하는 것입니다:

만약 이 답변들이 일치하지 않는다면, 패치는 준비되지 않은 것입니다.

GitHub의 프리뷰 기능은 보안 조치 (security remediation)를 더 실행 가능하게 만듭니다. 엔지니어링 과제는 증거 (evidence) 또한 더 실행 가능하게 만드는 것입니다.

오늘 여러분은 AI가 생성한 보안 수정 사항을 어떻게 검토하고 계십니까: 스캐너 재실행 (scanner reruns)만 수행하시나요, 집중적인 익스플로잇 테스트 (exploit tests)를 진행하시나요, 아니면 더 엄격한 초안 PR (draft-PR) 정책을 적용하시나요?