추가 보안 패치

위험 기반 보안 업데이트의 일환으로 Android가 지속적 출시 및 분기별 게시판 으로 전환됨에 따라 OEM은 전체 분기를 기다리는 대신 출시 간에 취약점을 수정할 수 있습니다. 보안 패치 추가 XML 기능을 사용하면 OEM이 표준화된 XML 파일을 제공하여 선언된 보안 패치 수준 (SPL)을 초과하여 패치된 CVE를 보고할 수 있으므로 OEM은 지속적인 패치에 대한 크레딧을 받습니다.

대략적인 흐름

OEM 시스템, 공급업체, 제품 파티션에서 AOSP 프레임워크 API로의 보충 보안 패치 XML 데이터 흐름을 보여주는 다이어그램

그림 1. 보안 패치 추가 아키텍처 및 데이터 흐름

OEM은 여러 기기 파티션 (/system, /vendor 또는 /product)에 XML 파일을 배치하여 프레임워크 및 하드웨어별 구성요소의 보안 패치가 모두 고려되도록 할 수 있습니다. XML 파일은 각 파티션의 /etc/security/supplemental_security_patches.xml에 설치해야 합니다.

플랫폼은 이러한 기기 파티션 전반에서 CVE 데이터를 집계하고 플랫폼 API 및 Jetpack 라이브러리에 노출합니다. 자세한 내용은 플랫폼 API Android 17 이상 및 이전 Android 버전으로 백포팅을 참고하세요.

다음 예는 Android 지원 기기에 설치된 보안 패치 추가 XML 파일의 샘플을 보여줍니다.

<?xml version="1.0" encoding="utf-8"?>
<security-patches xmlns="http://schemas.android.com/security/patches/1.0">
    <patch><id>CVE-2026-12345</id></patch>
</security-patches>

플랫폼 API (Android 17 이상)

Android 17 (API 수준 37) 이상의 경우 플랫폼의 SecurityStateManager는 지원되는 모든 파티션 위치에서 추가 패치를 파싱하고 getGlobalSecurityState에서 반환된 번들에 KEY_SYSTEM_SUPPLEMENTAL_PATCHES 및 KEY_VENDOR_SUPPLEMENTAL_PATCHES 키를 사용하여 노출합니다.

시스템 서비스 SecurityStateManagerService는 파티션 XML 파일을 다음 두 가지 포괄적인 보고 버킷으로 집계합니다.

  • KEY_SYSTEM_SUPPLEMENTAL_PATCHES: /system, /system_ext, /product 파티션 경로의 패치를 집계합니다.
  • KEY_VENDOR_SUPPLEMENTAL_PATCHES: /vendor 및 /odm 파티션 경로의 패치를 집계합니다.

이전 Android 버전으로 백포팅

Android 16 이하에서는 플랫폼 API가 지원되지 않습니다. 대신 Jetpack androidx.security:security-state 라이브러리 (SecurityStateManagerCompat) 는 XmlPullParser를 사용하여 XML 파일을 수동으로 읽습니다. untrusted_app 도메인이 Android 16 이하에서 파일을 읽을 수 있도록 하려면 OEM은 XML 파일이 설치된 모든 파티션 경로에서 다음 SELinux 변경사항을 구현해야 합니다.

file_contexts:

/(system|vendor|product|system_ext|odm)/etc/security/supplemental_security_patches\.xml u:object_r:supplemental_security_patches:s0

supplemental_security_patches.te:

allow untrusted_app supplemental_security_patches:file { getattr open read };

빌드 규칙 및 스키마 유효성 검사

보안 패치 추가 XML 파일을 /vendor/etc/security/, /system/etc/security/, 또는 /product/etc/security/에 설치하려면 prebuilt_etc 규칙 을 Android.bp에 추가합니다. SecurityStateManagerService는 기기의 파일 이름이 정확히 supplemental_security_patches.xml이어야 하므로 파티션별 모듈 이름을 사용할 때는 filename 속성을 사용합니다.

// For vendor partition (/vendor/etc/security/supplemental_security_patches.xml)
prebuilt_etc {
    name: "vendor_supplemental_security_patches.xml",
    src: "supplemental_security_patches.xml",
    filename: "supplemental_security_patches.xml",
    sub_dir: "security",
    vendor: true,
}
// For system partition (/system/etc/security/supplemental_security_patches.xml)
prebuilt_etc {
    name: "system_supplemental_security_patches.xml",
    src: "supplemental_security_patches.xml",
    filename: "supplemental_security_patches.xml",
    sub_dir: "security",
}
// For product partition (/product/etc/security/supplemental_security_patches.xml)
prebuilt_etc {
    name: "product_supplemental_security_patches.xml",
    src: "supplemental_security_patches.xml",
    filename: "supplemental_security_patches.xml",
    sub_dir: "security",
    product_specific: true,
}

Android 오픈소스 프로젝트 (AOSP)는 supplemental_security_patches.xsd 에 XSD 스키마를 포함하고 빌드 프로세스 중에 xsdc 빌드 규칙을 사용하여 XML 파일 형식을 검증합니다.Android.bp

xsdc {
    name: "supplemental_security_patches_xsd",
    srcs: ["supplemental_security_patches/supplemental_security_patches.xsd"],
    package_name: "android.security.patches", // Java package name for generated code
}

xmllint를 사용하여 XSD 스키마에 대해 XML 파일을 로컬로 검증할 수도 있습니다.

xmllint --schema frameworks/base/services/core/xsd/supplemental_security_patches/supplemental_security_patches.xsd --noout supplemental_security_patches.xml

테스트 및 모음 통합

보안 테스트 모음 (STS) 및 펌웨어 분석 (BTS)은 supplemental_security_patches.xml 파일의 데이터를 사용하여 XML 파일에 있는 취약점에 대한 패치 분석을 확장합니다. 따라서 이 파일을 올바르게 통합하면 기기의 보안 상태를 반영하는 것 외에도 OEM은 분기별 SPL이 공식적으로 선언될 때까지 기다리는 대신 기기의 SPL보다 높게 패치된 취약점에 대한 사전 패치 분석을 실행할 수 있습니다.