CSAF: 기계가 읽을 수 있는 권고를 위한 Common Security Advisory Framework

CSAF란 무엇입니까?

Common Security Advisory Framework(CSAF)는 OASIS CSAF Technical Committee가 만든 표준으로, 보안 권고를 구조화된 JSON으로 작성하고 자동으로 찾고 처리할 수 있도록 배포하기 위한 것입니다. CSAF 문서는 취약점이 어떤 제품과 버전에 영향을 주는지, 어떤 것이 영향을 받지 않는지, 어떤 것이 수정되었는지, 사용자가 무엇을 해야 하는지를 알려줍니다.

현재 버전은 CSAF 2.0으로, 2022년 11월 18일 OASIS Standard로 승인되었습니다. CSAF 2.1도 준비 중이며, 네 번째 Committee Specification Draft가 2026년 10월 23일부터 11월 6일까지 공개 검토를 거쳤지만 아직 승인된 표준은 아닙니다.

권고는 공급업체, 주로 공급업체의 제품 보안 사고 대응팀(PSIRT)과 국가 CERT 같은 조정 기관이 작성합니다. 두 팀이 어떻게 다른지는 PSIRT vs CSIRT를 참조하세요.

CVRF에서 CSAF로

CSAF는 XML 형식인 Common Vulnerability Reporting Framework(CVRF)에서 발전했습니다. ICASI는 2012년 5월 CVRF 1.1을, OASIS는 2017년 9월 CVRF 1.2를 게시했습니다. CSAF 2.0은 이를 JSON 형식, 검증용 JSON 스키마, 문서 종류별 프로필, 권고의 배포 및 검색 규칙으로 대체했습니다. 사양에는 지금도 CVRF 문서를 CSAF로 변환하는 방법이 정의되어 있습니다.

CSAF 문서 구조

CSAF 문서는 세 개의 최상위 부분으로 구성됩니다.

• document: 메타데이터. 다섯 가지 속성이 필수입니다. 범주(문서가 따르는 프로필), CSAF 버전, 게시자, 제목, 추적 데이터입니다. 추적 데이터에는 권고 ID, 상태, 버전, 최초 및 현재 릴리스 날짜, 개정 이력이 포함됩니다.
• product_tree: 문서에 언급된 모든 제품. 보통 공급업체에서 제품명, 버전으로 이어지는 분기로 표현되며, 문서의 나머지 부분이 참조하는 제품 ID를 가집니다. 제품은 패키지 URL(purl), CPE 또는 해시로도 식별할 수 있습니다.
• vulnerabilities: 취약점마다 하나의 항목으로, CVE 또는 기타 ID, 노트, 점수, 그리고 제품 ID를 목록으로 분류하는 제품 상태를 담습니다. 목록은 known_affected, known_not_affected, fixed, first_affected, last_affected, first_fixed, recommended, under_investigation입니다. 해결 방안은 vendor_fix, workaround, mitigation, no_fix_planned, none_available로 분류됩니다.

CSAF의 5가지 프로필

CSAF 전체로 보면 필수 필드는 많지 않습니다. 프로필은 특정 종류의 문서에 어떤 필드가 있어야 하는지 정하며, /document/category 값이 문서가 따르는 프로필을 나타냅니다.

프로필	범주 값	용도
CSAF Base	csaf_base	모든 CSAF 문서가 충족하는 최소 요건. 다른 프로필에 맞지 않는 문서를 위한 범용 프로필
보안 사고 대응	csaf_security_incident_response	다른 조직에서 발생한 것을 포함해 보안 침해나 사고에 대한 대응
정보성 권고	csaf_informational_advisory	위험한 잘못된 구성처럼 취약점이 아닌 문제
보안 권고	csaf_security_advisory	취약점과 그 해결 방안. 전형적인 공급업체 권고
VEX	csaf_vex	각 제품이 취약점의 영향을 받는지 여부와 그 이유를 진술

보안 권고에는 제품 트리, 취약점, 취약점별 노트, 제품 상태가 있어야 합니다. VEX 프로필은 더 나아가, known_not_affected로 나열된 모든 제품에 기계가 읽을 수 있는 플래그 또는 텍스트 형태의 영향 진술을 요구하고, 모든 known_affected 제품에는 사용자가 무엇을 해야 하는지 알려주는 해결 방안을 요구합니다.

CSAF VEX

VEX(Vulnerability Exploitability eXchange)는 제품 구성 요소의 취약점 중 실제로 제품에 영향을 주는 것이 무엇인지 사용자에게 알려줍니다. CSAF VEX는 OpenVEX, CycloneDX VEX와 함께 널리 쓰이는 세 가지 VEX 형식 중 하나입니다. 플래그는 component_not_present, vulnerable_code_not_in_execute_path 등 CISA의 VEX 요구 사항과 같은 다섯 가지 미영향 근거를 사용합니다. Trivy와 Grype는 모두 CSAF VEX를 읽고, 영향 없음으로 표시된 발견 사항을 제외합니다. 예를 들어 Red Hat은 CSAF VEX 문서를 CSAF 권고 옆의 별도 디렉터리에 게시합니다.

CSAF 권고의 배포 방식

표준 형식은 도구가 문서를 찾을 수 있을 때만 도움이 됩니다. CSAF 2.0의 7장은 그 방법을 정합니다.

• provider-metadata.json은 게시자와 권고의 위치를 설명합니다. 도구는 세 가지 경로 중 최소 하나로 이 파일을 찾습니다. 도메인 security.txt의 CSAF 필드, well-known URL /.well-known/csaf/provider-metadata.json, 또는 도메인 앞에 붙는 DNS 이름 csaf.data.security.입니다.
• 권고 목록은 index.txt와 changes.csv가 있는 연도별 폴더 또는 ROLIE 피드로 제공되며, 리디렉션 없이 TLS로 제공됩니다.
• 각 파일의 이름은 추적 ID를 따릅니다. TLP:WHITE 권고는 자유롭게 접근할 수 있어야 하고, TLP:AMBER나 TLP:RED 권고는 접근 제어 뒤에 있어야 합니다.
• 무결성: trusted provider는 각 문서에 해시와 OpenPGP 서명을 추가하고 공개 키를 게시합니다.

표준은 배포 주체가 맡을 수 있는 다섯 가지 역할을 정의합니다.

역할	하는 일
CSAF publisher	유효한 CSAF 문서를 자사 명의로만 TLS를 통해 게시
CSAF provider	provider-metadata.json, 검색 경로, 디렉터리 또는 ROLIE 피드도 제공하는 publisher
CSAF trusted provider	해시, OpenPGP 서명, 공개 키도 게시하는 provider
CSAF lister	다른 주체의 CSAF 문서를 복사하지 않고 그 위치 목록을 유지
CSAF aggregator	최소 두 개의 독립된 발행 주체의 문서를 해시 및 서명과 함께 한곳에 미러링

소비자는 다운로더를 한 번 설정하면, 수십 개의 공급업체 웹 페이지를 지켜보는 대신 제품이 의존하는 모든 provider에서 새 권고를 가져올 수 있습니다.

CSAF를 게시하는 주체

CSAF는 산업, 엔터프라이즈, 인프라 공급업체와 국가 CERT 사이에서 가장 널리 쓰입니다.

• Cisco는 well-known CSAF URL에서 provider-metadata.json을 제공합니다.
• Siemens ProductCERT는 권고를 CSAF ROLIE 피드로 게시합니다.
• Red Hat은 CSAF 권고와 별도로 CSAF VEX 문서를 게시합니다.
• 독일 국가 CERT인 BSI의 CERT-Bund는 권고의 CSAF 피드를 게시합니다.
• CISA는 2023년 9월 ICS 권고에 2017년까지 거슬러 올라가는 CSAF 문서를 제공한다고 발표하고, 공급업체에 표준 채택을 촉구했습니다.

IEC 62443-4-1에 따라 일하는 산업 공급업체에는 제품의 보안 문제를 사용자에게 알리는 프로세스가 필요하며, 기계가 읽을 수 있는 권고는 고객의 기대에 부응하는 일반적인 방법입니다.

CSAF 도구

• Secvisogram은 BSI의 CSAF 문서용 웹 편집기로, 양식 편집기, JSON 편집기, HTML 미리 보기, 검증 기능을 갖추고 있습니다.
• BSI와 Intevation의 csaf 도구(gocsaf/csaf, 흔히 csaf_distribution이라고 부름)는 trusted provider, checker, aggregator, downloader를 구현하며, CSAF 2.1 버전이 개발 중입니다.
• Trivy, Grype 같은 스캐너는 CSAF VEX 문서를 사용합니다.

웹 페이지와 RSS 피드에서 CSAF로 옮기기

대부분의 공급업체는 다섯 단계로 CSAF로 옮깁니다. 제품과 버전 목록을 정리하고, 필요한 CSAF 역할을 고르고, 검색용 파일과 피드를 게시하고, 권고를 손으로 쓰는 대신 생성하고, 마지막으로 VEX와 과거 권고 아카이브를 더합니다. CSAF로의 전환은 대개 JSON의 문제가 아닙니다. 권고가 가리킬 수 있는 제품 목록과, 기계가 권고를 찾을 수 있는 경로를 갖추는 일입니다.

대부분의 공급업체가 출발하는 지점

흔한 구성은 권고마다 HTML 페이지 하나, 때로는 PDF, RSS 또는 Atom 피드, 메일링 리스트입니다. 사람은 읽을 수 있습니다. 하지만 고객 쪽 도구는 이것으로 할 수 있는 일이 많지 않습니다. 안정적인 제품 식별자가 없고, 버전별 영향 있음·없음 상태가 없고, 공급업체의 모든 권고를 찾을 방법도, 무결성을 확인할 방법도 없습니다. BSI도 같은 문제를 지적합니다. 구독해야 하는 RSS 피드가 있거나, 새 권고가 누군가 직접 방문해야 하는 웹사이트에만 올라온다는 것입니다. 기존 구성의 각 요소에는 CSAF의 대응 요소가 있습니다.

기존 요소	CSAF의 대응 요소
권고 웹 페이지	프로필 csaf_security_advisory를 따르는 CSAF 문서
문장으로 쓴 "영향받는 버전"	product_tree와 product_status
RSS 피드	ROLIE 피드, 또는 index.txt와 changes.csv가 있는 디렉터리
"구독" 페이지	provider-metadata.json과 검색 경로
PDF 서명, 또는 서명 없음	해시와 OpenPGP 서명(trusted provider)
"최종 업데이트" 문구	tracking과 revision_history

RSS 피드는 배포 채널이고, CSAF는 형식입니다. FIRST PSIRT Services Framework는 권고를 전달하는 방법으로 "웹 문서, RSS 피드 또는 구독"을 들고, 이와 별도로 고객이 자동화 도구로 처리할 수 있도록 "Common Security Advisory Framework(CSAF) 같은 기계 판독 가능 형식으로" 권고를 게시할 것을 권합니다. 피드는 그대로 유지할 수 있습니다.

1단계: 제품 목록부터 바로잡기

전환이 실패하는 곳은 product_tree입니다. 첫 CSAF 문서를 내기 전에, 고객이 자기 장비와 자산 목록에서 보는 것과 일치하는 제품과 버전의 기준 목록이 필요합니다. 가능하면 각 항목에 CPE나 package URL을 붙입니다. 이는 PSIRT가 어떤 버전이 CVE의 영향을 받는지 알기 위해 필요한 목록과 같으며, 그래서 PSIRT 확장하기도 버전별 인벤토리에서 시작합니다. 브랜치는 공급업체에서 제품군, 제품, 버전으로 이어집니다.

"product_tree": {
  "branches": [{
    "category": "vendor",
    "name": "Example Networks",
    "branches": [{
      "category": "product_family",
      "name": "EX Series",
      "branches": [{
        "category": "product_name",
        "name": "EX-200",
        "branches": [{
          "category": "product_version",
          "name": "4.2.1",
          "product": {
            "product_id": "EX200-4.2.1",
            "name": "Example Networks EX-200 4.2.1",
            "product_identification_helper": {
              "cpe": "cpe:2.3:o:example:ex-200_firmware:4.2.1:*:*:*:*:*:*:*"
            }
          }
        }]
      }]
    }]
  }]
}

오픈소스 컴포넌트가 들어 있는 제품이라면, 권고에 적는 것은 귀사의 제품 버전입니다. 결정의 근거가 되는 컴포넌트 인벤토리, 즉 어떤 버전에 취약한 라이브러리가 들어 있는지는 SBOM이 담당합니다 (SBOM이란?).

2단계: 역할 고르기

다섯 가지 역할은 위에서 설명했습니다. 공급업체에게 선택지는 사실상 세 가지입니다.

역할	이럴 때 고르세요	추가되는 것
CSAF publisher	우선 자사 사이트에 유효한 CSAF 문서만 있으면 될 때	TLS로 제공되는 유효한 문서. 도구가 스스로 찾지는 못합니다
CSAF provider	고객이 권고를 자동으로 가져가야 할 때. 현실적인 최소 수준	provider-metadata.json, 검색 경로, 디렉터리 또는 ROLIE 피드
CSAF trusted provider	고객이나 당국이 서명된 권고를 기대할 때	해시, OpenPGP 서명, 공개된 공개 키

lister와 aggregator는 조정 기관을 위한 역할이지 공급업체를 위한 역할이 아닙니다. gocsaf/csaf 도구에는 trusted provider를 구현하는 csaf_provider와, provider 구성을 표준 7절에 비추어 검사하는 csaf_checker가 들어 있습니다. 피드를 알리기 전에 checker를 실행하세요.

3단계: 검색 경로와 피드

• provider-metadata.json을 게시하세요. 위치는 자사 도메인의 /.well-known/csaf/입니다.
• security.txt에서 이를 가리키세요. RFC 9116이 이 파일을 정의하고, CSAF 2.0의 요구사항 8이 CSAF: 필드를 추가합니다. URL은 https://로 시작해야 합니다.

Contact: mailto:[email protected]
Expires: 2027-11-11T00:00:00.000Z
# Our security advisories
CSAF: https://www.example.com/.well-known/csaf/provider-metadata.json

• RSS 피드를 ROLIE 피드로 바꾸거나, 둘 다 운영하세요. ROLIE(Resource-Oriented Lightweight Information Exchange, RFC 8322)는 Atom 기반이므로 이미 게시 중인 피드의 자연스러운 후속입니다. index.txt와 changes.csv가 있는 디렉터리도 됩니다.
• 피드마다 TLP 등급을 붙이세요. CSAF 2.0은 TLP 1.0 라벨 WHITE, GREEN, AMBER, RED를 씁니다. 2022년 8월부터 기준이 된 FIRST의 TLP 2.0은 CLEAR, GREEN, AMBER, RED를 쓰고, AMBER의 확장으로 AMBER+STRICT가 있으며, CSAF 2.1 초안은 이 라벨을 채택합니다. CSAF 2.0에서 공개 권고는 TLP:WHITE입니다.

4단계: 손으로 쓰지 말고 생성하기

새 권고는 취약점마다 이미 관리하는 기록, 즉 트래커의 케이스나 취약점 데이터베이스에서 생성하고, 게시 전에 각각을 스키마와 표준의 테스트로 검증합니다. Secvisogram은 건수가 적을 때나 편집할 때 적합합니다. 사람이 읽는 페이지도 같은 JSON 문서에서 만들면 웹 페이지와 CSAF 파일이 어긋나지 않습니다. 개정은 같은 문서의 tracking/version과 revision_history를 갱신하는 것이며, 새 문서를 게시하지 않습니다.

5단계: VEX와 아카이브

고객이 가장 많이 묻는 CVE에 대해서는 영향 없음 진술을 CSAF VEX로 게시하세요. 하나하나가 반복되는 문의 하나를 멈춥니다. 과거 권고는 마지막에, 아직 지원 중인 제품부터 옮깁니다. 과거 권고가 CVRF 형식이라면 사양의 변환 규칙으로 처리할 수 있습니다.

CSAF 2.0인가, 2.1인가?

지금 2.0으로 게시하세요. 2.0은 승인된 OASIS Standard이며 국제 표준 ISO/IEC 20153:2025로도 발행되었습니다. CSAF 2.1은 아직 Committee Specification Draft입니다. 네 번째 초안은 2026년 10월 21일 승인되었고, 공개 검토는 2026년 11월 6일에 끝났습니다. 도구도 준비 중입니다. Secvisogram은 이미 2.1 문서를 편집할 수 있고, gocsaf/csaf 도구는 다음 메이저 버전을 위해 2.1 지원을 개발하고 있습니다.

CRA와 BSI가 기대하는 것

• Cyber Resilience Act는 CSAF를 지정하지 않습니다. 제14조 제8항은 적극적으로 악용되는 취약점이나 심각한 사고를 인지한 제조사가 영향을 받는 사용자, 그리고 적절한 경우 모든 사용자에게 "적절한 경우 구조화되고 기계 판독 가능하며 자동으로 쉽게 처리할 수 있는 형식으로" 알리도록 요구합니다. 부속서 I 제II부는 보안 업데이트가 나오면 수정된 취약점에 관한 정보를 공개하고, 조정된 취약점 공개 정책을 갖추도록 요구합니다. CSAF는 기계 판독 부분을 충족하는 한 가지 방법입니다.
• BSI는 자체 CERT-Bund 권고를 CSAF로 게시합니다. BSI의 기술 지침 TR-03183-3(Vulnerability Reports and Notifications, v1.0.0, 2025년 8월)은 CSAF를 사용해 제조사 웹사이트에 게시하는 것을 권고 배포의 권장 방법으로 제시합니다 (3.1.5절). security.txt 파일을 요구하고(4.2절), 제조사는 그 안에 provider-metadata.json을 CSAF: 필드로 기재해야 한다고 말합니다(4.2.8절). 기술 지침은 지침일 뿐 법이 아닙니다.
• ENISA의 Single Reporting Platform은 CRA에 따른 당국 신고를 위한 것이지 사용자 대상 권고를 위한 것이 아닙니다. CSAF 권고를 게시한다고 신고를 대신할 수 없고, 신고를 했다고 사용자에게 알린 것도 아닙니다.

최소한의 CSAF 구성

• 제품과 버전 목록(가능하면 CPE 또는 package URL 식별자 포함)
• publisher 메타데이터: 이름, 카테고리, 네임스페이스, 연락처
• 프로필 csaf_security_advisory를 따르는 첫 권고
• 스키마와 표준의 테스트로 검증
• provider-metadata.json(/.well-known/csaf/에 배치)
• security.txt의 CSAF: 줄
• ROLIE 피드, 또는 index.txt와 changes.csv가 있는 디렉터리
• 모든 URL에 TLS, 리디렉션 없음
• JSON에서 생성한 사람이 읽는 페이지
• trusted provider로 옮길 때 공개한 서명 키

좋은 보안 권고 작성법

CSAF를 쓰든 쓰지 않든, 유용한 권고는 같은 질문에 답합니다. 다음은 대부분의 PSIRT가 수렴하는 템플릿과, 각 답을 담는 CSAF 필드입니다.

권고 요소	작성할 내용	CSAF에서
ID와 제목	안정적인 권고 ID와, 제품 및 문제 유형을 명시한 제목	tracking/id, title
날짜와 개정	최초 게시일, 최종 업데이트일, 개정마다 바뀐 내용	tracking 날짜 및 revision_history
영향받는 제품	"이전 버전"이 아닌 정확한 제품과 버전 범위	product_tree, known_affected
미영향 및 수정	영향을 받지 않는 제품과 버전, 수정이 포함된 버전	known_not_affected, fixed, first_fixed
취약점	CVE ID, 쉬운 설명, 영향과 악용 방식. 단, 공격자를 위한 방법은 제외	cve, ids, notes
심각도	독자가 확인할 수 있도록 벡터와 함께 CVSS 점수	scores
해결 방안	수정된 버전, 또는 해결책이나 완화 조치, 또는 수정 계획이 없다는 명확한 진술	remediations
감사 표시 및 참고 자료	보고자, 관련 권고 및 수정에 대한 링크	acknowledgments, references
연락처	문제 보고와 문의를 위한 연락처	publisher/contact_details

사람들이 행동에 옮기는 권고와 무시하는 권고는 몇 가지 습관에서 갈립니다.

• 버전을 정확히 밝히세요. 고객은 영향받는 범위를 보고 조치합니다. 제품 라인마다 최초 영향 버전과 최초 수정 버전을 명시하세요.
• 영향을 받지 않는 것을 밝히세요. 배제된 제품을 쓰는 고객은 더 이상 문의하지 않으며, VEX도 게시하면 고객의 스캐너도 더 이상 이를 표시하지 않습니다.
• 교체하지 말고 업데이트하세요. 문제마다 하나의 권고를 유지하고, 수정이 출시될 때마다 개정을 추가하세요.
• 합의한 날짜에 게시하세요. 권고는 조정된 취약점 공개의 마지막 단계로, 수정이 제공되고 보고자에게 알린 뒤에 공개됩니다.

접수와 분류부터 수정까지 권고 이전의 단계는 취약점 관리 수명 주기에서, 이 일을 하는 사람들은 PSIRT 역할에서 다룹니다.

어려운 부분은 무엇이 영향을 받는지 아는 것입니다

CSAF든 다른 형식이든, 모든 권고는 하나의 답에 달려 있습니다. 어떤 제품과 버전에 취약한 구성 요소가 포함되어 있는가입니다. 오픈 소스 패키지로 빌드된 소프트웨어라면, 전이적 종속성을 포함해 각 릴리스에 정확히 어떤 종속성 버전이 들어갔는지 알아야 한다는 뜻입니다.

CRACI는 보안 권고를 작성하거나 게시하지 않습니다. CRACI가 제공하는 것은 권고의 제품 상태를 정하는 근거가 되는 기록입니다. CRACI는 GitHub Actions 빌드를 자체 러너에서 실행하고, 각 잡이 실제로 가져온 패키지를 기록합니다. 전이적 종속성, 캐시에서 복원된 패키지, 어떤 락파일에도 없는 종속성도 포함됩니다. 새 취약점이 공개되면 모니터링 중인 SBOM이 다시 평가되고, 빌드 기록을 보면 어떤 과거 빌드와 릴리스가 취약한 종속성을 직접 또는 전이적으로 포함했는지, 그리고 언제부터인지 알 수 있습니다. 인벤토리 보기는 어떤 버전이 어떤 제품에 배포되었는지 보여주며, 분류를 통해 각 발견 사항을 수정 담당 팀에 배정합니다. SBOM은 CycloneDX 또는 SPDX로 내보낼 수 있으며, CRACI는 VEX를 지원합니다. 취약점 추적을 참고하세요.

CSAF: 자주 묻는 질문

CSAF는 무엇의 약자입니까?

보안 분야에서 CSAF는 Common Security Advisory Framework의 약자로, 보안 권고를 기계가 읽을 수 있는 JSON 문서로 작성하고 도구가 자동으로 찾아 처리할 수 있도록 배포하기 위한 OASIS 표준입니다.

CSAF의 현재 버전은 무엇입니까?

CSAF 2.0입니다. 2022년 11월 18일 OASIS Standard로 승인되었고 ISO/IEC 20153:2025로도 발행되었습니다. CSAF 2.1은 작업 중이며, 네 번째 Committee Specification Draft가 2026년 10월 21일 승인되어 2026년 11월 6일 공개 검토를 마쳤습니다. 아직 승인된 OASIS Standard는 아닙니다.

CSAF와 CVE의 차이는 무엇입니까?

CVE 레코드는 하나의 취약점을 식별하고 일반적인 용어로 설명합니다. CSAF 권고는 공급업체나 조정 기관이 게시하며, 해당 취약점(그리고 흔히 다른 여러 취약점)이 특정 제품과 버전에 어떤 영향을 주는지, 어떻게 대응해야 하는지를 알려줍니다. CSAF 권고는 CVE ID를 참조합니다.

CSAF VEX란 무엇입니까?

CSAF VEX는 CSAF의 csaf_vex 프로필입니다. VEX 진술을 담습니다. 즉 각 제품이 영향을 받는지, 받지 않는지, 수정되었는지, 조사 중인지를 나타내며, 영향을 받지 않는 제품에는 영향 진술을, 영향을 받는 제품에는 해결 방안을 포함합니다. Trivy와 Grype는 이를 읽어 발견 사항을 억제할 수 있습니다.

CSAF provider란 무엇입니까?

CSAF provider는 도구가 찾을 수 있는 방식으로 자체 CSAF 문서를 게시하는 조직입니다. security.txt, well-known URL 또는 DNS 이름을 통해 찾을 수 있는 provider-metadata.json 파일과, 권고의 디렉터리 또는 ROLIE 피드를 제공합니다. trusted provider는 여기에 해시, OpenPGP 서명, 공개된 공개 키를 추가합니다.

CSAF는 무엇을 대체했습니까?

XML 형식인 Common Vulnerability Reporting Framework(CVRF)입니다. CVRF 1.1은 2012년 ICASI가, CVRF 1.2는 2017년 OASIS가 게시했습니다. CSAF 2.0은 JSON으로 전환하고 프로필, 제품 트리, 배포 규칙을 추가했습니다.

CSAF 권고는 어떻게 작성합니까?

대부분의 팀은 BSI의 CSAF 웹 편집기인 Secvisogram 같은 편집기로 시작하거나, 자체 취약점 추적 데이터에서 JSON을 생성합니다. 프로필(보통 csaf_security_advisory)을 선택하고, 게시자, 추적 데이터, 제품 트리, 취약점을 채운 뒤, 스키마로 검증하고 provider를 통해 게시합니다.

보안 권고를 웹 페이지에서 CSAF로 옮기려면 어떻게 하나요?

먼저 제품과 버전의 기준 목록을 만들고, 다음으로 CSAF provider가 되세요. provider-metadata.json을 게시하고, security.txt에서 이를 가리키고, ROLIE 피드나 디렉터리에 권고를 나열합니다. 새 권고는 취약점 기록에서 생성하고, 웹 페이지도 같은 JSON에서 만들고, 과거 권고는 마지막에 옮기세요.

CSAF를 게시해도 RSS 피드를 유지할 수 있나요?

네. RSS 피드는 배포 채널이고 CSAF는 형식이므로 함께 둘 수 있습니다. 사람과 기계 모두를 위한 피드 하나를 원한다면, ROLIE 피드는 Atom 기반이라 RSS 피드를 대체할 수 있습니다. 두 피드를 같은 권고 데이터에서 생성하면 내용이 어긋나지 않습니다.

어떤 CSAF 역할이 필요한가요: publisher, provider, trusted provider?

대부분의 공급업체에는 CSAF provider 역할이 필요합니다. 유효한 문서, provider-metadata.json, 검색 경로, 디렉터리 또는 ROLIE 피드를 갖춰 고객이 권고를 자동으로 가져갈 수 있게 합니다. publisher만으로는 도구가 찾지 못하는 출발점에 그칩니다. 고객이나 당국이 서명된 권고를 기대하면 해시, OpenPGP 서명, 공개 키를 갖춘 trusted provider가 되세요.

Cyber Resilience Act가 CSAF를 요구하나요?

아니요. CRA는 형식을 지정하지 않습니다. 제14조 제8항은 적극적으로 악용되는 취약점이나 심각한 사고에 대해 영향을 받는 사용자에게, 적절한 경우 구조화되고 기계 판독 가능하며 자동 처리가 쉬운 형식으로 알리도록 제조사에 요구합니다. CSAF는 이를 충족하는 한 가지 방법이며, BSI가 권장하는 형식입니다.

BSI는 CSAF와 관련해 제조사에 무엇을 기대하나요?

BSI TR-03183-3은 법이 아닌 기술 지침으로, CSAF를 사용해 제조사 웹사이트에 게시하는 것을 권고 배포의 권장 방법으로 제시합니다. security.txt 파일을 요구하며, 제조사는 그 안에 provider-metadata.json을 CSAF: 필드로 기재해야 한다고 말합니다. BSI는 자체 CERT-Bund 권고를 CSAF로 게시합니다.

CSAF 2.0으로 게시할까요, 2.1을 기다릴까요?

지금 2.0으로 게시하세요. 승인된 OASIS Standard이자 ISO/IEC 20153:2025이며, 도구도 지원합니다. CSAF 2.1은 아직 Committee Specification Draft이고, 네 번째 초안은 2026년 10월과 11월에 검토되었습니다. 나중에 2.1로 옮기는 일은 도구 업데이트로 충분하므로 기다릴 이유가 되지 않습니다.