보안 강화로 앱 보호하기

좋은 아침입니다. 저는 Apple의 보안, 엔지니어링 및 아키텍처 팀 소속 마크 미첼입니다. 제 동료 데빈과 함께 이 자리에 섰습니다. 오늘은 메모리 안전성 취약점으로부터 앱을 보호할 수 있는

프레임워크에 대해 설명해 드리겠습니다. 데빈과 제가 오늘 소개할 전략들을 신중하게 계층화하고 조합한 결과, iPhone은 시중에서 가장 안전한 소비자용 기기로 명성을 얻게 되었습니다.

오늘 세션 전반에 걸쳐 이러한 기능들이 무엇인지, 어떤 용도로 사용되는지 설명하고, Apple이 앱과 OS, 그리고 고객을 보호하기 위해 이를 어떻게 활용하는지 예시를 들어 보여드리겠습니다.

이제 Xcode를 통해 여러분도 애플이 앱 사용자를 보호하기 위해 사용하는 것과 동일한 기술을 활용할 수 있습니다.

앱은 우리 삶의 여러 부분에 깊이 관여하고 있습니다. 앱은 모든 사람이 개인 정보, 위치, 브라우징 기록, 사진, 메시지, 금융 정보 등을 믿고 맡기는 필수적인 도구입니다. 동시에, 이러한 앱과 사용자는 인터넷에 연결되어 있으므로, 앱 내의 보안 취약점은 사용자를 공격에 노출시킬 수 있습니다. 이러한 공격으로 인한 피해는 사기 및 신원 도용에서 협박에 이르기까지 다양하며, 드문 경우지만 현실 세계에서의 위협으로까지 이어질 수 있습니다.

사람들은 자신의 데이터가 비공개로 안전하게 보호되기를 기대하며, 그 약속이 지켜지지 않는다면 이는 신뢰의 위반입니다. 보안은 개인정보 보호를 가능하게 하는 기술적 토대입니다.

먼저 메모리 안전성이 무엇을 의미하는지, 그리고 이것이 초래할 수 있는 다양한 유형의 취약점에 대해 개괄적으로 설명하겠습니다. 다음으로, 앱을 보호하는 데 활용할 수 있는 몇 가지 보안 엔지니어링 전략에 대한 개요를 제시하고, 저희가 자사 앱에서 이를 성공적으로 적용한 방법을 설명하겠습니다. 마지막으로, 데빈이 강화된 보안 기능을 활용하여 Xcode에서 이러한 전략을 실제로 적용하는 방법을 보여드릴 것입니다.

그렇다면 메모리 안전성이란 무엇을 의미할까요? 메모리 안전성 결함은 소프트웨어에서 가장 흔한 취약점 유형 중 하나로, 공격자가 메모리 손상을 이용해 프로그램의 동작을 변경하거나 교란하는 경우를 말합니다.

애플의 보안 엔지니어들은 프로그램 내 의도된 동작과 의도하지 않은 동작이라는 관점에서 메모리 안전성을 고려합니다.

일반적인 사용 환경에서 프로그램은 개발자가 의도한 대로 작동하며, 타당한 작업만 수행합니다. 따라서 프로그램의 흐름을 일종의 미로와 비슷하게 생각할 수 있습니다. 미로를 통과하는 경로가 바로 코드입니다. 개발자는 특정 작업을 수행하기 위해 특정 경로를 의도적으로 사용하며, 다른 경로들은 사용되지 않거나 도달할 수 없는 코드 경로를 나타냅니다.

도달할 수 없는 경로는 카메라를 켜거나 이메일을 보내는 등의 기능을 수행하는, 여러분이 사용하지 않는 프레임워크 내에 있을 수 있습니다. 공격자는 이러한 메모리 안전성 취약점을 악용하여 프로그램을 의도하지 않은 상태로 유도함으로써, 개발자가 실제로 의도한 것과는 전혀 다른 작업을 수행할 수 있습니다.

이 예시에서, 의도된 경로상의 어느 곳에서든 메모리 안전성 취약점이 발생하면 새로운 경로를 만들거나 따라가게 되어, 의도하지 않은 방식으로 미로를 해결하거나 코드를 실행하게 됩니다. 이는 해당 코드를 호출하여 앱이 카메라를 켜거나 이메일을 보내도록 강제하는 것을 의미할 수 있습니다.

메모리 안전성은 보안의 기초이며, 이것이 없으면 상위 수준의 보안 속성을 보장할 수 없습니다. 예를 들어, 비밀번호 해싱 방식이 아무리 강력하더라도 소용이 없습니다. 공격자가 메모리 안전성 취약점을 악용해 시스템에 접근할 수만 있다면 말입니다.

다음은 간단한 로그인 함수의 예시입니다. 사용자가 텍스트 필드에 입력한 비밀번호의 복사본을 받아, 디버그 빌드인지 확인한 후 인증 과정을 건너뜁니다. 아마도 개발자는 자신의 책상에서 더 빠르게 테스트할 수 있도록, 비밀번호 복사본을 하드코딩된 비밀값과 비교하는 함수를 호출하고, 로그인 결과를 반환하는 것일 수 있습니다. 특히 눈썰미가 좋은 분들은 그 커다란 빨간색 X 표시를 눈치채셨을지도 모릅니다. 이 코드에는 분명히 메모리 안전성 취약점이 있으므로, 절대 여기서 따라 해서는 안 됩니다. 개발자는 비밀번호 사본을 저장하기 위해 스택에 32자 분량의 공간을 할당하고 있지만, 복사 API는 사용 가능한 공간이 얼마나 되는지 알지 못합니다. 따라서 텍스트 필드에 입력된 모든 문자를 주어진 버퍼에 복사하게 되고, 그 결과 스택 버퍼 오버플로가 발생합니다.

메모리 내부에서 대략 다음과 같은 일이 벌어집니다. 로컬 비밀번호 저장 공간은 디버그 로그인 플래그를 저장하는 메모리 바로 앞에 위치해 있습니다.

비밀번호가 예를 들어 18자라면 당연히 안전하게 들어갑니다.

하지만 공격자가 32자 이상의 데이터를 전송한다면 어떻게 될까요?

이 경우, 이 프로그램이 메모리 안전성이 보장되지 않는 언어로 작성되었기 때문에 인접한 메모리를 덮어쓰기 시작합니다. 그리고 바로 그 위치가 디버그 로그인 플래그를 저장하는

메모리 영역입니다. 그 결과, 개발자가 의도했거나 이 함수에 전달한 값과 상관없이, 프로그램이 이 if 문에 도달했을 때 해당 값이 공격자에 의해 덮어쓰이거나 변경되었다면, 공격자는 인증 과정을 건너뛰고 어쨌든 true를 반환하도록 강제할 수 있습니다.

하지만 사실, 그 코드에는 훨씬 더 심각한 문제가 있습니다. 디버그 플래그를 덮어쓰면 공격자가 인증 없이 로그인할 수 있지만, 메모리 상에서 디버그 로그인 플래그 바로 뒤에는 프로그램이 비교 작업을 수행하기 위해 호출할 함수 포인터의 주소가 있습니다.

공격자가 더 긴 비밀번호를 입력하면, 로컬 비밀번호 버퍼가 오버플로우되어 디버그 로그인 플래그 영역을 넘어서 그 함수 포인터를 원하는 대로 변경할 수 있습니다. 이는 프로그램이 비교 함수를 호출하려고 할 때, 실제로는 비교 작업을 수행하지 않게 된다는 것을 의미합니다. 실제로는 공격자가 선택한 임의의 함수를 호출하게 되는 것입니다. 이제 공격자는 이 프로세스를 완전히 제어하여 다른 코드 경로로 이동하고, 잠재적으로 사용자 데이터를 탈취할 수 있게 됩니다.

따라서 이 예시는 버퍼 오버플로우로, 메모리 안전성의 속성 중 하나를 위반하는 사례입니다. 하지만 실제로는 다섯 가지 안전성 축이 존재합니다. 안전성(Safety)은 메모리에 대한 모든 접근이 메모리 할당 범위 내에서 이루어지도록 보장합니다.

수명 안전성(Lifetime safety)은 메모리가 유효한 기간 동안에만 사용되고 다른 용도로 재사용되지 않도록 보장합니다. 유형 안전성은 프로그래머가 의도한 것과 다른 유형을 통해 실수로 메모리에 접근하는 것을 방지합니다.

보장된 초기화는 메모리가 사용되기 전에 초기화되도록 보장합니다.

마지막으로, 스레드 안전성은 서로 다른 스레드가 서로의 메모리를 덮어쓰지 못하도록 보장합니다.

공격은 대개 다음과 같은 양상을 띱니다. 일반적으로 특정 앱을 표적으로 삼는 공격자는 해당 앱의 데이터에 접근하거나 앱을 침해하여 데이터를 탈취하는 것뿐만 아니라, 이를 발판 삼아 일련의 버그 체인을 통해 다른 시스템 구성 요소를 공격하고, 심지어 플랫폼 보안 모델을 훼손하기 위해 커널 권한까지 상승시키려 합니다. 이는 시스템 전반의 파일에 접근할 뿐만 아니라 위치 정보, 사진, 연락처, 마이크와 같은 다른 자산에도 접근하려는 목적이 있기 때문입니다.

따라서 앱은 종종 더 광범위한 공격의 관문 역할을 합니다.

동시에, 현대 애플리케이션은 매우 다양한 기능을 제공하기 때문에, 많은 앱이 정상적인 사용 과정에서 이러한 자산 대부분에 대한 접근 권한을 부여받고 있습니다. OS의 보안 태세가 지속적으로 발전함에 따라, 향후 공격자들은 단순히 앱을 악용하여 해당 환경에서 접근 권한이 있는 데이터를 수집하는 데 만족하고, 플랫폼의 나머지 부분으로 침투할 필요가 없을 것이라고 예상하는 것이 합리적입니다. 바로 그 때문에 지금 우리 모두가 함께 보안 강화를 위해 힘을 합쳐 나아가는 것이 정말 중요합니다.

이제 저는 메시지, 사파리, 메일과 같은 애플리케이션과 서비스를 메모리 안전성 취약점으로부터 보호하기 위해 Apple에서 사용하고 있는 전략에 대해 설명드리겠습니다.

충분히 복잡한 코드베이스라면 어디에서나 항상 취약점이 존재할 수밖에 없다는 점은 인정되는 사실입니다. 상황이 너무 심각해졌습니다.

그래서 Apple에서는 서로 겹치고 상호 보완하는 다층적인 보안 엔지니어링 체계를 활용하고 있습니다. 오늘 제가 소개할 여러 기술에 대해서는 추후 더 깊이 있게 다룰 예정이지만, 오늘은 기본 개념과 Apple이 이를 적용하는 방식, 그리고 여러분이 해당 기술의 효과성을 평가하고 애플리케이션에 적용하는 데 필요한 노력을 파악할 수 있는 몇 가지 방법을 소개하고자 합니다. 총 다섯 가지 전략에 대해 이야기해 보겠습니다. Swift와 같은 메모리 안전성을 보장하는 언어를 사용하여 코드에서 메모리 안전성 취약점을 근본적으로 방지하는 방법에 대해 다룰 것입니다.

공격 표면을 줄여 취약점에 접근할 수 없게 만드는 방법.

완화 조치를 통해 취약점이 악용될 수 없도록 만드는 방법.

악용이 발생하더라도 피해를 최소화하는 방법. 그리고 마지막으로, 코드에서 취약점을 찾아 제거하는 몇 가지 기법입니다.

메모리 안전성 취약점으로부터 방어하는 가장 포괄적인 접근 방식은 애초에 이러한 취약점이 발생할 가능성을 거의 없애주는 언어를 사용하는 것입니다.

애플은 Swift가 안전하면서도 성능이 뛰어난 언어가 되도록 막대한 투자를 해왔으며, Swift는 기본적으로 메모리 안전성을 제공합니다. Swift는 여러분의 많은 애플리케이션뿐만 아니라 운영 체제의 일부에도 사용되고 있으며, 여기에는 WebKit과 같이 보안에 매우 중요한 코드베이스가 점점 더 많이 포함되고 있습니다. 복잡한 파싱은 물론, Secure Enclave와 같은 임베디드 환경에서 펌웨어를 처리하는 과정까지 포함됩니다. 물론, 많은 앱에는 C 계열 언어로 작성된 방대한 기존 코드베이스가 있습니다. 이러한 코드베이스는 메모리 안전성이 보장되지 않습니다. 강화된 보안 기능은 C 및 C++ 표준 라이브러리의 보안을 강화하기 위한 F-밴드 안전성 및 관련 어노테이션과 같은 도구를 제공하여, 밴드 안전성 오류의 위험을 줄이는 데 도움을 줍니다. 하지만 이를 메모리 안전성을 향한 과정의 디딤돌로 생각하십시오. 이 도구들은 나머지 네 가지 축을 다루지 않기 때문에 최종 목표는 아닙니다.

이 다섯 가지 축을 기준으로 C 기반 언어와 Swift를 비교해 보면, C 기반 언어는 이러한 보호 기능을 전혀 제공하지 않는 반면, Swift는 경계 검사 배열 및 기타 Swift 표준 라이브러리 추상화를 통해 경계 안전성을 제공합니다. 또한 자동 참조 카운팅과 소유권을 통해 수명 안전성을 보장합니다. 실행 시점에 형 변환을 검사하도록 요구함으로써 형 안전성을 보장합니다.

Swift는 변수를 사용하기 전에 초기화하도록 요구함으로써 초기화 안전성을 보장하며, Swift 동시성 기능을 통해 데이터 경합을 방지함으로써 스레드 안전성을 제공합니다.

지금까지 메모리 안전성 취약점을 근본적으로 차단하는 방법에 대해 간략히 살펴보았습니다. 더 자세한 내용은 나중에 진행될 ‘Swift에서 보안에 민감한 코드 작성하기’ 세션을 확인해 주시기 바랍니다.

Apple이 보안이 중요한 코드베이스에서 적극적으로 활용하는 두 번째 전략은 ‘공격 표면 축소(attack surface reduction)’로 알려져 있습니다. 여기서의 이론은 개발자와 보안 엔지니어로서, 자신의 코드와 의존하는 프레임워크에 존재하는 모든 취약점이 어디에 있을지 알 수 없다는 점입니다. 하지만 공격자가 잠재적으로 접근할 수 있는 코드의 양을, 기능 구현에 필요한 최소한의 범위만으로 제한할 수는 있습니다. 이를 통해 앱에서 실제로 사용되는 코드에 취약점이 존재할 가능성을 크게 줄일 수 있습니다.

Apple은 공격자가 활동할 수 있는 여지를 줄이기 위해 시스템 전반에 걸쳐 이 기법을 사용하며, 이는 어떤 복잡한 문서 형식을 파싱할 수 있는지 제한하는 기술부터 특정 조건에 기반한 기능 제한에 이르기까지 다양합니다. 심지어 락다운 모드에서는 신뢰할 수 있는 상대방에 한해 전체 기능을 비활성화하기도 합니다. 형식 제한의 예로, 앱이 오직 JPEG 이미지만 송수신할 것임을 알고 있다면, 수신 측 코드가 다른 형식의 이미지를 처리하도록 허용하는 것은 공격자가 불필요하게 수백만 줄에 달하는 파싱 코드에서 취약점을 찾도록 노출시키는 것과 같습니다. 따라서 이 경우, 즉각적인 효과를 거두고 보안을 강화하는 최선의 방법은 올바른 형식의 JPEG인지 확인하거나, 해당 프로세스에서 해당 형식만 파싱하도록 Core Graphics 기능을 구성하고, 예상과 일치하지 않는 트래픽은 그냥 버리는 것입니다.

앱이 엄밀히 말해 꼭 필요하지 않은 공격 표면을 의도치 않게 노출할 수 있는 또 다른 경우는, 인앱 브라우징과 같은 용도로 직접 사용하는 웹 뷰를 통해 웹 콘텐츠를 렌더링할 때나, 광고 SDK와 같은 타사 프레임워크를 통해 렌더링할 때입니다.

iOS 26.4부터 WebKit에는 ‘강화된 보안 웹뷰(Enhanced Security Webviews)’라는 두 가지 강력한 새로운 옵션이 도입되었으며, 이러한 모드를 통해 앱을 제어하고, 앱이 웹 콘텐츠를 처리하는 방식을 관리하며, 추가적인 보안 강화 조치를 적용할 수 있습니다.

기본적으로 WebView는 앱 내부에서 WebKit의 모든 성능, 기능 및 성능을 제공하는 동시에 Safari의 모든 보안 완화 조치와 아키텍처를 그대로 유지합니다. 첫 번째 새로운 모드인 ‘호환성 극대화(Maximize compatibility)’ 제한 모드는 WebKit이 현재 지원하는 전체 웹 호환성을 유지하면서, 복잡한 프레임워크 코드의 상당 부분을 제거하고 최신 하드웨어 보안 완화 조치의 사용을 확대합니다.

두 번째 새로운 모드인 ‘잠금(lockdown)’ 제한 모드는 한 걸음 더 나아가, 앱의 WebView를 잠금 모드와 동일한 극도의 보호 수준으로 설정할 수 있게 해주며, 거의 사용되지 않는 웹 기술을 제거하여 공격자가 이용할 수 있는 옵션을 더욱 줄여줍니다.

애플에서는 메일을 포함하여 OS 전반에 걸쳐 이러한 보안이 강화된 웹뷰를 도입하기 시작했습니다. 간단히 살펴보겠습니다. iOS 26.4의 캡티브 포털 단축어 및 애플 광고입니다. 지금이 바로 여러분도 이 기능을 직접 체험해 보기에 아주 좋은 시기입니다.

공격 표면을 줄이는 것은 보안 투자에 비해 엄청난 성과를 가져다줍니다. 하지만 안전하지 않은 언어로 작성된 나머지 코드에는 여전히 메모리 안전성 취약점이 존재할 것이라는 가정을 해야 합니다.

이러한 경우, 그 다음으로 효과적인 방어 전략은 악의적인 행위자가 해당 취약점을 악용할 수 있는 능력을 제한하는 것입니다.

우리는 ‘보안 완화 조치’라고 알려진 여러 기술을 조합하여 이를 수행하며, ‘완화 조치’는 하나의 개념입니다. 잠시만요. ‘완화 조치’라는 개념 자체는 새로운 것이 아닙니다. 이 개념은 지난 30~40년 동안 진화해 왔으며, 애플은 지속적으로 새로운 완화 조치를 개발하고 제공하기 위해 노력하고 있고, 이미 여러분의 앱에서 많은 기능을 활용할 수 있습니다. 그리고 해당 기능이 안전하게 사용될 수 있다고 확신할 때, 대부분의 경우 여러분이 별도로 설정할 필요 없이 기본적으로 활성화됩니다. 완화 기술은 clang 스택 프로텍터와 같은 버퍼 오버플로우에 대한 초기 방어 수단부터, 비실행 가능 스택 및 ASLR(주소 공간 레이디엄), 나아가 커널 무결성 보호 및 빠른 권한 제한과 같은 최신 하드웨어 지원 기술에 이르기까지 다양합니다. Xcode 26에는 앱을 보호하는 데 사용할 수 있는 강력하고 새로운 소프트웨어 및 하드웨어 지원 완화 기술이 포함되어 있습니다.

포인터 인증은 컴파일러가 지원하는 하드웨어 기술입니다. 이 기술은 특정 범주의 취약점을 탐지하고 악용을 방지할 수 있을 뿐만 아니라, 설령 악용이 발생하더라도 앱의 코드 흐름 무결성이 유지되도록 보장합니다.

iPhone 17 및 iPhone 17 Pro와 함께 출시된 메모리 무결성 강제 적용(Memory Integrity Enforcement)은 5년간의 연구, 모델링 및 엔지니어링의 결실이며, 보안 할당기가 제공하는 견고한 기반 위에 구축되었으며, 향상된 메모리 태깅, 확장 기능 및 ‘태그 기밀성 강제 적용(tag confidentiality enforcement)’으로 알려진 보안 정책이 결합되어 있습니다. 내용이 상당히 방대하며, 해당 세션에서는 이보다 훨씬 더 많은 내용이 다뤄질 것입니다. 나중에 진행될 ‘메모리 무결성 강제 적용 및 포인터 인증 도입’ 세션에서는 이러한 완화 조치에 대해 훨씬 더 자세히 다룰 예정입니다. 또한 security.apple.com 블로그에서 저에 대한 모든 정보를 확인하실 수 있습니다.

애플은 메모리 무결성 강제 적용이 소비자용 운영 체제 역사상 메모리 안전성에 있어 가장 중요한 업그레이드라고 믿습니다.

하지만 극히 드문 경우, 정교한 공격자는 우리의 완화 조치에도 불구하고 접근하여 악용할 수 있는 취약점을 여전히 찾아낼 수도 있습니다.

이러한 경우, 우리의 최후의 방어선은 ‘격리(containment)’라고 합니다.

앞서 언급한 시나리오를 생각해 보십시오. 공격자가 앱의 메모리 안전성 취약점을 발견하고 악용한 시나리오를 가정해 봅시다. 이제 공격자는 앱을 완전히 제어하게 됩니다. 이상적인 목표는 공격자를 이와 같은 환경에 가두어, 앱 데이터나 플랫폼의 나머지 부분에 접근하지 못하게 하는 것입니다.

iPhone 초기부터 앱은 악의적인 접근을 방지하고 사용자 데이터를 보호하는 샌드박스 환경에서 실행되어 왔습니다. 물론 앱은 여전히 자체 데이터에 접근할 수 있으며, 이를 지원하는 시스템 서비스를 사용할 수 있습니다. 앱이 사용하는 프레임워크는 매우 정교한 공격자에 대항하기 위해 훨씬 더 극단적인 수준의 격리가 필요하지만, 앱 전체를 시스템에서 단순히 분리하는 방식으로는 불가능합니다. UI를 그리거나 리소스에 접근하는 등 해당 환경에서 기능을 수행하기 위해서는 너무 많은 접근 권한이 필요하기 때문입니다. 따라서 ‘메시지’나 ‘사파리’와 같이 보안이 중요한 앱에는 새로운 접근 방식이 필요합니다. 애플은 공격자가 제공하는 복잡한 데이터의 처리를, 다른 서비스나 커널과 같은 시스템 리소스에 대한 접근 권한이 거의 없는 강력한 샌드박스 환경으로 이동시키는 다중 프로세스 아키텍처를 설계했습니다.

그 결과, 알려지지 않은 취약점으로 인한 위험을, 설령 공격이 성공하더라도 공격자를 메시지나 쿠키와 같은 자산이 전혀 없는 환경에 가두어 둘 수 있게 되었습니다. 또한 이 환경에서는 권한을 상승시켜 사용자 데이터에 접근할 수 있는 기회가 극히 제한되어 있어 보안성이 한층 강화되었습니다. Xcode 26에서는 앱에서도 이러한 엄격하게 제한된 보안 환경을 활용할 수 있으며, 이를 ‘강화된 보안 확장(enhanced security extensions)’이라고 합니다. 메시지 앱이 사진을 수신할 때 이 아키텍처를 어떻게 활용하는지 살펴보겠습니다.

메시지 앱은 이를 ‘보안 확장’이라고 부릅니다. 방호벽(blast door)과 보안 정책은 간단합니다. 수신된 모든 자산은 블래스트 도어 내에서 파싱되어 기본 유형으로 분해되거나 실행될 때까지 악성으로 간주합니다. 이 정책에 따라 더 높은 권한을 가진 메시지 앱은 블래스트 도어로부터 반환받은 단순 유형만 검증하면 되며, 복잡하고 위험한 파싱 작업은 가장 낮은 권한 수준에서 수행됩니다.

따라서 메시지는 인터넷을 통해 메시지 앱으로 도착하며, 메시지 앱은 이를 파싱하거나 처리하려고 시도하지 않고, 보안 블래스트 도어 프로세스 내부의 블래스트 도어로 직접 전송합니다. 이제 이미지를 처리하고 파싱할 차례입니다. 기억하시다시피, 이 이미지는 공격자가 보낸 것일 수도 있습니다. 물론 대부분의 경우 이미지는 유효하며, 메시지 앱은 잠재적으로 복잡한 유형의 이미지를 검증 가능하고 사용자에게 표시할 수 있는 훨씬 단순한 형식으로 변환합니다. 이미지가 유효하지 않은 경우 오류가 발생합니다. 메시지(messages)는 해당 트래픽을 단순히 차단합니다. 만약 공격자가 블래스트(blast)의 취약점을 성공적으로 악용할 수 있다면, 비록 해당 취약점이 메시지 데이터베이스나 시스템의 나머지 부분에 접근 권한이 없는 두 번째 프로세스 내에 포함되어 있더라도 문제가 발생합니다.

따라서 블래스트는 이제 이미지를 메시지(messages)로 반환해야 합니다. 여기서 기억해야 할 중요한 점은, 이 보안 격리 프로세스가 침해되었을 가능성을 고려해야 한다는 것입니다. 따라서 해당 프로세스를 떠나 메시지(messages)로 반환되는 모든 데이터는 신뢰할 수 없습니다. 이는 성공적으로 트랜스코딩된 이미지일 수도 있고, 공격자가 제어하는 완전히 악의적인 데이터일 수도 있습니다.

이러한 이유로, 이 아키텍처에서 가장 중요한 점은 ‘메시지’가 수신한 데이터가 올바른 형식의 이미지이며 예상한 포맷을 따르는지 안전하고 확실하게 검증해야 한다는 것입니다. 또한 이는 메모리 안전성, Swift, 공격 표면 축소라는 이전 전략들을 모두 결합한 것입니다. 이러한 검증을 안전하게 수행하고, 필요한 최소한의 코드만 노출해야 합니다. 이미지가 검증되면, 트랜스크립트에 안전하게 표시할 수 있습니다.

이는 애플이 보안에 가장 민감한 코드베이스에서 격리 기법을 활용하는 한 가지 예시일 뿐입니다.

마지막으로, 다섯 번째로 가능한 방법은 다른 전략들을 독자적으로 추진하는 동시에 코드에서 가능한 한 많은 취약점을 찾아 제거하는 것입니다. 이 방법만으로는 공격을 완전히 막을 수는 없지만, 가장 취약한 지점을 찾아내고 공격자들이 그러하듯 가장 쉽게 공략할 수 있는 취약점을 식별하는 데 효과적일 수 있습니다. Apple에서는 코드 내 취약점을 찾아내기 위해 수동 및 자동화된 기법을 조합하여 활용합니다. 개발 과정 중 및 사후에 코드 감사를 수행하며, clang 정적 분석기를 사용하여 사람의 검토를 보조하고 지속적 통합(CI) 워크플로우에 활용합니다. 우리는 퍼징(fuzzing) 기법을 활용하는데, 이는 도구가 프로그램에 수많은 입력값을 자동으로 생성하여 취약점을 우연히 발견하려는 시도입니다. 또한 주소 살루나이저(address sanitizer)나 스레드 살루나이저(thread sanitizer)와 같은 도구는 코드 디버깅에 도움이 될 뿐만 아니라, 개발 단계에서나 퍼징과 같은 기법과 병행하여 취약점을 선제적으로 찾아내는 데도 기여합니다.

이처럼 애플은 메모리 안전 코드를 위한 다층적 접근 방식을 다음과 같이 체계화하고 있습니다. 방금 언급한 모든 도구를 활용하면, Swift와 같은 메모리 안전 언어를 사용하여 버그 발생을 근본적으로

방지하고, 공격 표면을 축소하여 취약점이 노출되지 않도록 할 수 있습니다. 코드에 완화 조치를 적용하여 취약점이 악용될 수 없도록 만드세요.

복잡한 파싱 작업에는 강화된 보안 확장 기능을 사용하여, 악용이 발생하더라도 그 피해를 최소화하세요. 마지막으로, 다른 전략들을 추진하는 동안 코드 내의 버그를 최대한 많이 식별하고 제거하세요.

이제 Apple의 보안 관련 언어 및 도구 개발을 총괄하는 데본에게 마이크를 넘기겠습니다. 감사합니다.

고마워요, 마크. 안녕하세요, 저는 데빈 코플린입니다. 저는 Apple에서 개발자 보안 도구 그룹을 이끌고 있습니다.

Xcode는 앱에 최첨단 보안을 제공하기 위해 신중하게 선별된 다양한 보호 기능을 제공합니다. 이제 이러한 개별 보호 기능과 활성화 방법에 대해 자세히 설명하고, 최대의 보호 효과를 얻기 위해 이를 어떻게 조합해야 하는지 설명하겠습니다.

보안은 메모리 안전성을 위한 상충 관계를 조율하는 것입니다. 가장 중요한 상충 관계는 보안상의 이점과 코드 변경 및 테스트와 같은 엔지니어링 노력입니다.

이 상충 관계를 세로축에 이점을, 가로축에 도입 용이성을 둔 그래프로 생각해 보세요.

일부 보호 기능은 적용하기는 쉽지만 제공하는 이점은 적습니다.

반면, 적용하기는 더 어렵지만 더 높은 보안 수준을 제공하는 기능도 있습니다. 이러한 상충 관계를 조율한다는 것은 최소한의 노력으로 최대의 이점을 얻는 것을 의미합니다.

바로 우측 상단 모서리에 위치한 ‘최적점’이 바로 그것입니다.

Apple의 목표는 하드웨어, 운영 체제, 프로그래밍 언어를 긴밀하게 공동 설계하여, 우수한 성능을 유지하면서도 이 최적점에 가까운 수준의 보호 기능을 제공하는 것입니다.

예를 들어, 메모리 무결성 강제 적용은 소프트웨어 기반 보호 기능에 비해 도입 비용이 훨씬 낮고 성능이 뛰어나면서도 강력한 보안을 제공합니다.

여기서 네 가지 유형의 보호 기능을 설명하겠습니다.

출시 전에 보안 결함을 찾아내고, 더 강력한 보안 조치를 도입할 수 있는 기반을 마련해 주는 버그 탐지 도구입니다.

대개 버튼 하나만 클릭하면 앱 전체의 보안을 강화해 주는 ‘전체 앱 보호’ 기능입니다.

기존의 안전하지 않은 코드베이스에 경계 안전성을 추가하는 데 도움이 되는 C 및 C++용 코드 강화 기능과,

완전한 메모리 안전성을 제공하는 Swift가 있습니다.

이것들은 마크가 설명한 전략과 동일하지만, 저는 이를 실행하는 데 사용할 수 있는 실제 기술들에 대해 자세히 다루겠습니다.

마크는 새로운 코드 베이스의 경우, 이 전략들을 가장 효과적인 것부터 순서대로 나열했습니다. 바로 거기서 시작해야 합니다. 처음부터 앱 전체에 대해 가장 높은 수준의 보호를 제공합니다.

하지만 이미 공격을 받고 있는 기존 앱에 보안을 사후 적용할 때는, 지금 당장 적용할 수 있는 보호 조치와 시간이 좀 더 걸리는 조치를 전략적으로 구분하는 것이 중요합니다.

저는 배포하기 쉬운 ‘빠른 보안 성과’부터 시작해 도입 순서대로 설명하겠습니다. 실행하는 데 더 오랜 시간이 걸리는, 믿기 힘들 정도로 강력한 보호 조치들입니다.

여러분이 앱을 최대한 안전하게 만들 수 있도록, 이러한 다양한 기술을 효과적으로 활용하는 방법을 안내해 드리겠습니다.

먼저 버그 탐지 도구부터 시작하겠습니다.

이 도구들은 출시된 앱에서 실행되는 능동적인 보호 수단이 아닙니다. 대신, 빌드 및 디버깅 단계에서 사용되어 앱이 출시되기 전에 버그를 찾아내는 데 도움을 줍니다. 또한 버그를 조기에 발견함으로써 더 강력한 기술 도입의 토대를 마련해 줍니다.

이 도구들은 우하단 사분면에 위치합니다.

사용법은 간단합니다. 도구를 실행하고 문제 해결을 시작하기만 하면 됩니다.

이 도구들은 조치 가능한 버그를 찾아내지만, 모든 버그를 찾아낼 수는 없습니다. 따라서 훌륭한 예방 조치이긴 하지만, 나중에 설명할 다른 보안 조치들을 도입하는 것이 매우 중요합니다.

다행히도 이 도구들을 실행하면 다른 조치들을 더 쉽게 도입할 수 있습니다.

제가 먼저 다룰 버그 탐지 도구는 ‘산티라이저(sanitizers)’입니다. 이 도구들은 앱이 실행되는 동안 버그를 찾아내는 데 도움이 되는 추가 계측 코드를 삽입하여 앱을 재컴파일합니다. C 계열 언어와 Swift에서 작동합니다.

산티라이저의 가장 큰 장점은 오탐이 거의 없다는 점입니다. 산티라이저가 버그를 보고한다면, 실제로 버그가 있는 것입니다.

‘어드레스 산티라이저(Address Sanitizer)’는 어떤 메모리 위치가 유효하고 어떤 위치가 무효한지 추적하여 메모리 안전성 버그를 찾아냅니다. 이 도구는 앞서 마크가 보여준 종류의 버퍼 오버플로우나, 프로그래머가 메모리를 해제했지만 실수로 매달린 포인터를 남겨둔 ‘use-after-free’ 버그를 찾아내는 데 탁월합니다.

힙과 스택은 물론 전역 변수에서도 메모리 손상을 감지합니다.

또한 메모리가 할당되고 해제된 위치를 보여주는 백트레이스를 제공하여 이를 통해 버그를 신속하게 수정할 수 있도록 돕습니다. 스레드 세니타이저(Thread Sanitizer)는 두 스레드 간에 동기화가 이루어지지 않은 상태에서 한 스레드가 다른 스레드가 접근 중인 메모리를 방해할 때 발생하는 데이터 경합(data race)을 찾아냅니다.

이는 자동 참조 카운팅(reference counting)이 적용된 환경에서도 메모리 손상을 유발할 수 있습니다.

다음은 clang 정적

분석기입니다.

이 도구는 애플리케이션을 실행할 필요조차 없이 버그를 찾아냅니다. 대신, 프로그램 내의 가능한 실행 경로를 시뮬레이션합니다. 즉, 버그를 찾기 위해 테스트 커버리지가 필요하지 않습니다. 하지만 그 대가로 이 도구에서는 오탐이 발생할 수 있습니다. 즉, 버그가 없는데도 버그가 있다고 보고할 수 있습니다.

이 분석기는 C, C++, Objective-C를 지원합니다.

버퍼 오버플로우, 동결 후 사용(use after freeze), 초기화되지 않은 메모리 사용, 안전하지 않은 API 사용 등 보안에 민감한 많은 버그를 찾아냅니다.

타겟의 빌드 설정에서 이러한 검사를 활성화한 다음, 제품 메뉴에서 ‘분석(analyze)’을 선택하여 분석기를 실행하세요.

분석기가 버그를 발견하면 해당 문제와 버그가 발생하는 제어 흐름 경로를 표시합니다.

화살표는 버그가 발생하기까지의 프로그램 경로에서 각 단계를 나타내며,

설명은 해당 경로를 따라 발생하는 주요 이벤트를 설명합니다. 예를 들어, ‘free’ 후 사용(use after free)의 경우, 경로는 메모리가 할당되고, 해제된 후, 나중에 사용된 위치를 보여줍니다. 이를 통해 취약점을 쉽게 이해하고 수정할 수 있습니다.

Address Sanitizer, Thread Sanitizer 및 Clang 정적 분석기는 코드 개발에 도움이 되는 핵심 버그 탐지 도구입니다. 빌드 및 테스트 단계에서 이 도구들을 활용하세요. 이 도구들은 버그 중 일부는 찾아내지만, 전부는 아닙니다.

이러한 도구들을 실행하는 것은 앱에 더 강력한 보호 기능을 도입하기 위한 훌륭한 첫걸음입니다. 분명히 말하자면, 아직 해야 할 일이 더 많습니다. 하지만 이 도구들은 추가적인 필수 보호 기능을 도입할 수 있는 기반을 마련해 줍니다.

다음으로, 앱 전체에 대한 보호 기능에 대해 다루겠습니다. 이러한 보호 기능은 코드, 라이브러리, 시스템 프레임워크를 포함한 앱 전체에 탁월한 기본 수준의 보안을 제공합니다. 추가하기 쉬우며 보안 수준을 크게 높여줍니다.

타입 기반 할당기(typed allocator), 메모리 태깅(memory tagging), 포인터 인증(pointer authentication), 읽기 전용 메모리(read-only memory), 보안 확장 기능 강화(enhance security extensions) 등 다섯 가지의 앱 전체 보호 기능을 다룰 것입니다.

첫 번째 앱 전체 보호 기능은 타입 기반 할당기입니다.

이는 ‘해제 후 사용(use after free)’ 공격으로부터 보호하는 새로운 시스템 할로케이터입니다. 이 기능은 우측 상단 모서리의 최적 지점에 가까워 매우 훌륭합니다.

보호 성능이 뛰어나며 도입하기도 매우 쉽습니다.

‘해제 후 사용’ 버그는 메모리 손상(memory corruption)의 한 형태로, 프로그램이 메모리를 할당하고 해제했지만 실수로 매달린 포인터(dangling pointer)를 남겨두는 경우입니다. 해제된 메모리의 유형을 ‘피해자(victim)’라고 합니다.

공격자는 프로그램을 조작하여 다른 유형의 메모리를 할당함으로써 이 매달린 포인터를 악용합니다. 공격자는 동일한 위치에 ‘공격자’ 메모리를 할당한 다음, ‘피해자’ 포인터가 마치 ‘피해자’ 유형인 것처럼 ‘공격자’ 메모리의 데이터에 접근하도록 유도합니다. 이를 ‘유형 혼동(type confusion)’이라고 합니다. 만약 공격자가 피해자를 속여 공격자가 제어하는 데이터를 포인터로 접근하게 만들 수 있다면, 의도하지 않은 메모리를 수정하거나 예상치 못한 코드를 호출할 수도 있습니다.

유형 기반 할당기를 사용하면 컴파일러와 운영 체제가 협력하여 서로 다른 메모리 버킷에 서로 다른 유형을 확률적으로 할당함으로써 유형 혼동을 방지합니다.

공격자가 할당하는 메모리와 피해자 메모리는 서로 다른 버킷에 배치될 가능성이 높으므로, 공격자는 유형 혼동에 의존할 수 없습니다.

Apple 보안 연구 블로그에는 차세대 Xnu 메모리 안전성에 관한 훌륭한 게시물이 있는데, 여기에는 커널에 이 접근 방식을 적용하는 방법에 대해 매우 상세히 설명되어 있습니다.

타입 기반 할당기를 활성화하려면 '서명 및 기능(Signing and Capabilities)' 편집기로 이동합니다. '강화된 보안 기능(enhanced security capability)'을 추가하고 빌드 설정을 활성화합니다. 지금 바로 활성화하세요. 이 기능은 '해제 후 사용(use after free)' 취약점에 대해 매우 강력한 보호 기능을 제공합니다. 체크박스를 선택하고 앱을 재컴파일하는 것만큼 간단합니다.

전체 앱을 보호하는 두 번째 방법은 하드웨어 메모리 태깅입니다. 이 기능은 버퍼 오버플로우, 'use after free' 버그, 힙 할당 메모리에 대해 매우 강력한 방어력을 발휘합니다. 이는 타입 기반 할당기 및 커널의 태그 기밀성과 연동되어 메모리 무결성을 강제 적용하도록 설계된 CPU 기능입니다.

iPhone 17, iPhone Air는 물론 M5 기반 Mac 및 Vision Pro에서도 사용할 수 있습니다. 하드웨어 메모리 태깅은 우측 상단의 '최적 지점'에 매우 가깝게 위치합니다. 보호 수준이 높고 도입이 용이하며, 동시에 성능 오버헤드도 낮게 유지합니다.

다음은 이 기능이 메모리 손상을 방지하는 방식입니다.

타입 기반 할당기는 각 포인터와 각 할당에 태그를 할당합니다.

그런 다음 CPU는 태그와 포인터, 그리고 메모리 내의 태그가 일치하는지 확인합니다. 일치하지 않는 경우, 이는 'use after free' 버그나 버퍼 오버플로우를 의미하므로, 하드웨어는 메모리 손상을 허용하지 않고 안전하게 트랩을 발생시킵니다.

다음은 버퍼 오버플로우를 예로 든 것입니다.

피해자 포인터는 가리키는 메모리와 일치하는 태그를 가지고 있으며, 공격자 포인터도 마찬가지입니다. 버퍼 오버플로우가 발생하면 공격자는 공격자 포인터를 통해 피해자 메모리로 오버플로우를 일으킵니다. 하지만 공격자 포인터의 태그와 피해자 메모리의 태그가 서로 다르기 때문에, CPU는 공격이 계속되는 것을 허용하지 않고 불일치를 감지합니다.

메모리 태그 불일치는 앱을 중단시킵니다. 따라서 메모리 태깅 진단 기능을 활성화한 상태에서 보호 테스트를 실행하고, Address Sanitizer 및 Thread Sanitizer도 함께

적용한 후, 메모리 손상 문제를 모두 수정해야 합니다. 하드웨어 메모리 태깅을 활성화하는 방법에 대해 자세히 알아보려면 developer.apple.com에서 ‘메모리 무결성 적용을 통한 앱 보안(Secure your App with Memory Integrity Enforcement)’ 동영상을 시청하세요.

하지만 보안 할당기(secure allocator)와 하드웨어 메모리 태깅을 활성화하더라도 일부 메모리 손상 버그는 여전히 악용될 수 있습니다.

세 번째 유형의 전체 앱 보호 기능은 포인터 인증입니다.

포인터 인증을 사용하면 하드웨어, 컴파일러 및 운영 체제가 모두 협력하여 앱 내 제어의 무결성을 강제함으로써 다층적인 방어 체계를 제공합니다.

이 기능은 iPhone 10S 및 그 이후 모델과 모든 Apple Silicon 기반 Mac에서 사용할 수 있습니다.

제어 흐름 무결성 공격에서 공격자는 메모리 손상을 악용하여 앱의 제어권을 탈취합니다.

이로 인해 프로그램은 개발자가 의도하지 않은 예기치 못한 상태에 빠지게 됩니다.

앞서 마크가 설명한 스택 버퍼 오버플로우 사례를 떠올려 보십시오. 공격자가 비밀번호 버퍼를 오버플로우시켜 인접한 함수 포인터를 덮어쓴 사례입니다.

공격자는 지나치게 긴 비밀번호를 입력함으로써 함수 포인터의 값을 원하는 대로 변경할 수 있었습니다. 그러면 프로그램 내의 어떤 함수든 호출할 수 있게 되어 예기치 못한 상태로

이어질 수 있습니다.

포인터 인증을 사용하면 CPU는 포인터가 사용되기 전에 암호학적으로 서명하고 이를 인증합니다. 포인터의 서명이 예상된 것과 일치하지 않으면, 버퍼 오버플로우 예시에서와 같이 하드웨어는 예기치 않은 코드를 호출하는

대신 안전하게 트랩을 발생시킵니다. 이를 통해 공격자가 임의의 함수를 호출하는 것을 방지할 수 있습니다.

포인터 인증은 보호의 마지막 방어선으로서 메모리 무결성 강제 적용과 훌륭하게 조화를 이룹니다.

이 기능은 이점-도입 차트의 중심에 확고히 자리 잡고 있습니다. 보호 효과는 뛰어나지만, 특히 복잡한 C++ 코드베이스에서는 도입에 다소 노력이 필요할 수 있습니다.

따라서 이 기능을 활성화한 후 앱을 철저히 테스트하여 충돌이 발생하지 않는지 확인하십시오.

또한 타입 지정 할당기 및 하드웨어 메모리 태깅과 함께 사용할 때 가장 효과적이므로, 포인터 인증을 적용하기 전에 먼저 해당 기능들을 도입하십시오.

이 기능을 사용하려면 앱이 하드웨어 지원이 없는 구형 기기에서도 실행될 수 있도록 arm64 및 arm64 e 슬라이스를 모두 포함하는 범용 바이너리를 빌드해야 합니다. 이는 앱 내의 모든 라이브러리도 범용이어야 함을 의미합니다.

따라서 공급업체의 바이너리 라이브러리나 프레임워크에 의존하고 있다면, 해당 공급업체와 협력하여 유니버설 버전의 종속성을 확보해야 합니다.

네 번째 보호 기능은 읽기 전용 플랫폼 메모리입니다.

동적 로더는 앱과 그 라이브러리의 코드를 로드하는 역할을 합니다. 공격자가 동적 로더의 메타데이터를 탈취할 수 있다면, 이는 매우 매력적인 공격 대상이 됩니다. 공격자는 이를 이용해 앱을 완전히 제어할 수 있습니다.

읽기 전용 플랫폼 메모리는 공격자가 해당 데이터를 수정하지 못하도록 방지하므로, 동적 로더 자체만이 이를 변경할 수 있습니다. 이는 귀중한 보안 보호 기능을 제공하며 도입하기도 매우 쉽습니다.

대부분의 앱은 호환성을 보장하기 위해 별도의 변경을 할

필요가 없습니다. 시스템 API를 사용하여 De Wilde 및 Objective-C 런타임 메타데이터를 수정하십시오. 메타데이터를 직접 수정해서는 안 됩니다.

전체 앱 보호의 마지막 유형은 ‘프로세스 외부 강화 보안(Out-of-process Enhanced Security)’ 확장 기능입니다. 마크가 설명했듯이, 이 접근 방식은 격리(containment)의 한 형태입니다. 구현에 어느 정도의 투자가 필요하지만, 매우 강력한 보안 이점을 제공합니다.

신뢰할 수 없는 데이터를 처리하는 코드를 확장 기능으로 이동시켜 적용하십시오.

그런 다음 안전한 시스템 API를 사용하여 메인 앱에서 데이터를 전송하십시오. 확신할 수 없는 데이터를 앱 확장 프로그램에서 처리하고, 결과를 메인 앱으로 다시 전달한 후 반드시 유효성을 검증하십시오.

자, 격리 방식은 공격자가 메모리 손상을 악용하여 앱 확장 프로그램을 침해할 수 있다고 가정합니다.

목표는 해당 공격자를 해당 프로세스 내에 격리하여, 메인 애플리케이션의 데이터에 접근하지 못하게 하는 것입니다.

이를 적용하려면 앱의 어느 부분에서 신뢰할 수 없는 데이터를 처리하는지 평가하십시오.

코드 베이스를 리팩토링하여 해당 부분을 별도의 프로세스로 분리하고, 앱 확장 프로그램에서 반환된 응답을 검증하십시오. 그 결과를 무조건 신뢰해서는 안 됩니다. 이는 다른 보호 전략을 보완하는 수단입니다. 다른 전략을 대체하는 것은 아닙니다. 따라서 앱 전체에 대해 메모리 무결성 강제 적용을 활성화한 후에 도입하십시오. 또한 분리 작업에는 다소 시간이 걸릴 수 있으므로, 포인터 인증과 병행하여 진행하십시오. 전체 앱 보호 기능은 여러 단계 중 일부에 불과합니다.

또는 Xcode에서 몇 가지 단계를 거쳐 도입할 수도 있습니다. 타입 기반 할로케이터, 메모리 태깅, 포인터 인증, 읽기 전용 메모리를 활성화하십시오. 강화된 보안 기능을 도입한 후,

강화된 보안 확장 기능을 생성하십시오.

이러한 전체 앱 보호 기능을 도입하여 앱 전체에 강력한 기본 보안 수준을 제공하십시오.

이러한 보호 기능은 훌륭하지만, 앱에 C 기반 언어로 작성된 공격 표면(Attack Surface)이 있다면 더 강력한 보호가 필요합니다.

전체 앱 보호 기능을 적용한 후, 신뢰할 수 없는 입력을 처리하는 안전하지 않은 코드 기반에 대해서는 더욱 강력한 접근 방식을 적용하세요.

Xcode는 C와 C++ 모두에 대한 보호 기능을 제공합니다.

먼저 C++부터 살펴보겠습니다.

대부분의 코드 기반은 컨테이너 클래스 및 기타 널리 사용되는 추상화를 위해 표준 라이브러리를 사용합니다.

C++ 표준 라이브러리 강화 기능은 표준 span 및 vector와 같은 클래스에서 발생하는 범위를 벗어난 액세스를 방지합니다. 표준 라이브러리를 광범위하게 사용하는 코드베이스에서

메모리 손상을 허용하지 않고 안전하게 차단하므로, 이 강화 기능은 보안 도입의 상충 관계에서 우측 하단 사분면에 위치합니다. 도입이 매우 쉽고 확실한 보호 기능을 제공합니다.

더 강력한 보호를 원한다면 Xcode의 C++용 ‘경계 안전 버퍼 사용(bound safe buffer usage)’ 옵션은 더 강력한 보장을 제공합니다.

이 모드에서는 컴파일러가 안전하지 않은 원시 포인터 연산을 거부합니다. 대신 표준 span, string, vector와 같은 관용적인 라이브러리 추상화의 사용을 요구합니다.

이러한 방식으로, 원시 포인터 연산을 방지하기 위한 컴파일 시간 검사, 런타임 보호 기능, 그리고 강화된 C++ 표준 라이브러리의 조합이 언어에 경계 안전성을 부여합니다.

하지만 C++과 달리 C는 경계 안전 포인터 산술을 위한 사용하기 쉬운 라이브러리 추상화를 제공하는 연산자 오버로딩과 같은 고수준 언어 기능을 갖추고 있지 않습니다.

이러한 격차를 메우기 위해 Apple은 경계 안전성을 직접 내장한 C용 새로운 언어 확장을 개발했으며, 이 확장을 언어 표준에 통합하기 위해 노력하고 있습니다.

작동 방식은 다음과 같습니다. 포인터에 안전하게 인덱싱하려면 해당 포인터가 가리키는 메모리의 경계에 대한 정보가 필요합니다. 따라서 안전성을 보장하기 위해, 컴파일러는 포인터의 범위를 판단할 수 없을 때 오류를 발생시켜 해당 영역에 대한 인덱싱을 차단합니다. 사용자는 어노테이션에 범위를 추가하여 컴파일러가 범위를 판단하는 방법을 알려줄 수 있으며,

컴파일러는 런타임 시 범위를 벗어난 액세스가 발생하면 안전하게 트랩할 수 있도록 범위 검사 코드를 삽입합니다.

이러한 방식으로, 프로그래머가 제공한 어노테이션과 컴파일러가 생성한 런타임 범위 검사의 조합을 통해 경계 안전성이 실현됩니다.

Xcode의 C 및 C++ 경계 안전성 기능은 사분면의 왼쪽 상단 모서리에 위치합니다. 이 기능들은 강력한 보장을 제공하여 특정 유형의 취약점을 완전히 제거하지만, 소스 코드의 수정이 필요합니다. 메모리 무결성 강제 적용과 같은 앱 전체 보호 기능을 이미 도입한 후에 이 기능을 적용하여, 가장 민감한 C 및 C++ 코드에 대한 보안을 한층 더 강화하십시오.

지금까지 저는 안전하지 않은 C, C++ 및 Objective-C 코드베이스에 보호 기능을 사후 적용하도록 설계된 도구들에 대해 설명해 드렸습니다. 이것들은 강력한 보호 수단이지만, 완전한 메모리 안전성을 확보하려면 메모리 안전 언어가 필요합니다.

Swift는 메모리 안전성을 보장하며, OS 하드웨어 및 언어 수준에서 플랫폼 보안 보호 기능을 활용합니다.

Swift 6.2는 저수준 사용 및 파서, 그리고 보안과 성능이 중요한 기타 경우를 위해 설계된 새로운 경량 라이브러리 추상화 계열을 제공합니다.

예를 들어, 새로운 Span 유형 계열을 사용하면 연속적인 비소유 메모리에 접근할 수 있습니다.

Span은 완전히 메모리 안전합니다. Span은 고급 기능과 Swift 표준 라이브러리를 활용하여 수명 안전성과 경계 안전성을 모두 보장합니다.

Span은 또한 빠릅니다. 수명 안전성과 고도로 최적화된 경계 검사를 위해 런타임 오버헤드를 제로로 보장해야 하는 경우에 매우 유용합니다.

Swift Span을 사용하면, 수명 안전성을 위한 컴파일 타임 검사와 경계 안전성을 위한 런타임 검사의 조합을 통해 보안과 낮은 오버헤드를 모두 확보할 수 있습니다.

앱을 보호하기 위한 두 가지 전략이 있으며, Swift는 새로운 코드를 작성하거나 기존 보안에 민감한 코드를 재작성하는

방식을 채택합니다.

두 전략을 모두 활용하세요. Swift를 사용하면 메모리 안전 코드를 쉽게 작성할 수 있습니다.

아직 Swift로 새 코드를 작성하고 있지 않다면, 지금 바로 시작하세요. 오늘 작성하는 코드가 바로 미래에 공격자들이 노릴 대상이 될 것입니다. 자, 그렇습니다. Swift의 새로운 기능들 말이죠. 그리고 기존 하위 시스템을 리팩토링하거나 현대화할 때, 그 기회를 활용하여 해당 코드도 Swift로 작성하세요.

보안 취약점을 줄이기 위해서입니다. 기회가 생길 때까지 리팩토링을 미루지 마세요. 대신, 선제적으로 해당 구성 요소를 Swift로 재작성하세요.

가장 중점적으로 집중해야 할 영역은 파서(특히 미디어 및 프로토콜 관련), 복잡한 상태 머신, 객체 수명 주기 제어, 그리고 신뢰할 수 없는 입력을 처리하는 모든 부분입니다.

이제 악의적인 공격자로부터 앱을 보호하는 방법을 알게 되었습니다.

이것들은 Apple이 자사 앱에 적용하는 것과 동일한 보안 조치입니다. 이 조치들은 코드베이스의 핵심 부분에 계층적으로 적용될 때 세심하게 설계된 효과를 발휘합니다. 이를 통해 최고 수준의 보안을 확보할 수 있습니다.

이를 도입하려면, Xcode에서 메모리 무결성, 강제 적용, 포인터 인증을 포함한 강화된 보안 기능을 활성화하여 앱 전체에 대한 기본 수준의 보호를 제공하십시오.

신뢰할 수 없는 입력 처리를 제한하고 강화된 보안 확장 기능을 활용하며, 바운드 안전성 확장 기능을 통해 안전하지 않은 C 및 C++ 코드 기반을 보호하십시오.

또한 모든 신규 코드와 보안 영역의 표적 재작성 시 완전한 메모리 안전성을 보장하는 Swift를 사용하십시오.

지금은 그 어느 때보다 보안이 중요합니다. 오늘 바로 이러한 조치를 취하여 앱과 사용자, 그리고 사용자의 민감한 데이터를 보호하십시오. 감사합니다.