CVE(일반적인 취약점 및 노출) 스캔은 소프트웨어 애플리케이션을 보호하는 데 필수적입니다. 그러나 소프트웨어 스택의 복잡성이 증가함에 따라 모든 CVE를 식별하고 해결하는 것이 어려울 수 있습니다. 오늘날 CVE 스캔의 가장 큰 문제 중 하나는 프로덕션 애플리케이션에서 사용되지 않는 패키지에서 취약점이 식별되는 오탐(false positive)이 널리 퍼져 있다는 것입니다.
모든 소프트웨어 패키지의 전체 목록과 해당 패키지에서 발견된 모든 CVE의 전체 목록을 얻었더라도 해당 패키지 중 일부가 애플리케이션과 관련이 없다는 것이 확실하다는 점을 기억하는 것이 중요합니다. CVE는 코드에서 사용되지 않는 함수에 있거나 호출하지도 않는 라이브러리의 일부에 있을 수 있습니다. 패치되지 않은 종속성 목록으로 인해 호출되고 코드에서 전혀 사용되지 않는 임시 종속성에 있을 수 있습니다. CVE가 사용하는 라이브러리의 일부에 있다는 것을 알고 있더라도 CVE가 애플리케이션에서 실제로 악용될 수 있다는 보장은 없습니다. 일부 익스플로잇은 3개 이상의 CVE를 순서대로 조합하고 올바른 스택과 올바른 인프라를 갖춘 등 해커가 사용할 수 있는 극한 조건을 취합니다. 스캔을 통해 얻은 각 CVE를 자세히 살펴봐야 하므로, 다시 돌아오기 전에 경고 피로나 CVE 소진을 방지하기 위해 얻은 CVE 수를 선별하는 것이 얼마나 중요한지 알 수 있습니다. 실제로 애플리케이션의 다음 기능을 구축하는 것입니다.
이 기사에서는 처리해야 하는 전체 CVE 수를 줄이는 것을 목표로 CVE 스캔에서 오탐지를 완화할 수 있는 몇 가지 가능한 솔루션을 제공하겠습니다. 먼저 패키지 식별 문제에 대해 논의한 다음 패키지 파일을 패키지 이름에 매핑하는 데이터베이스를 소개하겠습니다. 또한 오탐지를 유발할 수 있는 범위 지정 및 코드 경로 문제에 대해서도 논의하겠습니다.
먼저 CVE를 식별하는 방법부터 살펴보겠습니다.
미스터리 패키지와 누락된 CVE
Mitre Corporation은 다음과 같은 업무를 담당하는 미국의 비영리 단체입니다. CVE® 프로그램. 프로그램의 임무는 공개적으로 공개된 사이버 보안 취약점을 식별, 정의 및 분류하는 것입니다. 이것이 작동하는 방식은 취약점을 발견한 후 양식을 작성하고, 발견 내용이 확증될 수 있으면 새로운 CVE 식별자가 취약점에 제공되고 공개 CVE 데이터베이스에 추가된다는 것입니다.
CVE가 나열되는 방식을 고려할 때 CVE 스캔의 주요 과제 중 하나는 패키지와 라이브러리를 올바르게 식별하는 것입니다. 누군가 패키지나 라이브러리에서 취약점을 식별하면 익숙한 패키지 이름과 버전과 함께 취약점을 나열합니다. 물론 모든 도구가 동일한 명명 규칙을 사용하는 것은 아니며 패키지 이름에는 기존 글로벌 표준이 없습니다. 알려진 대로 '명명 문제'는 여러 포럼과 싱크 그룹이 오랫동안 공통의 해결책을 찾기 위해 노력해 왔을 정도로 심각합니다. 예를 들면 다음과 같습니다. OWASP가 제안하는 솔루션 문제는 생성과 관련된 것이므로 SBOM. 스캔 도구는 스캔 결과에서 제공하는 패키지 이름에 대해 빌드 또는 컴파일된 아티팩트와 같이 제공되는 소스에 의존하는 경우가 많으며 이러한 소스가 항상 신뢰할 수 있는 것은 아닙니다. 예를 들어, 포장지와 개조품으로 인해 실제 패키지를 식별하기 어려울 수 있습니다. 또한 일부 패키지 파일은 Docker COPY 명령과 같은 설치 프로그램 패키지의 흔적을 남기지 않을 수 있습니다.
이러한 문제를 해결하기 위해 우리는 서기 보안, 패키지 파일을 패키지 이름에 매핑하는 애플리케이션용 데이터베이스를 만드는 것이 좋습니다. 패키지 이름이 달라도 동일한 패키지라면 파일과 파일 해시는 동일합니다. 이렇게 하면 래퍼 및 조정과 관련된 문제를 건너뛰고 해결해야 하는 실제 패키지를 식별할 수 있습니다. 이 접근 방식을 사용하면 CVE 수정 프로세스에서 시간과 노력을 절약할 수 있습니다. 이후 스크라이브 플랫폼 최종 이미지에 포함된 각 패키지와 관련된 파일을 이미 식별하고 있으므로 이러한 데이터베이스를 만드는 것이 다음 논리적 단계입니다. 우리는 CVE 스캔이 CVE에 나열된 이름과 버전이 아닌 패키지에 포함된 실제 파일에 의존할 필요가 있다는 것을 의도하고 있습니다.
당신은 우리 엄마입니까?
Docker 이미지인 최종 빌드를 처리할 때 요즘에는 처음부터 시작하지 않는 것이 일반적인 관행입니다. 설정된 기본 이미지와 같은 견고한 시작점을 통해 개발자는 실행해야 하는 환경 계획을 시작하는 대신 애플리케이션인 빌드 부분에 집중할 수 있습니다. Docker 이미지를 사용할 때의 과제 중 하나는 특히 최종 이미지가 구축되는 상위 이미지(기본 이미지 제외)와 관련하여 출처와 종속성을 이해하는 것입니다.
부모 이미지는 Docker 이미지의 가장 가까운 '살아 있는 친척'을 설명하기 위해 우리가 생각한 개념입니다. 이미지는 별개의 레이어로 구축되므로 Alpine, Debian 또는 Ubuntu와 같은 알려진 기본 이미지를 사용하고 그 위에 바로 애플리케이션 레이어를 구축한다고 가정해 보겠습니다. 이 경우 가장 가까운 '부모'는 해당 기본 이미지가 됩니다. 하지만 내가 일하는 회사가 기본 이미지와 모든 회사 이미지에 필수인 보안 도구 외에 몇 가지 추가 레이어를 포함하는 다른 시작점을 가지고 있다면 어떻게 될까요? 이 경우 내 상위 이미지는 이 회사 템플릿이 되며 이 템플릿이 작성된 기본 이미지도 식별할 수 있습니다.
상위 이미지는 애플리케이션과 해당 종속성에 대한 기반을 제공하므로 소프트웨어 공급망의 중요한 부분입니다. 기본적으로 Docker 이미지에는 상위 이미지 또는 기본 이미지의 원본에 대한 정보가 많이 포함되어 있지 않으므로 무결성 확인, 취약점 이해 및 라이선스 확인이 어렵습니다.
이 문제를 해결하기 위해 Scribe는 다음과 같은 오픈 소스 도구와 서비스를 개발했습니다. 상위 이미지 Docker 이미지의 가장 가까운 스캔 상위 항목을 감지합니다. 이 도구는 주요 위험 감소 요소인 Docker 이미지의 상위 이미지를 식별하는 데 사용할 수 있습니다.
첫째, 기본 이미지를 식별함으로써 해당 이미지의 무결성을 확인하고 변조되거나 손상되지 않았는지 확인할 수 있습니다. 이는 애플리케이션의 보안과 안정성을 유지하는 데 중요합니다.
둘째, 어떤 취약점이 상위 이미지에서 발생하는지, 어떤 취약점이 애플리케이션 계층 자체에서 발생하는지 이해함으로써 취약점의 우선 순위를 지정하고 보다 효과적으로 관리할 수 있습니다. 즉, 기본 이미지 또는 상위 이미지에 연결된 CVE는 애플리케이션 계층의 CVE와 비교할 때 덜 긴급합니다(항상 문제 해결에 대한 책임은 귀하에게 없음).
또한 상위 이미지를 식별함으로써 라이선스를 확인하고 법률 및 내부 정책 요구 사항을 준수하는지 확인할 수 있습니다.
ParentImage 오픈 소스 도구에는 업데이트 가능한 Docker 이미지 스캔 데이터베이스가 포함되어 있습니다. 이를 포크하여 완전히 내부적으로 사용할 수 있지만 사람들이 Docker 이미지를 스캔하여 해당 정보를 데이터베이스에 포함하도록 보내주길 바랍니다. 데이터베이스에 더 많은 이미지를 스캔할수록 도구가 식별할 수 있는 '상위 항목'이 더 많이 포함됩니다. 현재 포함된 데이터베이스에는 개념 증명으로 확립된 모든 기본 이미지의 전체 목록이 있습니다. 오픈 소스 도구이므로 시도해 보는 데 비용이 들지 않습니다. 따라서 Docker 이미지를 사용하는 경우 관련 없는 CVE에 대한 한 가지 이유에 대한 가능한 해결 방법으로 이 도구를 고려하는 것이 좋습니다.
스캔해야 할까요, 아니면 건너뛰어야 할까요?
CVE 스캔의 또 다른 과제는 범위 지정 문제입니다. 범위 지정은 검사된 파일 및 패키지의 위치, 즉 검사에 포함되어야 하는 항목과 무시해도 되는 항목을 나타냅니다. 때로는 애플리케이션의 프로덕션 버전에서 실제로 사용되지 않는 패키지에서 CVE가 발견되는 경우도 있습니다. 예를 들어, 일부 테스트 프레임워크에 대한 간접적인 종속성의 결과로 패키지가 설치될 수 있습니다. 이 문제를 해결하려면 스캐너는 애플리케이션 파일의 범위를 평가하고 사용 중인 간접적인 종속성을 식별해야 합니다.
OWASP(The Open Worldwide Application Security Project) 플러그인에는 범위 지정 문제를 해결하는 데 도움이 될 수 있는 도구의 좋은 예가 있습니다. OWASP 종속성 검사예를 들어, 애플리케이션의 종속성을 분석하고 애플리케이션의 종속성 그래프 컨텍스트에서 CVE를 식별할 수 있습니다. 이를 통해 프로덕션 애플리케이션에서 사용 중인 CVE와 사용하지 않는 CVE를 식별할 수 있습니다.
숫자가 어떻든 여전히 CVE를 해결해야 합니다.
애플리케이션이 해킹, 백도어 및 기타 문제에 취약한 위치를 알려줄 수 있는 다른 도구가 없는 경우에도 CVE 스캔은 잠재적인 문제를 해결하기 위한 매우 기본적인 옵션입니다. 문제는 스캔에서 제시된 CVE가 실제 문제인지 확인할 때까지는 규제 기관, 제3자 및 사용자 모두가 귀하에게 불리하게 사용될 수 있는 위협을 의미한다는 것입니다.
보안과 투명성이라는 이름으로 모든 잠재적인 문제를 검토하고 그것이 문제가 아니거나 애플리케이션과 관련이 없거나 잠재적인 문제이고 패치를 위해 노력하고 있음을 증명해야 합니다. 이러한 CVE 중 다수가 외부(일반적으로 오픈 소스) 패키지에서 애플리케이션으로 유입된다는 사실은 이를 잠재적인 악용으로 식별하더라도 패치를 적용하려면 패키지 관리자의 도움이 여전히 필요할 수 있음을 의미합니다.
이 모든 작업이 각 CVE와 연관되어 있으므로 다음 CVE 스캔에서 가능한 한 작은 숫자를 얻는 것을 선호하는 것은 당연한 일입니다. 이 문서에 설명된 몇 가지 제안 사항을 사용하면 취약점을 해결하는 기념비적인 작업을 좀 더 쉽게 관리할 수 있습니다.
문제를 처리할 수 있는 다른 오픈 소스 또는 무료 도구가 있는 경우 이에 대해 듣고 싶습니다. 댓글로 이에 대해 알려주고 산더미 같은 취약점을 처리하는 방법을 커뮤니티와 공유하세요.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
