장기적인 Android 보안을 위한 제조업체 가이드

이 가이드에서는 Android 호환성 테스트 모음(CTS)으로 평가되는 보안 패치를 적용하기 위한 Google 권장사항을 설명합니다. 3년 넘게 지원되는 차량, TV, 셋톱 박스, 가전제품 등의 Android 호환 OEM 장비를 생산하는 제조업체('제조업체'로 통칭)를 대상으로 합니다. 이 가이드는 최종 사용자(예: 차량 소유자)를 대상으로 하지 않습니다.

감사의 말씀 및 면책 조항

이 가이드는 Google 또는 다른 제조업체에 관해 법적으로나 계약상 구속력을 지니지 않으며 일련의 요구사항을 제시하지 않습니다. 이 가이드는 권장되는 방법을 설명하는 안내 자료입니다.

의견

이 가이드는 포괄적이지 않습니다. 추가 수정이 예정되어 있습니다. 의견이 있으면 manufacturers-guide-android@googlegroups.com으로 제출해 주세요.

용어집

용어	정의
ACC	Android 호환성 약정. 이전에는 Android 세분화 방지 계약(AFA)이라고 했습니다.
AOSP	Android 오픈소스 프로젝트
ASB	Android 보안 게시판
BSP	보드 서포트 패키지
CDD	호환성 정의 문서
CTS	호환성 테스트 모음
FOTA	펌웨어 무선 업데이트
GPS	위성 위치 확인 시스템
MISRA	자동차 산업 소프트웨어 안정성 협회
NIST	미국 국립 표준 기술 연구소
OBD	온보드 진단기(OBD-II는 기능과 표준화 측면 모두 OBD-I에서 향상됨)
OEM	OEM
OS	운영체제
SEI	소프트웨어 엔지니어링 연구소
SoC	단일 칩 시스템
SOP	양산 시작
SPL	보안 패치 수준
TPMS	타이어압 모니터링 시스템

Android OS 정보

Android는 다양한 기기와 폼 팩터를 위해 설계된 Linux 기반 오픈소스 전체 소프트웨어 스택입니다. 2008년 첫 출시 이후 Android는 가장 많이 사용되는 운영체제(OS)가 되어 전 세계에서 14억 대 이상의 기기(2016년 기준)를 구동하고 있습니다. 이러한 기기의 약 67%는 2017년 3월 기준으로 Android 5.0(Lollipop) 이상을 사용합니다(최신 수치는 Android 대시보드에서 확인 가능). 대부분의 기기가 휴대전화와 태블릿이지만 스마트시계, TV, 차량용 인포테인먼트(IVI) 기기에서도 Android가 점차 성장하고 있습니다.

Google Play 스토어에서 사용할 수 있는 Android 앱 수는 220만 개에 달합니다(2016년). Android 호환성 프로그램에서 Android 앱 개발을 지원합니다. 이 호환성 프로그램은 호환성 정의 문서(CDD)를 통해 요구사항 세트를 정의하고 호환성 테스트 모음(CTS)을 통해 테스트 도구를 제공합니다. Android 호환성 프로그램은 Android 앱이 앱의 필수 기능을 지원하는 모든 Android 호환 기기에서 실행될 수 있도록 보장합니다.

Google은 정기적으로 새로운 OS 버전과 OS 보안 업데이트를 출시하고 발견된 취약점 관련 정보를 발표합니다. 제조업체는 Android 보안 게시판을 검토하여 이러한 Android OS 지원 제품 업데이트의 적용 여부를 확인해야 합니다. Android 보안, 호환성, 빌드 시스템을 검토하려면 다음을 참고하세요.

연결된 차량(표준 장기 지속 제품) 정보

차량은 1920년대에 AM 라디오의 도입과 함께 연결되기 시작했습니다. 그때부터 규제 기관과 자동차 제조업체가 진단과 서비스를 용이하게 하고(예: OBD-II 포트), 안전을 향상하고(예: TPMS), 연비 목표를 충족하기 위해 전자 장치에 의존함에 따라 외부 물리적 연결과 무선 연결의 수가 증가하기 시작했습니다. 이후 연결을 강조하는 추세가 이어지면서 자동차 리모컨 키, 차량 통신 기술 시스템, 고급 인포테인먼트 기능(예: 블루투스, Wi-Fi, 스마트폰 프로젝션) 같은 운전자 편의 기능이 도입되었습니다. 지금은 통합된 센서 및 연결(예: GPS)이 안전과 반자율 주행 시스템을 지원합니다.

차량 연결이 증가함에 따라 차량이 잠재적으로 공격에 노출되는 영역도 늘어납니다. 차량 연결로 인해 소비자 가전제품과 비슷한 일련의 사이버 보안 문제가 발생합니다. 그러나 재부팅, 일일 패치 업데이트, 설명할 수 없는 동작은 소비자 가전제품의 표준으로서 차량과 같이 안전이 중요한 시스템이 포함된 제품에는 일관적이지 않습니다.

제조업체는 현장에서 제품의 지속적인 보안 및 안전성 상태를 보장하기 위해 사전에 조치를 취해야 합니다. 즉, 제조업체는 제품의 알려진 보안 취약점을 인지하고 해결을 위해 위험 기반 접근 방식을 취해야 합니다.

장기적인 보안 보장

연결된 차량에는 OS, 라이브러리, 유틸리티 등의 여러 소프트웨어 구성요소가 포함된 전자 제어 장치(ECU)가 하나 이상 있는 경우가 많습니다. 제조업체는 이러한 구성요소를 추적하고 다음과 같은 사전 분석을 통해 게시되어 있는 알려진 취약점을 파악해야 합니다.

일반적인 취약점 및 노출(CVE) 데이터베이스와 비교하여 제품을 정기적으로 평가합니다.
제품 관련 보안 결함을 확인하기 위해 정보를 수집합니다.
보안을 테스트합니다.
Android 보안 게시판을 적극적으로 분석합니다.

OS 및 보안 패치 업데이트(Android를 실행하는 IVI)의 예:

그림 1. 차량 수명 기간의 주요 OS 및 보안 업데이트 출시 샘플

#	단계	활동
①	개발 브랜치	제조업체가 Android 버전(Android X)을 선택합니다. 이 예에서 'Android X'는 최초 양산 시작(SOP) 2년 전에 차량에 탑재될 제품의 기반이 됩니다.
②	최초 출시	Android X가 제품에 최초로 탑재되는 OS 버전이 되기 몇 개월 전에 Android 보안 게시판(ASB) 및 제조업체가 신뢰하는 다른 소스에서 보안 업데이트를 가져옵니다. y2는 Android X의 버전에 관한 두 번째 보안 게시판이며 제조업체가 Android X에 적용(백포팅)합니다. 이 업데이트가 제품에 탑재되며, Android X.y2를 0차 연도로 하여 프로덕션 시계가 움직이기 시작합니다. 이 예에서 제조업체는 최신 Android X+1 연간 출시를 탑재하지 않기로 결정했습니다. 최신 버전 탑재를 찬성하는 이유로는 새로운 기능 추가, 새로운 보안 취약점 해결, 최신 Android 버전이 필요한 Google 또는 서드 파티 서비스 탑재 등이 있습니다. 최신 버전 탑재를 반대하는 이유는 차량 개발 및 출시 프로세스 자체에 변경사항을 통합, 테스트, 검증(모든 규제 및 인증 요구사항 준수 포함)하는 데 필요한 시간이 없기 때문입니다.
③	전체 OS 업데이트	SOP 이후에 제조업체는 Android X+2 OS 업데이트를 출시합니다. 이 업데이트는 초기 제품에 사용된 버전(Android X0) 이후의 2개 Android 버전입니다. ASB 보안 업데이트는 탑재일 기준 API 수준에 사용할 수 있으므로, 업데이트는 SOP로부터 약 1.25년 후에 X+2.y0으로 출시됩니다. 이 OS 업데이트는 출시된 제품과 호환되거나 호환되지 않을 수 있습니다. 호환되는 경우 배포된 차량을 업데이트할 계획을 세울 수 있습니다. 다른 비즈니스 계약이 수립되어 있지 않은 경우 전체 OS 업데이트를 실행할 결정은 전적으로 제조업체의 재량에 따릅니다.
④	보안 업데이트	차량 생산 수명의 2년째에 제조업체는 Android X+2 OS를 패치합니다. 이 결정은 제조업체의 위험 평가를 기반으로 합니다. 이 업데이트 기반으로 제조업체는 X+2 버전의 세 번째 ASB 보안 업데이트를 선택합니다. 이 보안 업데이트를 받은 제품은 이제 (X+2.y3) OS + Android 보안 패치 수준이 됩니다. 제조업체는 개별 ASB에서 개별 보안 패치를 선택할 수 있지만 게시판(예: 2017-02-05)과 관련된 Android 보안 패치 수준(SPL)을 사용하려면 모든 필수 문제를 수정해야 합니다. 지원되는 제품의 백포트 및 보안 출시를 실행하는 것은 제조업체의 책임입니다.
⑤	전체 OS 업데이트	3단계(전체 OS 업데이트)를 반복하는 두 번째 전체 OS 업데이트를 통해 차량 생산 수명의 3년째에 제품을 Android X+4로 업데이트합니다. 이제 제조업체는 최신 Android 버전의 최신 하드웨어 요구사항을 제품의 하드웨어 및 업데이트된 Android OS에서 사용자가 얻을 이점을 비교하여 균형을 잡습니다. 제조업체가 보안 업데이트 없이 업데이트를 출시하므로 이제 제품은 (X+4.y0) OS + Android 보안 패치 수준입니다. 이 예에서는 하드웨어 제한으로 인해 X+4가 이 제품용으로 제공되는 최종 Android 주 버전이지만, 예상 수명이 6년 이상인 차량에 여전히 보안 지원이 필요합니다.
⑥	보안 업데이트	4단계(보안 업데이트)의 반복입니다. 제조업체는 최신 버전 Android (X+6)에서 ASB 보안 업데이트를 받아 일부 또는 모든 업데이트를 Android X+4로 백포팅할 임무를 가집니다. 업데이트를 병합, 통합, 실행(또는 서드 파티와 계약)하는 것은 제조업체의 책임입니다. 또한 제조업체는 더 이상 지원되지 않는 Android 버전의 보안 문제를 ASB에서 다루지 않는다는 점을 알아야 합니다.
⑦	보안 업데이트	Android X를 지정한 후 10년이 되었고 차량 생산 수명 주기 8년째이며 5단계(전체 OS 업데이트)의 최종 OS 업데이트 이후 Android 버전 4개가 만들어졌으며, 보안 패치를 선별하고 백포팅하는 책임은 API 수준 공개 버전으로부터 3년 지난 버전의 경우 제조업체가 전적으로 집니다.

보안 권장사항

보안 침해를 더욱 어렵게 만들기 위해 Google은 보안 구현에 설명된 대로 보안 및 소프트웨어 엔지니어링에 일반적으로 적용되는 권장사항을 준수할 것을 권장하고 채택합니다.

보안 가이드라인

다음을 포함한 보안 방법이 권장됩니다.

최신 버전의 외부 라이브러리와 오픈소스 구성요소를 사용합니다.
OS 출시 버전에 방해가 되는 디버그 기능을 포함하지 않습니다.
사용하지 않는 기능을 삭제하여 불필요한 공격 표면을 줄입니다.
최소 권한의 원칙 및 다른 Android 앱 개발 권장사항을 따릅니다.

소프트웨어 개발 가이드라인

시스템 수명 주기 동안 안전한 소프트웨어 개발을 위해 권장되는 방법은 다음과 같습니다.

위협 모델링을 실행하여 자산, 위협, 잠재적 완화 조치를 식별하고 그 순위를 지정합니다.
아키텍처/설계를 검토하여 안전하고 견고한 설계를 보장합니다.
정기적인 코드 검토를 실행하여 최대한 빨리 안티패턴과 버그를 식별합니다.
다음을 포함하여 고도의 코드 적용 범위 단위 테스트를 설계, 구현 및 실행합니다.
- 기능 테스트(네거티브 테스트 사례 포함)
- 정기적인 회귀 테스트(수정된 버그가 다시 발생하지 않도록 확인)
- 퍼징 테스트(단위 테스트 모음의 일부)
scan-build, 린트와 같은 정적 소스 코드 분석 도구를 사용하여 잠재적 문제를 식별합니다.
AddressSanitizer, UndefinedBehaviorSanitizer, FORTIFY_SOURCE(네이티브 구성요소의 경우)와 같은 동적 소스 코드 분석 도구를 사용하여 시스템 개발 중에 잠재적인 문제를 식별하고 완화할 수 있습니다.
소프트웨어 소스 코드와 출시 구성/버전에 관한 관리 전략을 갖춥니다.
소프트웨어 패치 생성 및 배포에 관한 패치 관리 전략을 갖춥니다.

보안 백포트 정책

Google은 현재 API 수준 공개 버전 이후 3년 동안 발견 및 신고된 보안 취약점의 보안 백포트를 적극적으로 지원합니다. 적극적인 지원은 다음으로 구성됩니다.

취약점 보고서를 받고 조사합니다.
보안 업데이트를 만들어 테스트하고 출시합니다.
보안 업데이트 및 보안 게시판 세부정보를 반복적으로 제공합니다.
수립된 가이드라인에 따라 심각도 평가를 실행합니다.

API 수준 공개 출시일로부터 3년이 지나면 다음 가이드라인을 준수하는 것이 좋습니다.

서드 파티(예: SoC 공급업체 또는 커널 제공업체)를 사용하여 API 출시로부터 3년이 지난 OS 보안 업데이트의 백포트 지원을 받습니다.
서드 파티를 사용하여 공개적으로 제공되는 ASB를 사용한 코드 검토를 실행합니다. ASB는 현재 지원되는 버전의 취약점을 식별하며, 제조업체는 제공된 정보를 사용하여 새로 출시된 업데이트와 이전 버전을 비교할 수 있습니다. 이 데이터를 사용하여 영향 분석을 실행하고 API 출시로부터 3년 지난 OS 버전용으로 유사한 패치를 생성할 수 있습니다.
필요한 경우 Android 오픈소스 프로젝트(AOSP)에 보안 업데이트를 업로드합니다.
제조업체는 공급업체별 코드(예: 독점적인 기기별 코드)의 보안 업데이트 처리를 조정해야 합니다.
제조업체는 NDA Android 보안 게시판 파트너 미리보기 알림 그룹에 가입해야 합니다(개발자 NDA와 같은 법적 계약에 서명해야 함). 다음을 포함한 항목을 게시판에 포함해야 합니다.
- 공지사항
- 패치 수준별 문제 요약(CVE 및 심각도 포함)
- 취약점 세부정보(필요한 경우)

추가 자료

안전한 코딩 및 소프트웨어 개발 방법에 관한 안내는 다음을 참고하세요.

제품 관련 권장 방법

Google에서는 다음과 같은 방법을 따를 것을 권장합니다.

일반 출시 가이드라인

연결된 제품은 일반적으로 최신 OS 버전을 포함하여 출시하는 것이 좋습니다. 제조업체는 제품을 출시하기 전에 최신 OS 버전을 사용해야 합니다. 테스트 및 검증 전에 안정성을 보장하기 위해 버전을 잠그는 것이 필요하지만, 제조업체는 알려진 보안 취약점과 향상된 보안 보호가 비교적 적은 최신 OS 버전과 이전 OS 버전에서 얻는 제품 안정성 간에 균형을 잡아야 합니다.

권장되는 가이드라인은 다음과 같습니다.

차량 개발 프로세스 자체에서 개발 리드 타임이 길기 때문에 제조업체는 OS 버전 n-2 이상을 포함해 출시해야 할 수도 있습니다.
출시된 각 Android OS 버전에 관해 무선 업데이트(OTA) 캠페인을 통해 Android 호환성 준수를 유지합니다.
고객 중심적인 빠른 업데이트가 가능하도록 Android 펌웨어 무선 업데이트(FOTA)와 호환 가능하도록 제품을 구현합니다. FOTA는 코드 서명, 제품과 IT 백오피스 간 TLS 연결 등과 같은 보안 권장사항을 준수하여 실행해야 합니다.
개별적으로 식별한 Android 보안 취약점을 Android 보안팀에 제출합니다.

참고: Google은 Android 보안 게시판에서 기기 유형 또는 업계별로 알림을 게시할 것을 고려했습니다. 하지만 Google은 특정 기기(차량, TV, 웨어러블, 휴대전화 등)의 커널이나 드라이버, 칩셋을 모르기 때문에 특정 보안 문제에 기기 유형으로 라벨을 지정할 수 있는 확정적인 방법이 없습니다.

제품 주기 가이드라인

제조업체는 제품 주기 개선 도중에 사용 중인 버전의 최신 OS 버전 또는 보안 업데이트를 사용하기 위해 노력해야 합니다. 반복되는 주기적인 제품 업데이트 도중에 업데이트를 실행하거나 핫픽스를 통해 품질 또는 다른 문제를 해결할 수 있습니다. 권장사항은 다음과 같습니다.

드라이버, 커널, 프로토콜을 업데이트할 계획을 세웁니다.
배포된 차량에 업데이트를 제공하기 위해 업계에 적절한 방법을 활용합니다.

호환성 정의 문서(CDD)

호환성 정의 문서(CDD)에서는 Android 호환 기기로 간주되기 위한 요구사항을 설명합니다. CDD는 공개되어 누구나 사용할 수 있습니다. Android 1.6부터 최신 버전까지 해당하는 CDD를 source.android.com에서 다운로드할 수 있습니다.

제품을 위해 이러한 요구사항을 충족하려면 다음 기본 단계를 따라야 합니다.

파트너가 Google과 Android 호환성 약정(ACC)에 서명합니다. 그런 다음, 기술 솔루션 컨설턴트(TSC)가 가이드로 할당됩니다.
파트너가 제품의 Android OS 버전을 대상으로 CDD 검토를 완료합니다.
Android 호환성이 허용될 때까지 파트너가 실행하고 CTS 결과를 제출(아래 설명 참고)합니다.

호환성 테스트 모음(CTS)

호환성 테스트 모음(CTS) 테스트 도구는 제품이 Android와 호환하도록 구현되어 있으며 최신 보안 패치가 포함되어 있는지 확인합니다. CTS는 오픈소스이며 공개되어 있어 모두가 사용할 수 있습니다. Android 1.6부터 최신 버전까지 해당하는 DCC를 source.android.com에서 다운로드할 수 있습니다.

공개 출시되는 각 Android 소프트웨어 빌드(공장 설치 이미지 및 현장 업데이트 이미지)는 CTS 결과를 통해 Android 호환성을 증명해야 합니다. 예를 들어 Android 7.1을 실행하는 기기의 경우 출시 인텐트 빌드 이미지를 생성 및 테스트할 때 해당하는 최신 버전 CDD 7.1 및 CTS 7.1을 참조해야 합니다. 제조업체는 조기에 자주 CTS를 사용하여 문제를 식별하고 해결하는 것이 좋습니다.

참고: Google 모바일 서비스(GMS)와 같은 다른 계약에 서명하는 파트너는 다른 요구사항을 충족해야 할 수도 있습니다.

CTS 워크플로

CTS 워크플로에는 테스트 환경 설정, 테스트 실행, 결과 해석, CTS 소스 코드 이해가 포함됩니다. 다음 가이드라인을 참고하여 CTS 사용자(예: 개발자, 제조업체)가 CTS를 효과적이고 효율적으로 사용하도록 도울 수 있습니다.

테스트를 자주 실행. CTS는 빌드 시스템에 통합되는 자동화된 도구로 설계되었습니다. CTS를 자주 실행하면 소프트웨어 성능이 저하되거나 회귀가 발생하는 경우 조기에 결함을 신속하게 찾을 수 있습니다.
CTS 소스 코드 다운로드 및 검토. 전체 CTS 소스 코드는 누구나 다운로드하여 사용할 수 있는 오픈소스 소프트웨어입니다. 다운로드된 소스 코드는 완전히 빌드할 수 있고 실행 가능합니다. 기기에서 테스트가 실패하는 경우 소스 코드의 관련 섹션을 검토하면 이유를 파악할 수 있습니다.
최신 CTS 다운로드. 새로운 Android 버전은 버그 수정, 개선사항, 새로운 테스트로 CTS를 업데이트할 수 있습니다. CTS 다운로드를 자주 확인하고 필요에 따라 CTS 프로그램을 업데이트하세요. CTS가 지속적으로 업데이트되는 동안 제품은 어느 시점에 정지되어야 하므로, 제조업체와 Google은 제품 출시를 위해 통과해야 할 CTS 버전에 관해 동의해야 합니다.

CTS 통과

Android 호환 제품의 경우 Google은 기기의 CTS 및 CTS 인증 도구에서 허용 가능한 테스트 결과를 보고하는지 확인합니다. 원칙적으로는 모든 테스트를 통과해야 합니다. 그러나 기기가 Android 호환성 요구사항을 준수하지 않은 것 이외의 이유로 실패한 테스트는 Google에서 검토합니다. 이 프로세스에서 다음을 처리합니다.

제조업체가 주장을 입증하기 위해 제안된 CTS 패치, 패치 검증, 근거를 Google에게 제공합니다.
Google은 제출된 자료를 검토하여 승인하는 경우 기기가 CTS의 다음 버전에서 통과하도록 관련 CTS 테스트를 업데이트합니다.

보안 패치를 적용한 후 CTS 테스트가 예기치 않게 실패하면 제조업체는 호환성을 손상시키지 않도록 패치를 수정하거나 테스트에 문제가 있음을 표시하고 해결 방법을 제공해야 합니다(위의 설명 참고).

CTS는 테스트 수정사항을 검토할 수 있도록 공개되어 있습니다. 예를 들어 Android 4.4는 지속적으로 수정사항을 수락합니다(https://android-review.googlesource.com/#/c/273371/ 참고).

자주 묻는 질문(FAQ)

Q: 특정 Android 구현에 보안 업데이트를 적용할 책임은 누구에게 있나요?

A: 기기를 직접 제공하는 제조업체가 담당합니다. 이 주체는 Google이 아닙니다. Google은 특정 기기(예: 차량)에 관한 것이 아닌 보안 업데이트를 AOSP에 게시합니다.

Q: Google에서는 Android의 보안 문제를 어떻게 처리하나요?

A: Google은 지속적으로 문제를 조사하고 잠재적 수정사항을 개발합니다. Google은 이 수정사항을 지원되는 모든 API 수준에 정기적인 보안 업데이트 프로세스의 일부로 제공합니다. 2015년 8월 이후 Google은 정기적인 간격을 유지하며 게시판 및 source.android.com 업데이트 링크를 게시해 왔습니다. 또한 Google은 주요 OS 버전의 일부로 보안 업데이트를 게시합니다. 보안 백포트 정책도 참고하세요.

Q: 제조업체가 ASB의 모든 AOSP 패치를 통합했지만 동일한 게시판에서 언급된 BSP 공급업체의 패치를 통합하지 않았다면 이 경우에도 보안 수준을 높이는(예: 해당하는 패치를 플랫폼/빌드에 적용) 것이 가능한가요?

A: Android 보안 패치 수준(SPL)을 선언하려면 제조업체는 Android 보안 게시판(이전 게시판 포함)에 게시되어 있고 특정 Android SPL에 매핑되어 있는 모든 필수 문제를 해결해야 합니다. 예를 들어 2017년 3월 보안 게시판(2017-03-01 SPL)을 사용하는 제조업체는 2017년 3월 게시판의 SPL 및 모든 이전 Android 보안 게시판의 기기별 업데이트(2017-02-05 SPL 관련 기기별 업데이트 포함)를 비롯한 모든 업데이트에 관해 수록된 필수 문제를 모두 해결했습니다.

Q: 제조업체가 BSP 공급업체가 제공한 보안 업데이트에 동의하지 않는 경우 또는 ASB에서 의무화하는 보안 업데이트를 공급업체가 제공하지 않는 경우 어떻게 되나요?

A: ASB는 보안 취약점(CVE 목록으로 나열됨)을 설명하며 일치하는 보안 테스트를 제공하는 경우가 많습니다. 목표는 나열된 취약점이 더 이상 기기에서 재현되지 않고 기기가 관련 보안 테스트를 통과할 수 있게 하는 것입니다. 따라서 Google이나 서드 파티 공급업체에서 제공되는 보안 업데이트를 받는 것이 아니라 기기가 ASB의 CVE 목록에 취약하지 않다는 것을 제조업체가 증명하는 것이 핵심입니다. 제조업체는 제공된 보안 업데이트를 사용하거나 기기에 더 적합한 변경사항이 있는 경우 이 변경사항을 대신 사용하면 됩니다.

예를 들어 Google이 구성요소의 완전한 기능을 유지하면서 구성요소가 CDD를 준수하도록 하는 코드 변경을 통해 AOSP 보안 취약점을 해결하는 사례를 생각해 보세요. 이 구성요소가 기기에 필요하지 않거나 CDD(또는 관련 인증 테스트)에 의해 의무화되지 않는다고 판단하는 경우 제조업체는 구성요소를 삭제하여 향후 서비스 요구와 공격 표면을 줄일 수 있습니다. 제조업체는 제공된 보안 업데이트를 사용하지 않았지만 기기가 보안 게시판에 수록된 CVE에 취약하지 않도록 했습니다. 그러나 권장 보안 업데이트에서 벗어남으로써 제조업체는 문제를 잘못 해결하여 새로운 보안 취약점을 발생시키거나 최종 빌드의 기능을 축소시킬 위험이 있습니다.

Google은 ASB의 모든 문제에 관한 수정사항을 확보하기 위해 모든 SoC 파트너와 협력하고 있지만, 제조업체는 SoC 공급업체와 기기 수명 주기에 해당하는 서비스 계약을 체결하는 것이 좋습니다. SoC가 예상보다 일찍 칩셋 제공을 중지할 수도 있으므로 기기 칩셋을 선택하기 전에 계약을 설정하는 것은 기기 출시 프로세스에서 중요한 부분입니다.

마지막으로, ASB에 수록된 문제에 관한 수정사항을 직접 받거나 독립적으로 만들 수 없는 경우 제조업체는 이전 Android SPL을 유지하고 새로 사용할 수 있는 수정사항을 빌드에 추가할 수 있습니다. 하지만 이 방법을 사용하면 결국 빌드 인증 문제가 발생할 수 있습니다(Android는 인증된 기기에서 최신 보안 패치 수준을 사용할 수 있도록 함). 제조업체는 이 문제를 방지하기 위해 SoC와 사전에 협력하는 것이 좋습니다.

Q: ASB 항목이 제품에 적용되지 않는다고 판단하는 경우에도 제조업체는 다른 Google 요구사항을 충족하거나 CTS를 통과하기 위해 이 항목을 적용하거나 패치해야 하나요?

A: Android 보안 패치 수준(SPL)을 선언하기 위해 패치를 반드시 받아야 할 필요는 없지만 제조업체는 빌드가 문제에 취약하지 않다는 것을 증명해야 합니다.

한 가지 예로, 패치 대상인 구성요소가 제조업체의 시스템에 존재하지 않는 경우 또는 제조업체의 시스템에서 구성요소를 삭제하여 문제를 해결하는 경우가 있습니다. 이 경우 제조업체가 패치를 받지 않고도 시스템이 규정을 준수할 수도 있습니다.

이 방법은 보안 테스트의 실패를 야기하는 적용 가능한 다른 패치를 가져오지 않고 중요한 패치만 수정하고자 하는 제조업체의 방법과는 완전히 다릅니다. 이 경우에는 SPL이 충족되지 않은 것으로 간주됩니다.