취약점 무시로 보안 강화
일반적으로 "취약점을 무시하라"는 진술은 보안 회사에서 듣기를 기대하지 않는 진술입니다. 결국, 취약점은 그 규모에 비해 심각한 보안 침해를 일으키기 때문에 수개월 동안 사후 논평, 분석 및 권장 사항으로 피드를 채웁니다.
그리고 "취약성 무시"라는 개념과 "보안 개선"이라는 개념이 함께 나타나는 것을 보지 못했습니다.
이제 당신은 - 대부분의 조언과 마찬가지로, 이 조언에도 경고와 조건이 따릅니다.
물론 모든 취약점을 무시할 필요는 없지만 지금 당장 안전하게 무시할 수 있는 취약점이 있거나 적어도 비오는 날을 대비해 우선순위를 낮출 수 있는 취약점이 있습니다. 저는 WhiteSource Software 에서 발행 한 2018년 오픈소스 취약점 관리 현황 보고서를 읽다가 이 개념을 우연히 발견했습니다.
매우 흥미로운 통계 외에도 이 논문에서는 오픈소스의 취약성을 비효과적인 것과 효과적인 것의 두 가지 범주로 그룹화할 수 있다는 아이디어를 제시합니다.
WhiteSource 분류의 전제는 일부 취약점은 비효과적이라는 것입니다. 즉, 이러한 취약점은 사용자 정의 코드에서 호출되지 않기 때문에 악용될 수 없습니다. 분석하고 차별화할 수 있는 능력은 보안과 개발자가 효과적인 것으로 간주되는 취약점에 집중할 수 있음을 의미하며, 이를 통해 애플리케이션의 전반적인 보안을 향상시키면서 시간과 노력을 줄일 수 있습니다.
예를 들어, 취약한 기능이 포함된 오픈 소스 구성 요소를 사용하는 사용자 정의 애플리케이션을 생각해 보겠습니다. White Source의 정의에 따르면, 이 예의 취약한 함수는 사용자 지정 애플리케이션에서 호출되지 않으므로 "비효율적"이라고 선언될 수 있습니다. 눈치 빠른 독자라면 취약한 함수가 오픈 소스 구성 요소(또 다른 구성 요소이든 동일한 구성 요소이든)의 함수에 의해 호출 될 수 있고 , 따라서 유효해질 수 있다는 것을 알아차릴 것입니다. 제가 WhiteSource에 이러한 가능성에 대해 물었을 때, 그들은 이 가능성이 고려되고 있다고 언급하며 분류를 확장했습니다. 취약한 코드가 사용자 정의 코드에서 호출되거나 다른 오픈 소스 구성 요소를 통해 간접적으로 호출되는 경우 "효과적"이라는 레이블이 지정됩니다. 반대로, 취약한 기능을 호출하는 직접적 또는 간접적 경로가 없는 경우 해당 기능은 "비효율적"으로 분류됩니다.
WhiteSource의 조사에 따르면 개발자의 96.8%가 오픈소스 구성 요소를 사용하고 있으며, 모든 프로젝트의 7.5%가 취약한 것으로 나타났습니다. 따라서 어떤 취약성에 집중해야 할지 우선순위를 정하는 것은 확실히 큰 도움이 될 것입니다. WhiteSource는 오픈소스 제품의 무려 64%가 비효율적인 취약점만 포함하고 있는 것으로 밝혀졌으며, 이는 안전하게 무시할 수 있다고 주장합니다.
코드에서 취약점이 적극적으로 사용되지 않는다는 이유만으로 취약점을 가볍게 무시해야 한다는 데는 동의하지 않지만, 취약점 관리의 우선순위를 정하는 데 이런 구분을 사용하는 데에는 가치가 있다고 생각합니다. 개발자와 보안 전문가는 적극적으로 사용 되는 취약한 코드에 집중함으로써 애플리케이션의 전반적인 보안을 즉시 개선할 수 있습니다. White Source 보고서에 따르면, 이를 통해 선임 개발자를 더 효과적으로 활용할 수 있는데, 선임 개발자는 주니어 개발자보다 취약점을 해결하는 데 평균적으로 더 많은 시간을 할애합니다.
어떤 종류의 우선순위 지정 방법이 필요합니다. WhiteSource에 따르면 2017년에 보고된 취약점이 약 3,500개에 달했으며, 이는 2016년 대비 60% 증가한 수치입니다. 보고된 3500개의 취약점이 모든 애플리케이션이나 조직에 영향을 미치는 것은 아니지만, 이러한 숫자는 누적된다는 점을 기억해야 합니다. 즉, 3500개는 누적 총계에 추가된 새로운 취약점입니다.
말할 것도 없이, 맞춤형 코드와 오픈 소스 코드에는 많은 취약점이 있습니다. "효과적"인지 "비효과적"인지에 따라 교정의 우선순위를 정하는 것은 다른 요소 외에도 실존적 위협을 기준으로 위험을 평가하는 새로운 보안 전략과 일치합니다. 효과적인 취약성이 존재하지 않으면 실존적 위협은 거의 존재하지 않습니다. 그럼에도 불구하고, 비효율적인 취약점을 무시하는 것은 최선의 장기적 접근 방식이 아닐 수도 있습니다. 결국에는 그러한 취약점이 효과적일 가능성이 있습니다. 기능이 추가되거나 향상됨에 따라 사용자 정의 코드가 변경되거나, 시간이 지남에 따라 오픈 소스 구성 요소가 변경되면 취약한 함수를 호출하는 경로가 열릴 수 있습니다. 이는 취약점을 찾아내기 위한 소스 코드 분석이 최상의 경우 지속적으로 이루어져야 하고, 최악의 경우 최종 빌드 중에 이루어져야 하는 이유 중 하나입니다.
하지만 마감일을 맞추고 개발자의 시간을 효율적으로 사용하기 위해 "효과적이지 않은" 취약점을 대기열 맨 뒤로 밀어 "효과적인" 취약점을 즉시 수정할 수 있도록 하는 것이 개발자가 지금 당장 보안을 개선할 수 있는 더 나은 방법 중 하나일 수 있습니다.