00:00:00이건 정말 심각한 상황입니다. 장난이 아니에요. 지난 몇 시간 동안 아주 힘든 시간을 보냈는데,
00:00:06Axios에 거대한 공급망 공격(supply chain attack)이 발생했기 때문입니다. 맞습니다, 주간 다운로드 수가
00:00:148천만 회가 넘는 그 Axios입니다.
00:00:15자, 가장 먼저 해야 할 일부터 말씀드리죠.
00:00:18여러분이 영향을 받았는지 확인하실 수 있도록 기사 링크를 첨부해 두었습니다.
00:00:23잠시 후에 더 자세한 내용을 공유하겠지만, 이건 중요합니다. 여러분이 피해를
00:00:27입었는지 확인하려면 아래 링크를 따라가서 여러분의 운영체제에 맞는
00:00:32명령어를 실행해야 합니다. macOS, Linux, Windows 모두 영향을 받았습니다.
00:00:37영향을 받았다면 이 명령어들을 실행해야 합니다.
00:00:40특히 이 단계들을 통해 시스템이 해킹된 것으로 확인된다면,
00:00:49시크릿 값을 교체하고, 비밀번호를 변경해야 합니다. 시스템에 있는 모든 자격 증명,
00:00:55API 키 등 시스템의 모든 정보가 도난당했다고 간주해야 합니다.
00:01:00비밀번호가 유출되었다고 생각하고 전부 바꾸세요. API 키도 비활성화하세요. 정말 중요합니다.
00:01:07자, 정확히 무슨 일이 일어난 걸까요?
00:01:09Axios는 아시다시피 매우 인기 있는 JavaScript 라이브러리입니다. 예를 들어 React 앱에서
00:01:17백엔드 API로 HTTP 요청을 보내는 데 사용되는 라이브러리죠.
00:01:22보시다시피 정말 많이 사용되는데, 이 라이브러리에
00:01:28악성 코드가 주입되었습니다.
00:01:29이것은 해당 라이브러리를 사용하는 웹사이트들이 영향을 받았다는 뜻이 아닙니다.
00:01:36대신 그 라이브러리를 설치한 시스템, 즉 여러분의 맥북이나 PC,
00:01:41혹은 웹사이트를 빌드한 VPS가 해킹되었다는 뜻입니다.
00:01:50지난 몇 시간 내에 npm install, bun install, npm update, bun update 등을 실행했다면,
00:01:57영향을 받았을 위험이 매우 큽니다.
00:02:00다시 말씀드리지만, 피해 여부를 확인하기 위해 실행해야 할 체크리스트를 공유해 드렸습니다.
00:02:05그렇다면 이 모든 일이 어떻게 일어났으며, 공급망 공격이란 정확히 무엇일까요?
00:02:10참고로 향후 이런 공격으로부터 자신을 보호하는 방법도 공유해 드리겠습니다.
00:02:15하지만 먼저 어떤 일이 일어났는지, 공급망 공격이 무엇인지 이해해 봅시다.
00:02:20공급망 공격이란 단순히 여러분의 애플리케이션 코드를 직접 겨냥하지 않는 공격입니다.
00:02:24공격자는 여러분의 시스템이나 코드베이스에 직접 침입하려 하지 않습니다.
00:02:31대신 애플리케이션 코드에 의존성(dependencies)이 있고, 그 의존성 또한
00:02:37자체적인 의존성을 가지고 있다는 점을 이용합니다.
00:02:38즉, 이러한 의존성 체인이 존재하는데, 공격은 이 체인을 겨냥하는 것입니다.
00:02:45여러분의 코드보다 상류(upstream)에서 발생하는 것이죠.
00:02:48따라서 이러한 의존성 중 하나에 악성 코드가 주입되는 것인데, 이는 관리자가
00:02:54여러분을 공격하려고 해서가 아닙니다.
00:02:58대신 이번 사례처럼 관리자의 계정이 탈취되고,
00:03:03공격자가 그 계정을 이용해 특정 라이브러리나 패키지에 악성 코드를 주입하면,
00:03:10그 패키지를 사용하는 다른 패키지가 영향을 받고, 여러분의 코드가 다시 그 패키지를
00:03:16사용하게 되거나, 혹은 애플리케이션 코드가 악성 의존성을 직접 가져올 수도 있습니다.
00:03:23어느 쪽이든, 여러분의 의존성 중 하나에 갑자기 악성 코드가 포함되게 됩니다.
00:03:28그리고 npm install 등을 실행하거나 업데이트하는 순간,
00:03:36그 악성 패키지가 여러분의 시스템에 다운로드되고, 시스템에서 악성 코드를 실행할 수 있게 됩니다.
00:03:41보통은 'postinstall' 스크립트의 도움을 받아서 말이죠.
00:03:47혹시 모르시는 분들을 위해 설명하자면, npm에는 스크립트라는 메커니즘이 있습니다.
00:03:56우리 모두 프로젝트에서 개발 서버를 실행하거나, 프로젝트를 빌드하거나,
00:04:01테스트를 실행하는 등의 용도로 사용하고 있죠.
00:04:04그리고 구체적으로 'postinstall' 스크립트라는 것도 있는데, React 앱을 만들 때는
00:04:11직접 사용하지 않을 수도 있지만, 라이브러리들은 라이브러리 설치 직후에
00:04:17시스템에서 특정 코드를 실행하기 위해 이를 사용하곤 합니다. 대개는
00:04:23악의적인 목적이 아니라, 코드를 컴파일하거나 해당 라이브러리에 필요한
00:04:31바이너리를 생성하는 등, 다운로드한 라이브러리를 실제로 사용할 수 있도록
00:04:36시스템을 준비시키는 용도로 사용됩니다.
00:04:40이것이 postinstall 스크립트의 본래 의도입니다.
00:04:42npm install 등을 통해 패키지가 설치된 후 실행되어야 할 코드를 정의할 수 있게 해주는데,
00:04:49공급망 공격에서는 바로 이 점을 악용하는 경우가 많습니다.
00:04:55공격자는 패키지에 악성 코드를 주입하는데, 이것은 본질적으로
00:04:57감염된 패키지가 설치되자마자 자동으로 실행되는 postinstall 스크립트입니다.
00:05:04보통 그 코드는 쉽게 읽을 수 없도록 난독화되어 있습니다.
00:05:10Base64로 인코딩되어 악성 코드를 찾아내는 스캐너의
00:05:14탐지를 피할 수도 있고, 또는 악성 코드가 별도로 다운로드될 수도 있습니다.
00:05:20즉, 이번 Axios 공격 사례처럼 postinstall 스크립트 자체에는
00:05:24악성 코드가 직접 들어있지 않을 수도 있다는 뜻입니다.
00:05:30대신 서버에 접속하여 거기서 코드를 다운로드합니다.
00:05:32이번에 일어난 일이 바로 그것입니다.
00:05:36해당 공격에 대해 정확히 무슨 일이 있었는지에 대한 상세 보고서가 있습니다.
00:05:37자세한 내용을 읽고 싶으시다면 첨부된 내용을 확인해 보세요. 요약하자면,
00:05:41Axios 패키지의 두 버전, 1.14.1과 0.30.4가 감염되었고 해킹당했습니다.
00:05:45결국 공격자가 Axios 패키지 관리자 중 한 명의 계정에 접근 권한을 얻어내어
00:05:57이루어진 일입니다. 그들은 해당 계정을 사용해 postinstall 스크립트가 포함된
00:06:02의존성을 가진 새로운 버전의 Axios 패키지를 배포했습니다.
00:06:08그러니까 Axios 패키지 자체가 postinstall 스크립트를 포함하고 있었던 것이 아니라,
00:06:14공격자가 만든 'plaincryptojs'라는 다른 패키지가 범인이었습니다.
00:06:19이 패키지의 유일한 목적은 악성 코드를 다운로드하고 실행하는
00:06:25postinstall 스크립트를 갖는 것이었습니다.
00:06:31즉, Axios에 'plaincryptojs'를 의존성으로 추가함으로써 Axios 패키지가 감염된 것입니다.
00:06:32그것은 악성 패키지입니다.
00:06:39악성 코드를 다운로드하는 것 외에는 아무런 목적이 없으며, 단지 Axios에 이
00:06:40의존성을 추가하는 것만으로 공격은 사실상 완료되었습니다.
00:06:46이 패키지는 Axios 소스 코드 어디에서도 임포트(import)되지 않습니다.
00:06:52그저 postinstall 스크립트만 가지고 있을 뿐이고, 그게 전부입니다.
00:06:56앞서 말씀드린 대로, Windows와 Linux에서 코드를 다운로드하고 실행하여
00:06:59무엇을 할까요?
00:07:05네, 많은 것들을 훔쳐갑니다.
00:07:06시스템이 영향을 받았다면, 서두에 언급했듯이 자격 증명, API 키, 암호화 화폐 토큰 등
00:07:08모든 중요한 정보들이 postinstall 스크립트에 의해 다운로드된
00:07:14트로이 목마에 의해 수집되고 유출됩니다.
00:07:21그것이 이번 공격의 작동 방식이었습니다.
00:07:22과거의 유사한 공격들도 이런 식이었죠.
00:07:24여기서 흥미로운 점은... 아, 참고로 이 공격은 오늘 자정 직후,
00:07:29정확히 몇 시간 전인 UTC 기준 자정 이후에 시작되었습니다.
00:07:36공격은 몇 시간 동안 지속되었으며, Axios 버전 1.14.1과 0.30.4 모두
00:07:40단 40분, 정확히는 39분 만에 영향을 받았습니다.
00:07:50이것은 매우 치밀하게 계획된 공격이었습니다.
00:07:53공격에 사용된 추가 패키지는 공격 시작 약 18시간 전에
00:07:56이미 생성되어 있었습니다.
00:08:03정말 조직적이고 계획적이었습니다.
00:08:04그런데 의아한 점은 npm에 패키지 관리자들이 사용할 수 있는
00:08:06'신뢰할 수 있는 배포(Trusted Publishing)'라는 메커니즘이 있다는 것입니다.
00:08:14이 기능의 목적은 새로운 버전의 패키지 배포 과정을 명확하게 정의된
00:08:17프로세스로 제한하는 것입니다. 구체적으로는 지원되는
00:08:26CI/CD 제공업체 중 하나를 통해 특정 설정을 거쳐 배포해야 합니다.
00:08:32이렇게 하면 이론적으로는 관리자의 npm 계정 정보가 유출되더라도,
00:08:38공격자가 자신의 머신에서 직접 패키지의 새 버전을 배포할 수 없습니다.
00:08:46반드시 정해진 프로세스를 거쳐야 하기 때문이죠.
00:08:51물론 관리자의 GitHub 계정이 해킹당한다면 악성 버전이
00:08:52GitHub에 푸시될 수 있고, 이것이 배포 워크플로를 트리거하여
00:08:59신뢰할 수 있는 배포 과정을 통해 악성 코드가 배포될 수도 있다고 주장할 수 있습니다.
00:09:06하지만 보안 보고서에 따르면 이번에는 그런 일이 일어나지 않았습니다.
00:09:11Axios 팀은 0.30 브랜치가 아닌 1.x 브랜치에 대해
00:09:16이 신뢰할 수 있는 배포 프로세스를 사용하고 있었기 때문입니다.
00:09:21하지만 보고서에 따르면 Axios GitHub 저장소에는 관련 커밋이나
00:09:26공격 흔적이 전혀 없습니다.
00:09:33즉, 해킹된 Axios 버전이 GitHub으로 푸시된 적이 없다는 뜻입니다.
00:09:40따라서 신뢰할 수 있는 배포 프로세스가 작동했을 리 없습니다.
00:09:44대신 보고서는 공격자가 이 악성 또는 감염된 Axios 버전을 배포하기 위해
00:09:50수명이 긴 기존의 npm 액세스 토큰을 획득했음에 틀림없다고 기술하고 있습니다.
00:09:56해당 릴리스는 npm에만 존재하고 GitHub에는 없었기 때문입니다.
00:10:01이 내용이 틀렸을 수도 있습니다.
00:10:02어쩌면 공격이 GitHub을 통해 이루어졌을지도 모르죠.
00:10:05하지만 만약 보고서 내용이 맞다면, 이론적으로 신뢰할 수 있는 배포 기능이
00:10:11활성화된 상태에서는 이런 방식의 배포가 불가능해야 하므로 어떻게 성공했는지 의문입니다.
00:10:15이것이 npm의 보안 취약점인지 아니면 어떤 문제 때문인지는 확실하지 않습니다.
00:10:20신뢰할 수 있는 배포 기능이 켜져 있어도 기존의 수명이 긴 토큰을
00:10:26여전히 사용할 수 있었던 것일까요?
00:10:27그 부분이 정확히 어떻게 된 것인지는 저도 알아낼 수 없었습니다.
00:10:32그리고 이 공격이 보고된 Axios 라이브러리의 GitHub 이슈
00:10:39스레드가 있습니다.
00:10:40덧붙이자면, 유사한 이슈들이 더 생성되었으나 해킹된 관리자 계정에 의해
00:10:45삭제되기도 했습니다.
00:10:48이 스레드는 살아남았고 결국 공격은 중단되었습니다.
00:10:52피해를 입었던 관리자가 계정 권한을 되찾았기 때문입니다.
00:10:56해당 이슈에서 관리자는 자신들이 신뢰할 수 있는 배포 기능을 사용 중이며,
00:11:03어떻게 이런 일이 발생했는지 명확하지 않다는 글을 올렸습니다.
00:11:07여기 공유된 한 가지 이론이 있습니다.
00:11:09하지만 제가 이해하기로는 이 이론 역시 악성 또는 감염된 버전이
00:11:16GitHub에 푸시되어야 가능한 시나리오인데, 다시 말씀드리지만 모든 게 불투명합니다.
00:11:20분명한 사실은 감염된 버전이 배포되어 npm에 올라왔고,
00:11:25결과적으로 시스템에 다운로드되어 정보를 훔쳐갈 수 있었다는 점입니다.
00:11:29주간 다운로드 수가 8천만 회가 넘는 만큼, 단 몇 시간 만에
00:11:35엄청난 피해가 발생할 수 있습니다.
00:11:37물론 다운로드가 하루 종일 고르게 분산되지는 않겠지만,
00:11:44이는 분명 거대한 숫자이며, 그 몇 시간 동안 수천,
00:11:51수만 대의 시스템이 영향을 받았을 것으로 추정됩니다.
00:11:55물론 이것이 첫 번째 공급망 공격은 아니었습니다.
00:11:59지난 몇 달 동안 여러 건의 공격을 목격했습니다.
00:12:01작년 말에는 'shy hulu' 공격이라는 큰 건이 있었는데, 여러 패키지가
00:12:08npm에서 실행되었으며 비슷한 패턴을 보였습니다. 악성 코드가 주입되어
00:12:16감염된 패키지를 다운로드한 시스템에서 실행되었고, 자격 증명 등이
00:12:21도난당했습니다.
00:12:22그것이 하나의 큰 공격 사례였죠.
00:12:25그리고 불과 며칠 전에는 Python 생태계에서도 유사한 사건이 있었습니다.
00:12:31그러니 JavaScript에만 국한된 문제는 아닙니다. 'lightllm' 패키지가 영향을 받았었죠.
00:12:37하나의 편리한 인터페이스를 통해 여러 AI 제공업체를 쉽게 사용할 수 있게 해주는
00:12:43매우 인기 있는 패키지인데, 이 또한 유사한 공격을 받아 피해를 입었습니다.
00:12:49따라서 당연히 JavaScript만의 문제가 아닙니다.
00:12:52이런 공격이 더 많이 발생하는 데에는 몇 가지 이유가 있다고 생각합니다.
00:12:57이론적으로 이런 종류의 공격은 과거에도 가능했고 실제로 일어났겠지만,
00:13:03분명히 지금 더 빈번해지고 있으며, 여기에는 몇 가지
00:13:08이유가 있다고 봅니다.
00:13:11가장 큰 이유 중 하나는 그 어느 때보다 더 많은 코드가
00:13:17작성되고 생성되고 있는 시점이라는 것입니다.
00:13:19여러 지표를 살펴볼 수 있습니다.
00:13:22예를 들어, 최근 새로 생성되는 GitHub 저장소 수가
00:13:27사상 최고치를 기록했다는 차트를 보았는데, 이는 당연히 AI 덕분입니다.
00:13:31사람들이 프로젝트를 진행하고 코드를 생성하고 있으니까요.
00:13:35과거 어느 때보다 코드 생산량이 많아졌고, 이는 곧 더 많은 프로그램이
00:13:42작성되고 더 많은 코드가 생성되면서 공격 표면(attack surface)이 훨씬 커졌음을 의미합니다.
00:13:47공격 대상이 더 많아진 것이죠.
00:13:48코드를 짜고 패키지를 설치하는 사람들이 더 많아졌습니다.
00:13:52그래서 공격자들에게 그 어느 때보다 매력적인 대상이 되었습니다.
00:13:54과거에 매력적이지 않았다는 것이 아니라, 이제는 공격할 수 있는
00:13:59사람들이 그 어느 때보다 많아졌다는 뜻입니다.
00:14:00그것이 하나의 큰 이유입니다.
00:14:03이런 공격을 실행하는 것이 단순히 더 흥미로워진 것이지만, 그게 전부는 아닙니다.
00:14:07또 다른 이유는 역시 AI와 관련이 있다고 생각합니다. 우선,
00:14:15AI의 도움으로 이런 공격을 실행하는 것이 더 쉬워졌을 것입니다. 왜냐하면
00:14:21악성 코드 또한 AI의 도움으로 생성하고 작성할 수 있기 때문입니다. 따라서 이런
00:14:28공격을 실행하는 데 필요한 기술적 숙련도가 과거보다 더 낮아졌다고 주장할 수 있습니다.
00:14:33물론 다크웹에서 이런 스크립트나 트로이 목마를 살 수도 있었겠지만, 접근성은 더 좋아졌을 겁니다.
00:14:40더 많은 사람이 소프트웨어를 만들고 아이디어를 비즈니스로 전환할 수 있게 된
00:14:46AI의 긍정적인 측면만 있는 것이 아니라, 나쁜 일에도 마찬가지입니다.
00:14:50AI 덕분에 더 많은 사람이 코드와 관련된 나쁜 짓을 할 수 있게 된 것이죠. 그것이 한 가지 이유입니다.
00:14:55또한 패키지나 라이브러리 관리자들이 수많은 풀 리퀘스트(pull request)에
00:15:01압도당하고 있다는 점도 들 수 있습니다.
00:15:02요즘 우리가 겪고 있는 또 다른 큰 문제입니다. 오픈 소스 관리자라면
00:15:07과거 어느 때보다 많은 풀 리퀘스트가 들어오기 때문에, 무엇을
00:15:13병합(merge)할지 세심하게 주의를 기울이지 못할 수도 있습니다.
00:15:14분명히 말씀드리지만, 이번 사건이 그렇다는 건 아닙니다.
00:15:16이번 Axios 공격은 명백히 계정 탈취 사례였지만, 이론적으로는
00:15:22관리자들이 악성 코드나 악성 의존성을 설치하는 코드를
00:15:29무심코 라이브러리에 병합할 가능성도 충분히 있습니다. 단순히 간과했거나,
00:15:34혹은 문제를 잡아내지 못하는 완전 자동화된 코드 리뷰 프로세스 때문일 수도 있죠.
00:15:38그저 AI에만 의존하고 있는 경우 말입니다.
00:15:40다시 말하지만 이번 사례는 아니지만, 미래에 공격자들이 사람들이 코드를
00:15:45제대로 살피지 않는다는 점을 이용해 코드베이스에 악성 코드를 주입할 수도 있습니다.
00:15:51게다가 시스템에서 Claude Code나 OpenClaude 등을 사용하여
00:15:56소프트웨어 작업뿐만 아니라 시스템 전체를 관리하는 등
00:16:01다양한 업무를 수행할 때, 특정 작업을 위해 OpenClaude나 Claude Code,
00:16:09Codex 등이 여러분이 요청한 일을 처리하려고 스크립트를 작성하고
00:16:15코드를 실행하기로 결정할 수 있습니다. 그리고 그들이 생성한 코드가
00:16:20Axios와 같은 의존성에 의존할 수도 있습니다. 따라서 공격 표면이 더 넓어지고 있다는
00:16:24저의 첫 번째 논점으로 다시 돌아가게 되는데, 이는 전통적인 소프트웨어 개발 영역 밖의 이야기입니다.
00:16:30이러한 이유들과 제가 미처 생각하지 못한 다른 많은 이유들로 인해 이런 공격들은
00:16:37더 수익성이 좋아지고 실행하기 쉬워졌으며 흥미로워졌습니다. 그래서 앞으로
00:16:43이런 공격을 더 많이 보게 될 것이라고 확신합니다. 그렇다면 이런 공격을 방지하고
00:16:47자신을 보호하기 위해 무엇을 할 수 있을까요?
00:16:55보안을 강화하기 위해 할 수 있는 한 가지 큰 조치는, 여러분이 진행하는 모든
00:17:02애플리케이션 개발 프로젝트에서 의존성 관리를 위해 npm 대신 pnpm 같은 도구를
00:17:09사용할 때, pnpm-workspace.yaml 파일에 최소 릴리스 기간(minimum release age) 설정을 추가하는 것입니다.
00:17:15Bun도 유사한 기능을 가지고 있습니다. 패키지 매니저로 Bun을 사용 중이라면 bunfig.toml 파일을
00:17:21추가할 수 있고, 거기에도 최소 릴리스 기간 설정이 있습니다. 이것이 무엇을 할까요?
00:17:27간단히 말해, 어떤 방식으로든 패키지를 설치할 때 최소한 그 기간만큼
00:17:34오래된 패키지나 패키지 버전만 설치되도록 보장합니다.
00:17:39따라서 어떤 패키지가 5시간 전에 감염되었더라도, 최소 3일 이상 된
00:17:46버전만 설치한다는 규칙이 있다면 안전할 것입니다. 이것이 핵심 아이디어입니다.
00:17:51안타깝게도 npm 자체에는 아직 이런 기능이 없습니다. 명확히 짚고 넘어가자면,
00:17:56우리는 여전히 npm에 호스팅된 패키지에 대해 이야기하고 있는 것이며, 제가 말하는 것은 패키지 매니저 도구입니다.
00:18:03당연히 npm에서 패키지를 다운로드하기 위해 Bun이나 pnpm을 사용할 수 있으며,
00:18:08npm 대신 이 도구들을 사용한다면 이러한 설정의 이점을 누릴 수 있습니다.
00:18:14이를 통해 추가적인 보안 계층을 확보할 수 있는데, 대개 과거의 공격들은
00:18:20몇 시간 내에 발각되었기 때문입니다. 예를 들어 3일이라는 임계값을 설정해 두면
00:18:25대부분의 공격은 그때쯤이면 발견되어 종료되었을 것입니다. 물론 100% 안전한 것은
00:18:32아닙니다. 공격이 더 오래 지속될 수도 있지만, 분명히 유리한 고지를 점하게 해주며
00:18:39권장할 만한 조치입니다. 더 안전해지려면 Doppler 같은 솔루션을
00:18:44사용하는 것을 고려해야 합니다. 광고는 아닙니다. 이건 하나의 예시일 뿐이고 대안은 많습니다.
00:18:49사실 저도 직접 대안을 만들어 사용하고 있는데, 이는 시크릿(secrets)을
00:18:55관리하는 서비스나 도구들입니다. OpenAI API 키 같은 것을 .env 파일에
00:19:02저장할 수도 있겠지만, Doppler 같은 서비스를 통해 그들의 서버에 암호화하여 저장하거나
00:19:08본인 소유의 VPS에 셀프 호스팅하여 저장하는 것이 더 낫습니다. 그리고 필요할 때
00:19:13애플리케이션 환경 변수에 주입하여 사용하도록 합니다. 이렇게 하면
00:19:20시스템에 침투한 트로이 목마가 모든 .env 파일을 긁어모아 정보를 추출하려 해도
00:19:25그 안에서 아무런 비밀 정보도 찾지 못하게 됩니다. 그것이 아이디어입니다.
00:19:32즉, 시스템의 텍스트 파일(.env 파일도 결국 텍스트 파일일 뿐이니까요)에
00:19:36비밀 정보를 저장하지 않고 다른 곳에 암호화하여 보관하는 것을 반드시 고려해 보세요.
00:19:40여러 솔루션이 있으니 한 번 검토해 보시기 바랍니다.
00:19:45보안을 더욱 강화하려면 개발 환경을 아예 외부로 분리하여
00:19:50여러분의 맥북이나 PC가 아닌, SSH 등으로 연결하는 VPS나 Mac mini,
00:19:56혹은 Docker 컨테이너에서 구축하는 것도 방법입니다. 그렇게 하면
00:20:02악성 코드가 실행되더라도 해당 Docker 컨테이너나 VPS에만
00:20:07영향을 미치고 전체 시스템에는 미치지 않게 됩니다. 시스템 비밀번호 등을
00:20:13전부 털어갈 수 없게 되는 것이죠. 피해 범위를 좁힐 수 있습니다.
00:20:21이런 공격은 앞으로도 계속될 것입니다. 분명 패키지 배포의
00:20:27보안을 강화하기 위한 더 좋은 메커니즘이 나오겠지만, 이런 공격이
00:20:33절대 일어날 수 없다는 100% 보장은 결코 있을 수 없습니다. 따라서 패키지 사용자로서
00:20:39시스템을 안전하게 지키고 다중 방어 계층을 구축해야 합니다. 감염된
00:20:45패키지 버전을 다운로드할 확률을 낮추고, 만약 그렇게 되더라도 피해 범위를 최소화해야 합니다.
00:20:50이와 관련된 더 자세한 내용은 제 다른 채널인 Academy 채널의 향후 영상에서 공유하겠습니다.
00:20:55모두 안전에 유의하시고, 이번 공격의 영향을 받았는지 꼭 확인해 보세요. 앞서 말씀드렸듯 정말 힘든 몇 시간이었습니다.