Koa.js 무적 분석 업데이트

Nov 26 2022

얼마 전인 2018년에 Koa.js에 영향을 준 취약점에 대해 글을 쓴 적이 있습니다.

얼마 전인 2018년에 Koa.js 에 영향을 미친 취약점에 대해 글을 쓴 적이 있습니다. 날짜가 2022년인데 2018년부터 문제를 처리해야 하고 최신 버전의 Koa를 사용하고 있어 답답했습니다. 4년이 지났습니다. 오랜만입니다. 확실히 문제는 더 이상 존재하지 않습니다!? 그리고 그것은 동시에 존재하지 않았습니다. 그것은 내가 틀렸으면서 동시에 옳았다는 것을 의미합니다. 따라서 다음은 이전 게시물에 대한 업데이트로 방법을 알려줍니다.

Sonatype과 Dependency Track이 특정한 경우에 버전 정보로 작동하지 않는다고 잘못 고발했습니다.
취약점에 대해 동시에 옳고 그름을 말할 수 있습니다.

OSS 인덱스에는 버전 정보가 있습니다.

내 이전 게시물을 읽었다면 이 문제가 나에게 영향을 미치지 않는다는 결론을 내렸음을 기억할 것입니다. 좋은 소식은 내가 옳았다는 것입니다. 나쁜 소식은 제가 Sonatype이 OSS Index for Dependency Track에서 제공한 데이터에 버전 번호가 없다고 잘못 고발했다는 것입니다. 그들은 정보를 가지고 있는 것으로 밝혀졌습니다. 내가 예상했던 곳에 보이지 않았을뿐입니다. 2022년 11월 22일에 찍은 아래 스크린샷을 참조하십시오.

누락된 영향을 받는 버전에 대한 정보

DT(Dependency Track)가 위 페이지에 표시된 것과 정확하게 작동하지 않을 가능성이 높지만 DT가 OSS 인덱스에서 가져오는 데이터가 어떻게 생겼는지 확인하는 데 신경 쓰지 않았습니다. DT는 내가 더 많은 것을 배울 수 있는 OSS 인덱스에 대한 링크를 보여주었습니다. 이 페이지를 클릭하고 방문했습니다.
오늘 Sonatype에서 버전 번호를 사용할 수 있다는 사실을 알게 되었습니다. 나는 다른 곳을 찾아야합니다. 실제로 계정에 로그인하고 Koa를 검색하거나 위 스크린샷에서 "koa 세부 정보 보기" 버튼을 클릭하면 찾을 수 있습니다. 아래 스크린샷을 참조하십시오.

버전별 Koa 및 기본 취약점 카운터

그래서 나는 틀렸다. Sonatype은 데이터베이스에 정보를 가지고 있습니다. 그렇다면 문제는 프레젠테이션 계층에 있습니다. 필요한 경우 보고 확인할 수 있도록 취약점이 실제로 논의되는 페이지에 영향을 받는 버전이 나열되어 있으면 더 좋을 것입니다.

Sonatype OSS Index에 버전 정보가 없다고 잘못 고발했습니다. 또한 버전 정보를 사용할 수 없는 경우 종속성 이름에 따라 순전히 보고할 용의가 있다고 종속성 추적을 잘못 고발했습니다. (후자가 참인지 거짓인지는 아직 확인해야하므로 확인하지 않았습니다.)

아직 포기하지 마세요! 논의할 더 흥미로운 사항은 실제 취약성과 OSS 인덱스의 취약성 보고서에 대한 예정된 변경 사항입니다. 취약점부터 시작하겠습니다.

교차 사이트 스크립팅

Sonatype은 아래의 사고 과정을 기반으로 XSS를 Koa에 귀속시켰습니다.

Koa는 Koa를 사용하는 개발자가 아니라 HTML 응답에 URL을 작성하는 엔터티입니다.

개발자가 공개 리디렉션을 방지하기 위해 허용 목록에 대해 제공된 URL의 유효성을 검사할 것이라고 기대하는 것은 확실히 합리적입니다. Koa는 어떤 URL을 허용할지 여부를 알 수 없기 때문입니다. 그러나 개발자로서 나는 redirect() 메서드에 전달하는 URL에 대해 XSS 삭제를 수행하는 것에 대해 걱정할 필요가 없다고 생각합니다.

Koa는 XSS를 방지하기 위한 코드를 이미 가지고 있기 때문에 이 맥락에서 XSS에 신경을 쓰는 것 같습니다. HTML에 작성할 때 URL을 인코딩하는 HTML 엔터티입니다.

어느 정도 동의합니다. 예를 들어 다음과 같은 내용에 동의하지 않습니다.

redirect() 메서드에 전달하는 URL에 대해 XSS 삭제를 수행하는 것에 대해 걱정할 필요가 없다고 생각합니다.

귀하(개발자)가 제공한 리디렉션 방법에 유효하고 안전한 URL을 전달하면 XSS에 대해 걱정할 필요가 없습니다(분명히). 사용자가 제공한 데이터의 전부 또는 일부를 전달하는 경우 개발자든 보안 전문가든 항상 걱정해야 할 사항입니다. 그래도 Koa가 개발자에게 도움이 될 것이라고 기대하는 것은 무리가 아닙니다.

내가 어디에서 왔는지 이해하는 데 도움이 되는 훌륭한 예를 들어 보겠습니다. 아래 예에서는 사용자가 제공한 데이터를 응답 본문의 브라우저로 다시 전달합니다. 유효성 검사, 삭제 또는 인코딩 없이 이 작업을 수행합니다.

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.body = ctx.query.payload;
});

app.listen(4444);

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=<img%20src=x%20onerror=alert(1)> HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 28
< Date: Wed, 23 Nov 2022 10:59:17 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
<img src=x onerror=alert(1)>%

응답 본문에서 브라우저에 무엇을 어떻게 전달하는지 생각하십시오.
응답에 대한 Content-Type 헤더의 값을 고려하십시오(명시적으로 제어하는 것이 가장 좋습니다!).
기본적으로 Koa는 에 전달된 값을 기반으로 Content-Type 헤더의 값을 자동으로 조정합니다 ctx.body. (예를 들어 를 전달하고 aaa어떻게 변경되는지 확인하십시오.)

위의 ctx.body"XSS" 예를 고려하면 ctx.redirect(). Sonatype을 다시 인용합니다.

Koa는 이미 코드가 있으므로 이 맥락에서 XSS에 관심을 갖는 것 같습니다.

이것은 Koa가 이 맥락에서 XSS에 대해 신경 쓰지 않았다면, 마찬가지로 Koa가 XSS에 대해 신경 쓰지 않았거나 신경 쓰지 않아야 한다는 것을 의미합니까? ctx.body아무도 XSS 취약점으로 표시하지 않았을 것입니까? 꽤 웃기다. 여기 와 여기 에 기록된 Formidable 에 대한 이전 분석 과 몇 가지 유사점 을 발견 했습니다 .

지금까지 말한 대로 XSS는 우연히 거기에 있습니다. 동시에는 아닙니다. 어떻게 가능합니까? 단순한! 거기에 있지만 다음과 같은 경우가 아니면 악용할 수 없습니다.

피해자가 오래된 웹 브라우저를 사용하고, 그리고
ctx.redirect()Koa의 , AND 를 사용하여 개발자가 구현한 개방형 리디렉션이 있습니다.
개발자는 모든 사용자 제공 데이터를 완전히 신뢰하고 그대로 전달합니다.ctx.redirect()

Sonatype 보고서 페이지에는 오늘의 스크린샷에서 볼 수 있듯이 “Cross-Site Scripting으로 이어지는 Open redirect”라고 되어 있습니다. 이전 게시물에서 "오픈 리디렉션" 부분에 대해 질문했습니다.

우선, 열린 리디렉션이 없었습니다. 열어야만 열리는데 두 PoC(원본과 내 것)의 차이가 이를 명확하게 보여줍니다.

Sonatype은 또한 Koa가 열린 리디렉션을 방지할 책임이 없다는 데 동의합니다. 그들의 관심사, 나의 관심사 및 다른 모든 사람들의 주요 관심사는 XSS였습니다. 오픈 리다이렉트를 참여시키는 것은 혼란스러웠습니다. 동시에 나중에 보게 되겠지만 기술적으로 무리한 것은 아닙니다. (취약점 점수에도 영향을 미칩니다.)

앞에서 언급했듯이 Koa의 동작을 성공적으로 악용하려면 개방형 리디렉션이 필요합니다. 하지만:

Koa는 열린 리디렉션을 방지할 책임이 없습니다(이전에 결론을 내림).
Koa는 ctx.redirect()개발자의 말 없이는 실행되지 않습니다.
Koa는 개발자에게 리디렉션을 사용하도록 강요하지 않습니다.

따라서 또 다른 보호 계층인 사용 사례가 있습니다. 개발자가 브라우저가 리디렉션되는 위치에 대한 제어를 원하지 않을 가능성은 얼마나 됩니까? 매우 가능성이 낮습니다. ctx.redirect()이는 개발자가 다른 문자열에 추가된 사용자 제어 데이터를 전달할 가능성이 높다는 것을 의미 합니다. 따라서 아래에 표시된 예와 유사한 상황이 발생할 가능성이 가장 높습니다.

ctx.redirect(`http://website.example.org/search?q=${userInput}`);
ctx.redirect(`/search?topic=${userInput}`);

취약점 점수

이전 섹션의 끝에서 설명한 것처럼 버그를 악용할 수 있으려면 세 가지 조건이 충족되어야 합니다.

사용되는 브라우저 버전은 최종 사용자에게 달려 있습니다.
리디렉션 방법의 사용 및 사용 방법은 개발자에게 달려 있습니다.

또한 강조해야 할 점은 안전하지 않은 방식으로 리디렉션 방법을 사용하는 것이 공격 벡터라는 것입니다. 성공적인 악용을 위해서는 공격 벡터가 필요합니다. Koa는 공격 벡터를 제공하지 않습니다. 개발자가 합니다.

이를 NIST에서 제공한 "소프트웨어 취약성"의 정의와 연관시켜 보겠습니다.

https://csrc.nist.gov/glossary/term/software_vulnerability

제가 강조하고 싶은 부분은 "악용될 수 있다"입니다. Koa를 소프트웨어 라이브러리로 사용하십시오. 필요한 공격 벡터를 먼저 생성하지 않고 악용할 수 있습니까? 아니요. 따라서 소프트웨어 라이브러리인 Koa의 관점에서 보면 공격 벡터가 제시되지 않습니다. 그것 없이는 착취가 불가능합니다. 정의를 엄격하게 해석하면(저도 그렇게 합니다) Koa의 행동을 취약점이라고 부를 수 없습니다.
공격 벡터 없이 CVSS 점수를 계산해 보겠습니다.

공격 벡터 없이 CVSS 점수 계산

공격 벡터가 없으면 점수가 없습니다. 이것이 NIST에서 제공한 소프트웨어 취약성의 정의와 일치한다고 말하고 싶습니다.
공격 벡터가 존재하는 가상의 시나리오를 실험하고 만들어 봅시다.

가상의 공격 벡터

가상의 공격 벡터 외에 여기에는 여전히 몇 가지 문제가 있습니다. 악용에 성공하려면 이전 브라우저가 필요하기 때문에 공격 복잡도는 높음으로 설정되었습니다. 공격자는 피해자가 이전 브라우저를 다운로드하고 설치하도록 유도해야 합니다.
그런 의미에서 사용자 상호 작용 기본 메트릭이 실제로는 그렇지 않더라도 사용자 상호 작용이 필요합니다. 이 시나리오에서 XSS를 악용하는 데 사용자 상호 작용이 필요한지 여부는 Koa가 아니라 웹 응용 프로그램이 리디렉션을 사용하는 방법에 따라 다릅니다. 또한 언급할 가치가 있는 것은 주입된 JavaScript가 처음에 HTML 응답의 링크를 클릭하는 사용자 상호 작용이 필요했기 때문에 자체적으로 실행되지 않는다는 것입니다.

그렇다면 이에 대한 취약성 점수를 강제로 적용하려면 어떻게 해야 할까요? 우리는 무언가를 선택해야 합니다. 당신이 원하는 대로 최악의 상황을 가정하는 소망적 사고. 한 가지 확실한 것은 애초에 해서는 안 될 계산을 하고 있고 그 결과가 현실과 너무 동떨어져 있어 단어조차 찾을 수 없다는 점이다.

다음으로 중요한 것은 영향 지표입니다. 웹 애플리케이션이 어떤 영향을 미치는지 알아야 합니다. 그러나 우리는 웹 애플리케이션에 대한 취약성 점수를 계산하고 있지 않습니다. 컨텍스트를 고려할 때 이 XSS는 Koa에 전혀 영향을 미치지 않습니다. Koa는 자체적으로 기밀 정보를 취급하거나 처리하지 않습니다. 버그는 가용성이나 무결성에 영향을 미치지 않습니다. 공격 벡터를 강제로 계산에 넣은 후에도 최종 점수는 0.0입니다 .

그래서 문제는 우리가 사실을 보도하느냐, 허구를 보도하느냐입니다.

Sonatype은 CVSSv3.1과 함께 2019년에 출시된 Scoring Vulnerabilities in Software Libraries에 대한 공식 지침에 주목했습니다 . 나는 그것에 대해 몰랐다는 것을 인정합니다. 그것은 좋고 나쁩니다. 호언 장담하는 게시물이 나왔을 것이기 때문에 좋았고, 더 일찍 봤더라면 올바른 방법이 아니라는 것을 설명하기 위해 많은 노력을 기울이기 전에 모든 희망을 잃었을 것입니다. 그렇다면 공식 지침은 무엇을 말합니까?

라이브러리에 있는 취약점의 영향을 점수화할 때 … 분석가는 합리적인 최악의 구현 시나리오에 대해 점수를 매겨야 합니다. 가능한 경우 CVSS 정보는 이러한 가정을 자세히 설명해야 합니다.

따라서 대답은 취약성 점수가 허구를 기반으로 한다는 것입니다.

또한 " 합리적인 최악의 구현 시나리오"란 무엇입니까? Koa를 사용한 많은 프로젝트를 분석하고 대부분의 개발자가 Koa의 ctx.redirect()방법을 사용하여 개방형 리디렉션을 구현한 것을 발견했다면 최악의 상황을 가정하는 것이 합리적일 수 있습니다. GitHub 의 JavaScript 프로젝트에서 빠른 코드 검색 을 수행했습니다. ctx.redirect(16,827개의 코드 결과를 얻었습니다. 검색 context.redirect(결과 15,751개의 코드 결과를 받았습니다. 분석할 코드 결과는 32,578개입니다. 이들 중 일부는 Koa, 일부는 Express를 사용하고 일부는 다른 것을 사용할 수 있습니다. (물론 컨텍스트는 ctx또는 가 아닌 어떤 이름으로도 호출 context할 수 있으므로 살펴봐야 할 코드가 더 많을 수 있습니다.)

문제는 사용자가 제공한 데이터를 너무 일반적으로 리디렉션하기 위해 두뇌 없이 전달하는 것입니까? 검색 기준과 일치하는 모든 프로젝트를 확인하는 작은 스크립트를 작성하여 분석에 반자동 접근 방식을 취했습니다. 안타깝게도 GitHub가 추가 요청을 거부했기 때문에 처음 1,000개의 히트를 넘길 수 없었습니다.

{
    "message":"Only the first 1000 search results are available",
    "documentation_url":"https://docs.github.com/v3/search/"
}

내가 본 것과 다음 섹션("오래된 웹 브라우저")에서 논의할 내용을 고려하면 최악의 구현을 가정하는 것이 합리적이라고 생각하지 않습니다. 이 특별한 경우에는 아닙니다.

공식 지침에는 다음과 같이 명시되어 있습니다.

영향을 받는 라이브러리를 사용하여 특정 구현의 취약성에 점수를 매길 때 해당 특정 구현에 대해 점수를 다시 계산해야 합니다.

이것은 합리적이며 상황의 공상 과학 측면을 어느 정도 완화합니다. 이것이 우리의 경우 취약성 점수가 9.8인 이 Koa 문제가 결국 0.0이 된 방법입니다.

좋은 점은 Sonatype이 9.8의 취약성 점수가 불합리하다는 데 동의하고 기꺼이 낮추려는 것입니다. 나는 그것에 감사하며 아마도 다른 많은 사람들도 그럴 것입니다.

또한 Sonatype은 시스템에 문제를 추가할 때 고객이 이 잠재적으로 예상치 못한 상황에 대해 알고 있다면 최선일 것이라고 믿었다고 말했습니다. 그들은 "우리가 본 것을 무시하고 잠재적으로 부정적인 결과를 낳는 것보다 경고하는 것이 낫다"고 말했습니다. 그리고 물론 그들은 옳았습니다.

보안 문제를 전달해야 하는지 여부에 대해 질문한 적이 없습니다. 예, 보안 문제는 가시화되어야 합니다. 제가 우려하는 것은 이러한 문제가 전달되는 방식입니다.

어떤 것을 취약성이라고 부르는 것이 적절합니까, 아니면 보안 약점 또는 안전하지 않은 기본 동작 등이라고 부르는 것이 더 적절합니까?
할당된 취약성 점수가 합리적입니까?
충분한 세부 정보와 컨텍스트가 제공됩니까?

이제 이전 웹 브라우저에 대해 조금 이야기해 보겠습니다.

오래된 웹 브라우저

Sonatype의 좋은 사람들이 없었다면 아마도 다시는 오래된 웹 브라우저에 대해 생각하지 않았을 것입니다.

앞으로도 오래된 브라우저는 계속 고려하지 않겠습니다. 우선, 명심해야 할 것이 너무 많습니다. 오래된 웹 브라우저에 대해 걱정할 수 없습니다. 둘째, 얼마나 오래된 웹 브라우저입니까 ( 유머 감각이 없으면 링크를 클릭하지 마십시오! )? "오래된"은 실제로 무엇을 의미합니까? 1년 정도 된 브라우저를 사용하는 사람이 있다면 이미 XSS보다 훨씬 더 큰 문제 가 있을 가능성이 높습니다.

그래도 파헤쳐 보니 다음과 같습니다.

2016년(!)의 Google Chrome 48.0.2564.109 (64비트)는 응답 본문조차 표시하지 않았습니다. 2018년에 코아 문제가 발견되었으니 2016년까지 거슬러 올라가도 충분할 줄 알았는데, 아니었습니다.
2011년의 Firefox 4.0은 응답 본문을 표시했지만 사용자가 JavaScript 페이로드를 실행하려면 링크를 클릭해야 했습니다. (물론 링크입니다!)
Koa XSS 문제가 보고되기 1년 전인 2017년부터 Firefox 52.0은 이미 JavaScript 페이로드와 함께 응답 본문을 표시하지 않았습니다. Firefox에서 "네트워크 프로토콜 위반"으로 인해 "손상된 콘텐츠 오류"라는 오류가 발생했습니다.

Koa 0.0.1은 2013년에 출시되었으므로 이 문제가 악용될 수 있는 몇 년이 있었습니다. 현재로서는 2018년 Koa 2.5.0까지 이 문제(여전히 9.8점은 아님)를 표시하는 것이 허용될 수 있습니다. 그러나 그 이후에는 1.0 이상을 정당화하는 것은 없습니다.

파헤치는 동안 Wikipedia 에서 흥미로운 것을 발견 했습니다. 인용하겠습니다.

Firefox 15는 2012년 8월 28일에 출시되었습니다. Firefox 15는 자동 업데이트, 사용자에게 알리지 않고 Firefox를 최신 버전으로 업데이트하는 자동 업데이트, [65] 웹 브라우저 Google Chrome 및 Internet Explorer 8 이상이 가지고 있는 기능을 도입했습니다. 이미 구현

따라서 모든 주요 웹 브라우저에는 Koa의 첫 번째 버전이 출시되기 전에 자동 업데이트 기능이 있었습니다. 즉, 대부분의 사용자가 최신 웹 브라우저를 사용하고 있었을 가능성이 있습니다. "빅뱅" 당시의 상태를 보자: 2013년.

Firefox 15 : 응답 본문이 사용자에게 표시되지 않았음을 의미하는 "손상된 콘텐츠 오류"라는 오류를 반환했습니다.
Chrome 24.0.1312(WebKit 537.17) : 응답 본문이 표시되지 않았습니다. 개발자 도구의 네트워크 탭을 보는 동안 보이는 것이 거의 없었기 때문에 처음에 브라우저가 요청을 수행하는지 확인하기 위해 Wireshark를 실행해야 했습니다. Wireshark에서 Chrome이 내 PoC 서비스에 접근하여 JavaScript 페이로드로 응답을 받은 것을 볼 수 있습니다. 응답 본문을 렌더링하지 않았습니다. 더 좋은 점은 아무 일도 일어나지 않았다는 것입니다.
Internet Explorer 11(11.0.9600.19180) : Wireshark를 사용하여 확인한 내 PoC 서비스에서 응답을 가져왔습니다. 사용자에게 응답 본문을 표시하지 않았습니다. "이 페이지는 표시할 수 없습니다."라는 기본 제공 오류 페이지와 함께 반환되었습니다.

위의 조사를 마친 후 잠시 Sonatype의 인용문으로 돌아가 보겠습니다.

이 진술은 정확하지만 Koa의 첫 번째 버전이 출시될 때까지 주요 브라우저 중 어느 것도 악용을 허용하지 않았다는 사실은 인용된 문장이 제안하려는 것과 다른 흥미로운 것을 제안합니다. Koa 개발자가 어떻게 생각했는지 정확히 알 수 없기 때문에 추측을 작성하려고합니다. 개발자가 최신 웹 브라우저를 사용하여 문제의 동작을 테스트했다고 쉽게 상상할 수 있습니다. 그들은 HTML 인코딩이 적합하다는 것을 알았을 것 href입니다.a꼬리표. 이것은 심각한 질문을 제기합니다. 지난 5년 동안 소프트웨어 개발 측면에서 더 많은 시간을 보냈던 저에게도 적용됩니다. 개발자로서 백엔드 측면을 위한 새로운 웹 기술을 만들려고 한다면 오래된 웹 브라우저에 신경을 써야 할까요? 그리고 해야 한다면, 오래된 웹 브라우저를 고려해야 하는 시점에 대한 보안 커뮤니티의 공식 권장 사항은 무엇입니까? 최종 사용자를 위한 보안 모범 사례는 브라우저를 최신 상태로 유지하는 것이며 자동 업데이트 기능도 이를 지원한다는 사실을 고려해야 하지 않을까요? 또한 개발자가 이전 브라우저를 염두에 두고 테스트하기를 기대한다면 보안 전문가도 똑같이 "오래된 브라우저"를 언급하는 대신 특정 문제에 기여하는 모든 웹 브라우저와 해당 버전의 이름을 지정할 수 없을까요? "? 공정할 뿐입니다.

한 가지 확실한 것은 몇 년 전부터 걱정할 것이 없다는 것입니다.

예정된 변경 사항

다음은 이 문제와 관련하여 Sonatype에서 구현할 예정인 업데이트 목록입니다.

오해를 없애기 위한 요약/제목 라인 업데이트(이미 발생)
취약점 점수를 4.7로 낮추기(이미 발생)
사용자가 이전 브라우저를 실행하는 경우에만 취약점을 악용할 수 있음을 언급

보고 싶은 추가 변경 사항

이전 섹션에서 언급한 변경 사항 외에도 몇 가지 사항을 더 개선할 수 있습니다. 이것들은:

특히 2018년 이후에 출시된 Koa 버전의 경우 취약성 점수를 추가로 줄입니다.
"이전 브라우저"를 언급할 때 적어도 주요 웹 브라우저의 버전 번호와 보고서에 포함된 릴리스 날짜를 포함합니다. 이것은 "영향을 받는 라이브러리를 사용하여 주어진 구현에서 취약점 점수를 매길" 때 누구에게나 상당한 도움이 될 것입니다. 예를 들어 사용자가 2011년부터 브라우저를 사용해야 하는 경우 1초 이내에 SCA에서 해당 문제를 "영향 없음"으로 표시했을 것입니다. 많은 시간이 절약됩니다.
영향을 받는 Koa 버전은 취약점 페이지 에 나열됩니다 .

그건 그렇고, Sonatype은 예를 들어 애플리케이션이 보고된 취약점의 영향을 받는지 확인하기 위해 코드 수준에서 실제 검사를 수행하는 멋진 검사 기능이 있다고 언급했습니다. 그럴듯하게 들립니다. 그리고 라이브러리에 대한 취약성 점수가 계산되는 방식의 공상과학적인 특성을 고려할 때 이러한 종류의 검사는 엔지니어링 팀의 부하를 줄이기 위해 필수입니다. 특히 상황이 이와 같이 계속되는 경우 더욱 그렇습니다.