사이버 복원력법 준수 및 Application Security 

대부분의 조직은 사이버 복원력법(CRA)을 준수하기 위해 잘못된 단계에 투자하고 있습니다. 파이프라인을 강화하고, 스캔 범위를 확장하고, 위험 평가를 상세하게 문서화하는 데 그치고 있습니다. 이러한 활동은 모두 제품 출시 전에 이루어집니다. 하지만 이 법규는 제품이 이미 배포되어 제조업체가 통제할 수 없는 환경에서 운영되고 있는 출시 후에 법적 책임을 부과합니다. 

CRA는 이를 명시적으로 규정하고 있습니다. 디지털 요소를 포함하는 제품은 시장 출시 시점뿐만 아니라 운영 수명 전반에 걸쳐 필수적인 사이버 보안 요건을 충족해야 하며, 여기에는 취약점 처리 방식과 사고 탐지 및 보고 방식이 포함됩니다. 이는 대부분의 팀이 대비하지 못한 새로운 유형의 장애를 야기합니다. 규정 준수 여부는 개발 단계에서 취약점이 발견되었는지 여부로 결정되는 것이 아닙니다. 제품이 악용에 얼마나 잘 저항하고, 영향을 최소화하며, 악용 발생 시 증거를 확보할 수 있는지 여부로 결정됩니다.

CRA는 위치에 관계없이 EU 내에서 "디지털 요소가 포함된 제품"(하드웨어 또는 소프트웨어)을 개발, 수입 또는 유통하는 모든 조직에 적용됩니다.

타임라인: 사이버 복원력이 실용화되는 시점 

사이버 복원력법은 이미 시행 중입니다. 2024년 12월 10일에 발효된 이 법은 디지털 요소를 포함하는 제품 제조업체에 대한 부담을 점진적으로 증가시키는 구체적인 시행 경로를 제시합니다. 첫 번째 주요 시행 단계는 2026년 9월 11일에 제14조에 따른 보고 의무가 발효되는 시점입니다. 법의 모든 조항은 2027년 12월 11일부터 시행됩니다. 

이러한 과정은 규정 준수 경험에 있어 구조적인 변화를 가져옵니다. 조직은 한때 성숙도를 나타내는 지표였던 역량들이 정해진 대응 기한과 연계된 의무적인 요구 사항으로 바뀌는 전환기를 거치게 됩니다. 2026년이라는 중요한 시점 이전에는 악용 가시성 확보와 취약점 처리 능력을 개선 영역으로 간주할 수 있습니다. 하지만 그 시점 이후에는 이러한 역량들을 탐지, 분류 및 대응을 입증하는 증거를 바탕으로 엄격한 기한 내에 운영해야 합니다. 

2027년까지 이 표준은 전체 제품 수명주기에 걸쳐 적용될 것입니다. 안전한 개발 관행, 테스트 범위 및 위험 평가는 실제 환경에서 제품이 어떻게 작동하는지와 직접적으로 연결되어야 합니다. 이러한 기대는 설계 의도에만 국한되지 않습니다. 제품이 조직의 통제 범위를 벗어난 환경에서 실행될 때 철저한 검증을 견딜 수 있는지, 그리고 지원 프로세스가 검토 시 검증 가능한 증거를 생성할 수 있는지 여부까지 포함합니다. 

바로 이 지점에서 많은 준비 노력이 방향을 잃기 시작합니다. 팀들은 문서화, 사전 출시 검증, 그리고 통제 범위 확보에 집중하는데, 이는 이러한 요소들이 목록화하고 감사하기가 더 쉽기 때문입니다. 하지만 출시 일정은 다른 부분에 압박을 가합니다. 제품이 악용에 저항하고, 실제 악용 사례를 탐지하며, 출시 후에도 방어 가능한 상태를 유지한다는 것을 입증해야 하기 때문입니다. 규정 준수는 단순히 준비 단계만이 아니라 실제 작동 시의 동작과 관찰 가능한 증거에 따라 좌우됩니다. 

공격자는 사용자의 제어가 아닌 바이너리 파일과 상호 작용합니다. 

부록 I 파트 I에서는 제품이 공격 표면을 제한하고, 무단 조작을 방지하고, 무결성을 보호하고, 사고의 영향을 줄여야 한다고 규정합니다. 이러한 요구 사항은 공격자와 배포된 소프트웨어 간의 직접적인 상호 작용을 전제로 합니다. 

모바일 애플리케이션이 다운로드되고 압축이 해제됩니다. 해당 애플리케이션의 클래스와 메서드가 재구성됩니다. API 엔드포인트와 인증 로직이 추출됩니다. 동일한 세션 내에서 런타임 계측 프레임워크가 연결되어 실행을 가로채고 수정합니다. 함수 반환 값을 재정의하여 유효성 검사를 우회합니다. 요청의 구조적 유효성이 유지되므로 서버 측 이상 현상은 발생하지 않습니다. 이것이 CRA가 작성된 기본 실행 환경입니다. 

Digital.ai Application Security 컴파일된 애플리케이션을 수정하여 역공학을 통해 더 이상 로직을 유용하게 표현할 수 없도록 만듭니다. 제어 흐름을 변경하고, 식별자를 제거하며, 실행 경로를 비선형으로 만듭니다. 이렇게 하면 분석이 불가능해지는 것은 아니지만, 대부분의 공격에 필요한 노력을 실질적으로 한계 이상으로 증가시킵니다. 이 공격 방식은 애플리케이션이 이미 구축되어 있다고 가정하고, 공격자가 애플리케이션에 대한 완전한 접근 권한을 가졌을 때 어떻게 동작하는지에 초점을 맞춥니다.  

표준 모바일 뱅킹 애플리케이션을 사용하면 이러한 단계를 몇 분 안에 재현할 수 있습니다. 비즈니스 로직은 컴파일된 애플리케이션에서 직접 재구성됩니다. 클라이언트 측 컨트롤은 정적 분석을 통해 확인할 수 있습니다. 그런 다음 런타임 계측을 사용하여 실행 중에 유효성 검사 로직을 재정의합니다. 

일반적인 구현에서 애플리케이션은 서버에서 발급되어 기기에 로컬로 저장된 토큰을 통해 사용자 세션을 유지합니다. 아키텍처 관점에서 볼 때, 이 모델은 애플리케이션과 백엔드 서비스 간의 인증된 통신을 통해 안전하고 통제된 것처럼 보입니다. 사용자 입장에서 애플리케이션은 설계된 대로 계속 작동합니다. 백엔드로 전송되는 요청은 구조적으로 유효하고 인증되었으며 예상되는 동작과 일치합니다. 인프라 관점에서는 어떠한 이상도 감지되지 않습니다. 침해는 전적으로 애플리케이션 경계 내에서 발생하며, 실행이 변경되고 민감한 데이터가 노출되었지만 예상되는 요청 패턴은 깨지지 않았습니다. 

취약점 악용은 애플리케이션 내부에서 발생합니다. 

은행 애플리케이션은 안전한 개발 관행을 따르고, 인증을 강화하며, 서버 측 유효성 검사에 의존하면서도 배포 후에는 외부에 노출될 수 있습니다. 모바일 뱅킹 애플리케이션은 서버에서 발급되어 기기에 로컬로 저장된 토큰을 통해 사용자 세션을 유지합니다. 애플리케이션은 로그인, 잔액 조회, 거래 등을 위해 백엔드 엔드포인트와 통신합니다. 아키텍처 관점에서 볼 때, 이러한 모델은 통제되고 안전해 보입니다. 

공격자는 인프라를 직접 공격하는 대신 애플리케이션 바이너리를 추출하여 그 로직을 재구성합니다. 표준 리버스 엔지니어링 도구를 사용하여 API 엔드포인트, 인증 흐름, 세션 토큰 저장 위치 등을 파악합니다. 그런 다음, 공격자는 변조된 코드를 삽입하여 애플리케이션을 재패키징하고, 정상적인 서비스와 유사하게 위장한 피싱 사이트를 통해 배포합니다. 사용자가 변조된 버전을 설치하고 실행하면, 사용자 입장에서는 애플리케이션이 정상적으로 작동하는 것처럼 보입니다. 하지만 동시에 세션 토큰을 탈취하여 공격자에게 전송합니다. 

공격자는 해당 토큰을 이용해 백엔드에 직접 유효한 요청을 보냅니다. 서버는 요청의 구조와 인증 방식이 합법적으로 보이기 때문에 이상 징후를 감지하지 않고 처리합니다. 인프라 모니터링 관점에서는 아무런 이상도 발생하지 않습니다. 하지만 애플리케이션 입장에서는 실행 방식이 변경되었고, 민감한 데이터가 노출되었습니다. 이것이 바로 사이버 복원력법(Cyber ​​Resilience Act)이 가정하는 운영 환경입니다. 제품은 더 이상 제조업체의 통제하에 있지 않습니다. 공격자는 합법적인 경로를 이용하여 애플리케이션과 직접 상호 작용하고, 동작을 변경하고, 취약점을 악용합니다. 

위험 평가는 신청서에 해당 내용이 포함된 경우에만 시행됩니다. 

제13조는 디지털 요소를 포함하는 제품 제조업체가 사이버 보안 위험을 평가하고 설계, 개발, 생산 및 유지 관리 전반에 걸쳐 해당 위험을 해결하도록 요구합니다. 또한 이 규정은 이러한 평가를 문서화하고 유지 관리하며 제품 작동 방식에 반영하도록 요구합니다. 실제로 평가는 문서 형태로만 존재하며, 시행은 외부 통제에 의존합니다. 역공학은 위험 요소로 식별되지만, 이를 방지하는 메커니즘은 없습니다. 런타임 조작은 인정되지만, 탐지는 이를 관찰할 수 없는 인프라 신호에 의존합니다. 

Digital.ai 애플리케이션 보안(AppSec)은 위험 평가 결과를 애플리케이션 자체에 내장함으로써 이러한 격차를 해소합니다. 평가에서 리버스 엔지니어링이 위협으로 식별되면 난독화 기능을 통해 해당 활동에 대한 저항력을 직접적으로 강화합니다. 조작이 식별되면 변조 방지 기능을 통해 변경된 실행 경로를 탐지하고 차단합니다. 민감한 자산이 위험에 처한 경우, 정적 또는 동적 분석을 통해 추출할 수 없도록 애플리케이션 내에서 보호됩니다. 

이는 CRA 요구사항과 제품 동작 간의 직접적인 연관성을 만들어냅니다. 해당 규정은 위험을 최소화하고 사고를 예방하거나 그 영향을 줄일 것을 요구합니다. 이러한 요구사항은 애플리케이션 자체가 실행 중에 이러한 조건을 준수할 때에만 충족됩니다. Digital.ai 애플리케이션 보안(AppSec)은 위험 평가를 수행하거나 규정 준수 문서를 유지 관리하지 않습니다. 대신, 해당 평가의 결론이 실제 운영 환경에서 애플리케이션에 적용되도록 보장하며, 궁극적으로 규정 준수 여부가 검증되는 현장을 지원합니다. 

해당 규정은 패치 격차를 인정하지만, 대부분의 아키텍처는 그렇지 않습니다. 

부록 I 파트 II는 취약점을 지체 없이 해결하고 보안 업데이트를 효과적으로 배포할 것을 요구합니다. 또한 지속적인 테스트, 조정된 정보 공개, 업데이트 배포 메커니즘을 명시하고 있습니다. 이 규정은 취약점이 존재할 것이며 시간이 지남에 따라 처리되어야 함을 인정합니다. 즉각적인 해결을 전제로 하지 않으며, 취약점 공개와 전체 패치 적용 사이에 알려진 노출 기간이 존재합니다. 이 기간 동안 취약점은 공개되고, 악용 기법이 사용 가능하며, 배포된 시스템은 패치가 적용되지 않은 상태로 남아 있습니다. 

Digital.ai 애플리케이션 보안(AppSec)은 이 기간 동안 취약점 악용 가능성을 줄입니다. 취약점을 악용하려면 취약한 로직을 이해해야 하는 경우, 난독화는 해당 로직을 찾고 해석하는 데 필요한 시간을 늘립니다. 실행 방식을 변경해야 하는 경우, 변조 방지 기능은 변경된 동작을 차단합니다. 런타임 동작을 관찰해야 하는 경우, 보호 조치는 관찰에 사용되는 도구를 방해합니다. 이러한 조치는 취약점의 실질적인 영향을 변화시킵니다. 취약점은 여전히 ​​존재하지만, 대규모로 악용하기는 더 어려워집니다. 

Digital.ai AppSec은 취약점 관리, SBOM 생성 또는 패치 배포를 대체하는 것이 아닙니다. 이러한 기능은 CRA 의무를 이행하는 데 여전히 필요합니다. AppSec은 이러한 기능으로 위험을 충분히 신속하게 제거할 수 없는 기간을 다룹니다. 

제14조는 추측이 아닌 증거를 요구한다 

CRA는 악용되고 있는 취약점과 심각한 사고에 대한 명확한 보고 의무를 도입하고, 통지 및 후속 조치를 위한 구체적인 기한을 명시합니다. 악용되고 있는 취약점이란 악의적인 사용에 대한 확실한 증거가 있는 경우를 말합니다. 심각한 사고에는 악성 코드가 유입되거나 제품 보안에 중대한 영향을 미치는 경우가 포함됩니다. 대부분의 조직은 기존 원격 측정 데이터로는 이러한 요구 사항을 충족할 수 없습니다. 인프라 로그는 요청을 보여주고, 네트워크 모니터링은 트래픽 패턴을 보여줍니다. 하지만 이러한 로그로는 메모리에서 함수가 재정의되었거나 계측을 통해 실행이 변경되었는지 여부를 확인할 수 없습니다. 

일반적인 모바일 뱅킹 애플리케이션을 예로 들면, 클라이언트 측 유효성 검사 함수를 런타임에 재정의하여 일반적으로 차단되는 거래를 진행할 수 있습니다. 애플리케이션은 백엔드의 예상과 정확히 일치하는 요청을 계속 발행합니다. 요청은 구조적으로 유효하고 인증되었으며 정상적인 트래픽과 구별할 수 없습니다. 인프라 또는 네트워크 로그에는 어떠한 이상 징후도 나타나지 않습니다. 애플리케이션 수준의 탐지 기능이 없으면 악용이 발생했다는 증거가 없습니다. Digital.ai 애플리케이션 보안(AppSec)은 공격이 발생하는 시점에 신호를 제공합니다. 디버거가 애플리케이션에 연결되면 이를 감지하고, 메모리가 수정되면 해당 변경 사항을 식별합니다. 실행이 예상 동작과 다를 경우, 애플리케이션은 이를 비정상으로 표시할 수 있습니다. 이러한 과정을 통해 제14조에 필요한 시작점을 마련할 수 있습니다. 

애플리케이션 내부에서 비정상적인 동작이 감지됩니다. 이러한 동작은 알려진 공격 기법이나 취약점과 연관되어 있습니다. 해당 이벤트는 CRA(보안 위험 평가)에서 정의하는 공격 유형과 비교하여 검증됩니다. 검증 결과에 따라 해당 이벤트는 현재 공격 중인 취약점 또는 심각한 사고로 분류됩니다. 이후 24시간 및 72시간 이내에 보고가 이루어집니다. 애플리케이션 수준의 탐지 기능이 없다면 이러한 일련의 과정은 시작되지 않습니다. Digital.ai AppSec은 사고 대응 시스템이나 규제 보고 워크플로를 대체하는 것이 아닙니다. AppSec은 이러한 워크플로에 필요한 증거를 제공합니다. 

지원 기간은 공학적 통제 범위를 넘어 위험을 초래합니다. 

CRA(보안 위험 평가법)는 제조업체가 지원 기간을 정의하고 해당 기간 동안 취약점을 처리하도록 요구하며, 대부분의 경우 최소 5년입니다. 또한 보안 업데이트가 지속적으로 제공되고 취약점이 해당 기간 동안 계속해서 해결되어야 한다고 규정합니다. 그러나 실제로 배포된 소프트웨어는 최신 버전으로 수렴하지 않습니다. 이전 버전은 다양한 기기, 환경 및 사용자 행동에 걸쳐 계속 남아 있습니다. 공격자들은 이러한 이전 버전의 동작이 안정적이고 잘 알려져 있기 때문에 집중적으로 공격합니다. 

Digital.ai 애플리케이션 보안(AppSec)은 해당 버전 내에서 보호 기능이 지속되도록 보장합니다. 애플리케이션이 업데이트되지 않더라도 무결성 검사를 계속 수행하고, 리버스 엔지니어링을 방지하며, 조작 시도를 탐지합니다. 이는 장기간 운영되는 배포 환경에서 알려진 취약점을 악용하는 데 있어 효과를 감소시킵니다. 

Digital.ai AppSec은 지원 기간을 연장하거나 업데이트 배포를 관리하지 않습니다. 지원 기간이 실제 사용 패턴과 겹칠 때 발생하는 위험을 줄여줍니다. 

공급망 위험은 최종 결과물에서만 악용될 수 있다 

CRA(소비자 책임법)는 제조업체가 타사 부품에 대해 상당한 주의를 기울이고 제품 전체의 취약점을 해결하도록 요구합니다. 또한 SBOM(부품 명세서)과 같은 메커니즘을 통해 부품을 식별하고 해당 부품에서 발견된 취약점을 수정하도록 요구합니다. 이 규정은 제품 조립 방식과 관계없이 제품 전체를 단일 책임 단위로 간주합니다. 

Digital.ai 애플리케이션 보안(AppSec)은 바로 이러한 수렴 지점에서 작동합니다. 공격자가 애플리케이션 분석을 통해 취약한 구성 요소를 식별하려고 시도할 경우, 난독화는 코드 구조에 대한 가시성을 제한합니다. 공격이 런타임 시 해당 구성 요소를 조작하는 데 의존하는 경우, 변조 방지 및 런타임 보호 기능은 해당 프로세스를 방해합니다. 이는 공급망 취약점을 완전히 제거하는 것은 아니지만, 배포된 환경에서 취약점을 악용할 가능성을 줄여줍니다. 

Digital.ai AppSec은 종속성을 추적하거나 SBOM(소프트웨어 구성 요소 목록)을 관리하지 않습니다. AppSec은 이러한 종속성으로 인해 위험이 발생할 경우, 애플리케이션이 공격자에게 쉽게 노출되지 않도록 보장합니다. 

경계선은 혼란이 가장 많이 발생하는 지점이다. 

사이버 복원력법은 설계 요구사항, 취약점 처리, 보고, 적합성 평가 및 시장 감시를 포함한 여러 영역을 포괄합니다. 

Digital.ai Application Security 이 도구는 해당 영역 중 하나에서 정밀하게 작동합니다. 런타임 시 애플리케이션 내 보안을 강화하고, 실행 파일을 분석으로부터 보호하며, 조작을 탐지하고, 공격 성공률을 제한합니다. 또한 공격 이벤트를 검증하는 데 사용할 수 있는 신호를 생성합니다.  

이 시스템은 정적 분석을 수행하거나, 종속성 목록을 관리하거나, SBOM을 생성하거나, 릴리스 파이프라인을 조정하거나, 패치를 배포하거나, 적합성 문서를 생성하지 않습니다. 이러한 시스템은 규정 준수 의무를 정의하고 관리합니다. Digital.ai AppSec은 애플리케이션이 악의적인 환경에 노출될 때에도 이러한 의무 사항이 유효하게 유지되도록 보장합니다. 

최종 관점 

사이버 복원력법은 취약점이 존재하고 공격자가 이를 악용할 것이며, 제품은 이러한 상황에서도 안전하게 유지되어야 한다는 전제를 바탕으로 합니다. 이 규정은 설계, 수명주기 관리 및 보고 전반에 걸쳐 요구 사항을 정의하지만, 실제 시행은 런타임 시점에 이루어집니다. 즉, 애플리케이션이 공격자의 손에 들어가 동작을 검사하고 변경하며 취약점을 적극적으로 악용하는 시점에 규정 준수 여부가 결정됩니다. 

Digital.ai Application Security 바로 그 지점에서 작동합니다. 애플리케이션이 분석에 저항하고, 무결성을 유지하며, 악용 시도를 탐지하고, 실제 운영 환경에서 취약점의 영향을 최소화하도록 보장합니다. CRA가 실제로 테스트되는 계층이 바로 이 단계입니다.