测验：供应链证明比对

증빙 문서의 서명 검증이 통과했는데, 그 문서의 subject digest 가 받은 산출물의 지문과 다르다. 이 상황을 가장 정확히 설명한 것은?

• 서명이 유효하므로 증빙과 산출물은 같은 것을 가리킨다고 보아도 된다
• 서명 알고리즘이 달라 생긴 오탐이므로 같은 해시 알고리즘으로 다시 검증한다
• 문서가 바뀌지 않았다는 것만 확인된 것이고, 이 증빙은 받은 산출물의 근거가 아니다
• 전송 중 손상이므로 산출물을 다시 받아 지문이 맞는지 확인하면 해결된다

in-toto Statement v1 에서 '이 증빙이 어느 산출물에 대한 것인가' 를 정하는 자리는 어디인가?

• subject 배열의 각 원소에 있는 digest
• predicateType 이 가리키는 술어 명세 문서의 이름
• predicate 안의 buildDefinition.externalParameters
• 증빙을 감싼 서명 봉투 파일의 이름과 확장자

SLSA Provenance v1 의 predicate 만 읽어서 답할 수 있는 것은?

• 빌드에 들어간 의존성에 알려진 취약점이 없는지
• 빌드한 소스가 코드 검토와 승인을 거쳤는지
• 이 파일이 빌드가 끝난 뒤로 손대지 않은 그대로인지
• 어느 빌드 플랫폼이 어떤 외부 인자로 빌드를 돌렸는지

CycloneDX SBOM 과 실제 산출물 트리를 대조할 때 양방향으로 보아야 하는 이유로 가장 알맞은 것은?

• components 배열의 순서가 파일 시스템 순서와 달라 한쪽만 보면 정렬이 어긋나기 때문
• 문서에만 있는 항목과 트리에만 있는 파일은 서로 다른 문제이고, 한쪽만 보면 나머지가 안 보이기 때문
• specVersion 이 1.6 미만이면 hashes 필드가 없어 이름만으로 맞춰야 하기 때문
• metadata.component 가 components 에도 함께 들어가 이중 계산이 생기기 때문

증빙 묶음에 predicateType 이 우리가 읽을 줄 모르는 URI 인 문서가 섞여 있다. 폐쇄망에서 이 문서를 다루는 방법으로 가장 알맞은 것은?

• 술어를 몰라도 서명이 유효하면 확인된 증빙으로 세어 승인 근거에 넣는다
• 술어를 해석할 수 없으면 검증이 불가능하므로 그 자리에서 반입을 거절한다
• 통과의 근거로 세지 않고 보류로 둔 뒤, 술어의 뜻을 아는 경로로 따로 확인한다
• predicateType 의 URI 를 열어 명세를 받아 온 뒤 그 자리에서 해석해 판정한다

검증에 쓴 공개키가 증빙 묶음과 같은 매체로 함께 들어왔다. 심사 보고서에 어떻게 적는 것이 맞는가?

• 서명 검증은 통과했다고 적되, 그 키가 발주처의 것인지는 확인하지 못했다고 따로 적는다
• 공개키가 함께 왔으므로 서명 검증 결과에 키 소유 확인까지 포함된 것으로 적는다
• 공개키를 믿을 수 없으므로 서명 검증 결과 자체를 보고서에서 빼고 적지 않는다
• 투명성 로그에서 인증서를 조회해 발급자를 확인한 뒤 그 결과를 함께 적는다