감사 추적이 성립하는 조건

한 줄 요약

감사 추적은 로그를 켜는 일이 아니라 지금 돌고 있는 것이 무엇인지 이름으로 지목할 수 있게 만드는 일입니다. 태그로 배포하면 이 조건이 성립하지 않습니다.

왜 태그로는 안 되나

checkout:1.4.0 은 이름이고 checkout@sha256:... 은 내용입니다. 태그는 다시 밀 수 있어서, 어제 스캔한 것과 오늘 돌고 있는 것이 다를 수 있습니다.

그러면 이런 질문에 답할 수 없습니다.

"지금 운영에 있는 checkout 은 어느 커밋에서 나온 것입니까""그 이미지에 CVE-2026-xxxx 가 들어 있습니까""그 취약점이 알려진 시점에 이미 배포돼 있었습니까"

세 질문 모두 "지금 돌고 있는 것" 을 유일하게 지목할 수 있어야 답이 나옵니다. 다이제스트로 고정하는 것은 보안 기능이 아니라 감사 추적의 최소 조건입니다.

어떻게 동작하나

SBOM 은 목록이고 서명은 출처입니다

둘은 다른 질문에 답합니다.

| 도구 | 답하는 질문 |
| --- | --- |
| SBOM | 이 이미지 안에 어떤 구성 요소가 들어 있는가 |
| 서명 | 이 이미지를 누가 만들었는가 |
| 증명(attestation) | 그것이 어떤 과정을 거쳐 만들어졌는가 |
| 스캔 결과 | 그 구성 요소에 알려진 취약점이 있는가 |

SBOM 만 있고 서명이 없으면 목록은 있는데 그 목록이 이 이미지의 것인지 알 수 없습니다. 서명만 있고 SBOM 이 없으면 누가 만들었는지는 아는데 안에 무엇이 들었는지는 모릅니다. 그래서 둘은 같이 갑니다.

스캔은 파이프라인 안에 있어야 의미가 있습니다

스캔을 따로 돌려 보고서를 만드는 조직이 많습니다. 보고서는 쌓이고 배포는 그대로 나갑니다. 스캔이 게이트가 되려면 결과가 종료 코드가 되어 파이프라인을 멈춰야 합니다.

다만 심각도 기준을 처음부터 높게 잡으면 아무것도 배포되지 않습니다. 그래서 대개 이렇게 시작합니다. 새로 들어오는 것에는 엄격한 기준을 적용하고, 이미 있는 것에는 기한을 두고 목록을 줄여 갑니다.

감사 로그는 무엇을 남기는가

쿠버네티스의 감사 로그는 "누가 무엇을 언제 했는가" 를 남깁니다. 여기서 중요한 것은 수준을 어디에 두느냐입니다. 전부 RequestResponse 로 남기면 저장량이 폭발하고 그래서 보존 기간이 짧아집니다. 사고를 조사할 때 필요한 것은 대개 몇 달 전 기록이라, 저장량이 커서 짧아진 보존 기간은 감사 추적을 사실상 없앱니다.

그래서 읽기는 Metadata 로, 쓰기와 시크릿 접근은 더 자세히 남기는 식으로 갈라 잡습니다.

현장에서 만나는 모습

취약점 하나가 공개된 날, 한 팀이 영향 범위를 세는 데 이틀이 걸렸습니다. 이미지가 전부 태그로 배포돼 있어서 어느 노드의 어느 파드가 어떤 빌드를 돌리는지 확인할 방법이 없었기 때문입니다. 다이제스트로 고정돼 있었다면 한 번의 조회로 끝날 일이었습니다.

이 이야기의 교훈은 다이제스트가 좋다는 것이 아닙니다. 보안 사고의 대부분은 대응이 늦어서 커진다는 것이고, 대응 속도는 사고가 난 뒤에 만들 수 없다는 것입니다.

다음 퀴즈에서 확인할 것

세 집행 자리가 각각 무엇을 놓치는지, 그리고 감사 추적이 성립하려면 무엇이 먼저 있어야 하는지를 확인합니다.