Claude는 이제 생성하는 파일에 서명된 C2PA 출처 메타데이터를 첨부합니다. OpenAI의 이미지 모델도 마찬가지이고, Gemini도 마찬가지입니다. 이는 출처 신호가 처음으로 업로드 엔드포인트에 도달한다는 것을 의미하며, 다른 사람이 보기 전에 파이프라인이 이를 삭제할 가능성이 높습니다.
악의적으로 삭제하는 것이 아닙니다. 기본 설정이 그렇습니다. sharp().resize()는 별도로 요청하지 않는 한 메타데이터가 없는 깨끗한 파일을 생성합니다. ImageMagick도, Pillow도, 대부분의 이미지 CDN도 마찬가지입니다. 매니페스트가 들어가면 더 작은 JPEG가 나오지만, 로그에는 아무것도 언급되지 않습니다.
이것은 테스트 가능한 실패이며, 테스트는 복잡하지 않습니다. 일반적인 파이프라인에서 메타데이터가 어떻게 소멸되는지, 이러한 현상이 발생하고 있음을 증명하는 방법, 그리고 CI에 왕복 검사를 연결하여 다시 발생하지 않도록 하는 방법을 설명합니다. Apidog가 오케스트레이션을 처리하고, c2patool이 바이트 수준 검증을 처리합니다.
실제로 파괴되는 것
C2PA 매니페스트는 파일 컨테이너에 내장된 암호화 서명 블록입니다. 자산을 누가 서명했고, 무엇을 주장했는지를 기록하며, 서명되어 있기 때문에 다시 서명하지 않고 바이트를 변경하면 어떤 리더든 감지할 수 있는 방식으로 서명이 깨집니다.
여기서 핵심 구문은 "컨테이너 수준"입니다. 컨테이너를 다시 작성하면 매니페스트는 사라집니다.
| 작업 | 매니페스트는 기본적으로 보존됩니까? |
|---|---|
| 바이트 단위 복사 또는 이동 | 예 |
sharp().resize().toBuffer() |
아니오 |
ImageMagick convert / magick |
아니오 |
Pillow Image.save() |
아니오 |
| PNG에서 WebP, JPEG에서 AVIF로 | 아니오 |
| 이미지 CDN 자동 최적화 | 대부분 아니오 |
| 스크린샷 | 아니오 |
| 이미지 편집기에서 다시 저장 | 아니오 |
| 변환 없는 S3 업로드 | 예 |
"아니오" 열에 있는 모든 항목은 일반적인 웹 앱이 받아들이는 모든 이미지에 대해 수행하는 작업입니다. 썸네일, 반응형 변형, 형식 협상, 개인 정보 보호를 위한 EXIF 제거. 각 작업은 개별적으로는 합리적이지만, 각각은 조용히 출처 체인을 끝냅니다.
주목할 점: 개인 정보 보호를 위한 -strip 습관은 종종 의도적입니다. EXIF는 GPS 좌표와 카메라 일련 번호를 포함하기 때문입니다. 위치 데이터를 제거하기 위해 모든 메타데이터를 제거하면 출처 매니페스트도 제거됩니다. 이 두 목표는 이제 충돌하며, 이를 해결하려면 전체 블록을 삭제하는 대신 선택적으로 접근해야 합니다.
2분 안에 증명하기
무언가를 구축하기 전에 문제가 있는지 확인하십시오. 유효한 매니페스트가 있는 파일 하나가 필요합니다. Claude가 생성하는 모든 이미지나 Content Authenticity Initiative에서 서명된 샘플을 가져올 수 있습니다.
참조 CLI를 설치합니다:
cargo install c2patool
피쳐가 실제로 서명되었는지 확인합니다:
c2patool fixtures/signed-sample.png
청구 생성자와 서명 상태를 나타내는 JSON 보고서를 받아야 합니다. 이제 자체 스택을 통해 푸시하고 다른 쪽 끝을 확인합니다:
# 실제 엔드포인트를 통해 업로드
curl -sS -X POST https://api.example.com/v1/assets \
-H "Authorization: Bearer $API_TOKEN" \
-F "file=@fixtures/signed-sample.png" \
-o /tmp/upload.json
# 프론트엔드가 사용할 URL을 통해 다시 가져오기
ASSET_URL=$(jq -r '.url' /tmp/upload.json)
curl -sS "$ASSET_URL" -o /tmp/roundtrip.png
# 매니페스트가 보존되었습니까?
c2patool /tmp/roundtrip.png
세 가지 가능한 결과가 있으며, 각각 다른 것을 의미합니다:
- 유효한 보고서. 매니페스트가 보존되었습니다. 좋습니다.
- 매니페스트를 찾을 수 없음. 파이프라인의 무언가가 제거했습니다. 이것이 흔한 경우입니다.
- 유효성 검사 오류. 매니페스트는 존재하지만 서명이 더 이상 바이트와 일치하지 않습니다. 무언가가 파일을 수정하고 이전 매니페스트를 남겨두었는데, 이는 제거하는 것보다 더 나쁩니다. 다운스트림 검증기에게는 변조된 것처럼 보이기 때문입니다.
세 번째 결과가 찾아야 할 것입니다. 일반적으로 변환 라이브러리가 픽셀을 다시 작성하면서 메타데이터 블록을 보존했음을 의미합니다.
문제를 일으키는 단계를 찾기
왕복이 실패하면 파이프라인을 이분법적으로 검사하십시오. 추측하는 대신 각 단계 직후에 매니페스트를 확인하십시오.
가능성이 높은 순서대로 일반적인 용의자:
1. 크기 조정 또는 썸네일 단계. 가장 유력한 범인입니다. sharp에서는 명시적으로 유지하도록 요청하지 않는 한 메타데이터가 삭제됩니다:
// C2PA 매니페스트를 삭제합니다.
await sharp(input).resize(1200).toFile(output);
// 메타데이터 블록을 보존합니다.
await sharp(input).resize(1200).keepMetadata().toFile(output);
블록을 보존하는 것은 필수적이지만 충분하지 않습니다. 픽셀이 변경되었으므로 원래 서명은 새 바이트에 대해 더 이상 유효하지 않습니다. 작동하는 출처 체인을 유지하려면 출력을 다시 서명하고 변환을 작업 단언(일반적으로 c2pa.resized)으로 기록해야 합니다. Rust, Python, JavaScript 및 C용 c2pa 라이브러리는 모두 이를 지원합니다.
2. 형식 변환. AVIF 또는 WebP를 서비스하는 것은 새로운 컨테이너를 의미합니다. 동일한 규칙: 보존하고 다시 서명하거나, 체인이 거기서 끝나고 그렇게 말해야 합니다.
3. CDN. 많은 이미지 CDN은 배포 시 다시 작성합니다. 일부는 이제 Content Credentials를 기본적으로 보존하고 다시 서명합니다. 대부분은 역사적으로 이를 제거했습니다. 원본을 통해서가 아니라 사용자가 실제로 접속하는 배포 URL을 통해 테스트하십시오. 그렇지 않으면 아무 의미 없는 녹색 결과를 얻게 될 것입니다.
4. 업로드 정규화. 형식을 표준화하기 위해 수집 시 다시 인코딩하는 서비스는 잊기 쉽습니다. 코드가 아무도 읽지 않는 인프라 리포지토리에 있기 때문입니다.
영구적인 테스트로 만들기
일회성 curl은 현재 상태를 증명합니다. 다음 스프린트에 누군가가 크기 조정 단계를 추가하는 것을 막지 못합니다. 검사는 CI에 있어야 합니다.
서로 다른 두 가지 도구가 서로 다른 두 가지 작업을 잘 수행하므로 두 개의 계층으로 나눕니다.
첫 번째 계층: Apidog에서의 왕복
오케스트레이션은 일반적인 연쇄 API 테스트입니다: 피쳐를 업로드하고, 반환된 URL을 캡처하고, 실제 전달 경로를 통해 자산을 다시 가져오고, 반환되는 것을 단언합니다.
Apidog에서는 두 단계로 구성된 테스트 시나리오입니다.
단계 1: POST /v1/assets
- 본문: 서명된 피쳐가 첨부된
multipart/form-data. 메커니즘은 파일 업로드 API 테스트와 동일합니다. - 단언: 상태는
201이고, 응답은 스키마와 일치합니다. - URL을 다음 단계로 전달하는 응답 후 스크립트:
const body = pm.response.json();
pm.environment.set("ASSET_URL", body.url);
pm.test("업로드는 배달 URL을 반환합니다", function () {
pm.expect(body.url).to.be.a("string").and.to.include("https://");
});
단계 2: GET {{ASSET_URL}}
- 단언: 상태는
200이고,Content-Type은 예상하는 형식이며, 본문 크기는 업로드한 것과 비슷합니다. 극적인 크기 감소는 파일이 다시 인코딩되었다는 강력한 힌트입니다.
const uploadedBytes = Number(pm.environment.get("FIXTURE_BYTES"));
const returnedBytes = pm.response.responseSize;
pm.test("자산이 조용히 다시 인코딩되지 않았습니다", function () {
pm.expect(returnedBytes).to.be.above(uploadedBytes * 0.9);
});
크기는 증거가 아닌 휴리스틱입니다. 시끄러운 실패를 저렴하게 잡아내고 다른 모든 것과 동일한 스위트에서 실행됩니다. 표준 단언 패턴은 API 단언에서 다룹니다.
두 번째 계층: CI의 바이트 수준 검사
서명을 확인하는 것은 컨테이너를 파싱하는 것을 의미하며, 이는 HTTP 클라이언트의 작업이 아닌 c2patool의 작업입니다. 왕복으로 가져온 파일에 대해 파이프라인 단계로 실행합니다:
# .github/workflows/provenance.yml
name: provenance
on: [pull_request]
jobs:
c2pa-round-trip:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: c2patool 설치
run: cargo install c2patool
- name: Apidog CLI 설치
run: npm install -g apidog-cli
- name: 왕복 시나리오 실행
run: |
apidog run --access-token "$APIDOG_ACCESS_TOKEN" \
-t "$SCENARIO_ID" -e "$ENV_ID" -r cli,html --out-dir ./apidog-reports
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
SCENARIO_ID: ${{ vars.PROVENANCE_SCENARIO_ID }}
ENV_ID: ${{ vars.APIDOG_ENV_ID }}
- name: 매니페스트 보존 여부 확인
run: |
set -euo pipefail
curl -sS "$ASSET_URL" -o /tmp/roundtrip.png
c2patool /tmp/roundtrip.png > /tmp/report.json
jq -e '.validation_status == null or (.validation_status | length) == 0' /tmp/report.json
set -euo pipefail이 중요합니다. 이것이 없으면, 제거된 파일에서 c2patool이 실패하더라도 경고만 발생하고 빌드는 성공하게 되는데, 이는 정확히 방지하려고 했던 실패입니다. 파이프라인에서 Apidog 시나리오를 실행하는 데 익숙하지 않다면, GitHub Actions에서 API 테스트 자동화가 설정을 다룹니다.
세 번째 계층 (선택 사항): 검증 엔드포인트
출처가 내부 검사가 아닌 제품 기능이라면, 가장 깔끔한 디자인은 c2pa 라이브러리를 실행하고 구조화된 결과를 반환하는 자체 서비스 내의 작은 엔드포인트입니다. 그러면 전체가 일반 JSON으로 테스트 가능하며, 프론트엔드는 추측 대신 실제 답변을 얻게 됩니다.
{
"asset_id": "img_9f2c41",
"provenance": {
"status": "verified",
"standard": "c2pa",
"signer": "Anthropic",
"signature_valid": true,
"checked_at": "2026-08-11T09:14:22Z",
"tool": "c2patool/0.9"
}
}
두 가지가 아닌 세 가지 상태를 유지하십시오. verified, absent, invalid는 실제로 다른 것을 의미하며, absent와 invalid를 하나의 부울로 합치는 것은 가장 흥미로운 신호를 버리는 것입니다. 검증기가 사용 불가능할 수 있다면 unchecked를 추가하여 중단이 깨끗한 결과로 가장하지 않도록 하십시오.
OpenAPI 정의에 모양을 문서화하고 이에 대해 유효성을 검사하여 필드가 리팩토링에서 사라지지 않도록 하십시오. OpenAPI 사양 유효성 검사 방법이 이 측면을 다룹니다.
유지할 가치가 있는 네 가지 피쳐
출처 스위트는 해피 경로뿐만 아니라 의도적으로 손상된 입력을 필요로 합니다.
- 유효하게 서명된 파일.
verified를 예상합니다. 지나친 제거를 잡아냅니다. - 제거된 파일. 동일한 이미지에서
exiftool -all=로 매니페스트를 제거한 파일. 오류가 아니라absent를 예상하고,verified는 절대 예상하지 않습니다. - 변조된 파일. 서명 후 바이트가 변경된 서명된 파일.
invalid를 예상합니다. 이는 블록이 존재하는지 확인하는 것이 아니라 서명을 확인하고 있음을 증명하는 것입니다. - 지원되지 않는 형식. 매니페스트 지원이 전혀 없는 형식. 500 오류가 아니라 깨끗한
absent를 예상합니다.
네 가지 모두를 테스트 시나리오 옆에 있는 리포지토리에 커밋하십시오. 작고, 변경되지 않으며, 통과하는 테스트와 의미 있는 테스트의 차이점입니다.
왜 귀찮게 해야 하는가
세 가지 이유가 있으며, 비용이 많이 드는 순서대로 나열합니다.
제품 주장. UI에 출처 배지가 표시되는데, 파이프라인이 매니페스트를 제거한다면, 크기 조정을 거친 모든 자산에 대해 배지가 잘못된 것입니다. 이는 사용자가 발견하게 될 신뢰 문제입니다.
규정 준수 스토리. Article 50과 관련하여 C2PA에 의존하고 있다면, 제거된 매니페스트는 작동하지 않는 통제 수단입니다. API 개발자를 위한 EU AI법 Article 50에서 실제로 당신에게 있는 의무를 설명합니다.
신호 자체. 출처는 체인이 처음부터 끝까지 유지될 때만 작동합니다. 매니페스트를 조용히 삭제하는 모든 파이프라인은 전체 생태계를 덜 유용하게 만듭니다. 당신이 무언가를 확인하려고 할 때도 마찬가지입니다.
자신의 엔드포인트에 대해 왕복 시나리오를 구축하려면 Apidog를 다운로드하고, 그 뒤에 c2patool 단계를 연결하십시오.
FAQ
이미지 크기를 조정하면 C2PA 메타데이터가 제거됩니까? 예, 모든 일반 라이브러리에서 기본적으로 그렇습니다. 메타데이터 블록을 보존하려면 명시적인 플래그가 필요하며, 유효한 서명을 유지하려면 변환된 출력을 다시 서명해야 합니다.
파일에 C2PA 메타데이터가 있는지 어떻게 확인합니까? 명령줄에서 c2patool <file>을 실행하거나 파일을 Content Credentials 확인 페이지에 드롭합니다.
크기 조정을 통해서도 C2PA 메타데이터를 유지할 수 있습니까? 예, 하지만 보존만으로는 안 됩니다. 블록을 보존한 다음, c2pa 라이브러리 중 하나를 사용하여 c2pa.resized와 같은 작업 단언으로 출력을 다시 서명해야 합니다. 그렇지 않으면 이전 서명이 새 바이트와 더 이상 일치하지 않습니다.
CDN은 Content Credentials를 제거합니까? 자동 최적화 시 많은 CDN이 제거합니다. 일부는 이제 기본적으로 보존하고 다시 서명합니다. 원본을 통해서가 아니라 사용자가 접속하는 배포 URL을 통해 테스트하십시오.
제거된 매니페스트와 유효하지 않은 매니페스트의 차이점은 무엇입니까? 제거됨은 매니페스트가 발견되지 않았음을 의미하며, 파일의 출처에 대해 아무것도 알려주지 않습니다. 유효하지 않음은 매니페스트가 존재하지만 서명이 바이트와 일치하지 않음을 의미하며, 이는 서명 후 파일이 변경되었음을 의미합니다. 이들을 별도의 상태로 유지하십시오.
Apidog가 C2PA 서명을 직접 확인할 수 있습니까? Apidog는 왕복을 오케스트레이션하고 검증 엔드포인트의 JSON을 포함한 HTTP 응답을 단언합니다. 서명 파싱 자체는 CI 단계로 실행되거나 자체 서비스 내에서 실행되는 c2patool의 작업입니다. 둘을 함께 사용하십시오.
개인 정보 보호를 위해 EXIF를 제거하되 C2PA는 유지해야 합니까? 그것이 올바른 목표이며 선택적인 접근 방식이 필요합니다. 포괄적인 -strip은 둘 다 제거합니다. 특히 우려되는 EXIF 블록을 제거하고 C2PA 매니페스트는 그대로 두십시오.
핵심 요점
출처 메타데이터는 API에 온전하게 도착하지만 일반적으로 조각조각 사라지며, 모니터링에서는 아무것도 알려주지 않습니다. 해결책은 실제 전달 경로를 통한 왕복과 빌드를 실패시키는 c2patool 검사입니다.
20분만 설정하면, UI에서 하고 있는 주장이 파이프라인이 실제로 시행하는 보장이 됩니다.