문제 분석

릴리스 상태

Issues Analytics는 엔터프라이즈(Enterprise) 플랜 고객에게만 제공됩니다.

이슈 분석(Issues Analytics)은 90일의 조회 기간(lookback period) 내에서 치명적(critical) 및 높음(high) 심각도 이슈에 대해 사용 가능한 가장 중요한 메트릭의 비교적 최근 보기에 팀이 집중하도록 하는 의견이 반영된(opinionated) 접근 방식을 취합니다. 이러한 정적 필터는 페이지 상단에 표시됩니다.

이슈 분석은 다음 제품에 대한 메트릭에 집중합니다.

• Snyk Open Source

• Snyk Code

• Snyk Container

• Snyk IaC

분석에 포함될 그룹과 조직을 선택할 수 있습니다.

메트릭은 AppSec 성과 프레임워크(AppSec performance framework)의 핵심 요소 내에 구성됩니다. 프로그램의 상태를 신속하게 파악하기 위해서는 메트릭의 현재 상태와 트렌드를 모두 이해하여 기대와 상충되는 이상 징후나 패턴을 식별하는 것이 중요합니다.

이슈 분석은 프로그램의 상태를 빠르게 이해할 수 있도록 각 핵심 요소에 대한 최상위 메트릭과 관련 트렌드를 항상 볼 수 있도록 설계되었습니다. 필요에 따라 각 탭의 더 세부적인 보기로 이동할 수 있습니다. 이러한 보기의 서로 다른 요소와 메트릭은 회사, 사업부, 제품, 팀 및 기타 참여자에게 시기에 따라 더 많거나 적은 관련성이 있을 수 있습니다.

메트릭과 용어에 대한 설명은 이슈 분석 애플리케이션 페이지 곳곳에 있는 툴팁을 사용하십시오.

필요에 따라 그룹이나 조직에 대해 이슈 분석을 수동으로 필터링할 수 있습니다.

이슈 분석의 데이터는 매일 약 13:00에서 14:00 UTC 사이에 업데이트됩니다.

AppSec 성과 프레임워크

AppSec 성과 대시보드는 AppSec 성과 프레임워크를 사용하여 각 핵심 요소에 대한 성과를 보여줍니다.

많은 AppSec 팀은 해결해야 할 가장 심각한 문제를 이해하고 그에 따라 대응하는 것부터 시작합니다. 팀이 성숙해짐에 따라 노출(Exposure), 관리(Manage), 예방(Prevention), 커버리지(Coverage)라는 각 핵심 요소에서 프로그램을 선제적으로 개선할 기회를 찾습니다.

노출 (Exposure)

Exposure 요소는 애플리케이션을 구성하는 자산에 대한 리스크 보기를 나타냅니다. 모니터링되는 자산에 실제 리스크를 제기하는 열린 이슈에 중점을 둡니다.

관리 (Manage)

Manage 요소는 애플리케이션을 구성하는 모니터링되는 자산에 영향을 미치는 이슈를 비즈니스에서 어떻게 관리하는지를 나타냅니다. 기존 리스크를 보는 대신, 모니터링되는 자산에 나타나는 리스크에 대한 해결, 수용 또는 조치 보류를 처리하는 팀의 행동 패턴을 보여줍니다.

예방 (Prevention)

Prevention 요소는 애플리케이션을 구성하는 자산에 예방 가능한 이슈가 유입되는 것을 막기 위해 팀이 도구와 프로세스를 얼마나 효과적으로 최적화하고 있는지에 대한 보기를 나타냅니다.

커버리지 (Coverage)

Coverage 요소는 보안 관점에서 애플리케이션을 구성하는 자산이 얼마나 완전하게 커버되고 있는지에 대한 보기를 나타냅니다.

리스크가 도입된 방식의 구분

리스크에 대한 노출만 평가할 때는 이슈가 제품에 어떻게 도입되었는지에 대해 신경 쓸 필요가 없습니다. 이슈를 검토하거나 감사를 수행할 때, 이슈가 악용될 수 있다면 악용될 수 있다는 점을 인지해야 합니다.

그러나 AppSec 프로그램의 성과를 평가할 때는 공격보다 앞서 나가고 다음 감사나 공격 방어에 대비할 수 있도록 이슈가 어떻게 도입되었는지 이해해야 합니다.

이슈는 다음과 같이 분류됩니다.

기준선 이슈 (Baseline issues)

여기에는 프로젝트 모니터링이 시작된 첫날에 식별된 이슈가 포함됩니다. 기준선 이슈는 Snyk 모니터링이 시작되었을 때 이미 존재했던 리스크에 대한 새로운 가시성을 나타냅니다.

기준선 이슈는 회사가 보안 도구를 사용하기 시작할 때 식별될 수 있지만, 시간이 지나면서 발견될 수도 있습니다. 기준선 이슈는 Snyk에 새로운 사업부를 온보딩할 때, 이전에 온보딩된 팀에서 레거시 코드를 식별할 때 또는 인수의 결과로 식별될 수 있습니다.

노출 관점에서는 기준선 이슈를 다른 이슈와 동일하게 처리해야 하지만, 기준선 이슈의 증가가 비기준선 이슈의 급증만큼의 경고를 일으키지는 않아야 합니다.

모니터링 첫날 이후 프로젝트에서 식별된 모든 이슈는 비기준선(non-baseline)으로 간주되며 다음 카테고리 중 하나에 해당합니다.

예방 가능 이슈 (Preventable issues)

예방 가능 이슈는 개발자가 사용 가능한 시프트 레프트(shift-left) 도구와 프로세스를 더 잘 활용했다면 SDLC 초기에 식별하고 해결할 수 있었던 이슈입니다.

개발자가 Snyk Learn을 활용하거나, IDE 플러그인을 사용하거나, PR 확인을 활성화하거나, CLI에서 로컬로 snyk test를 실행하거나, 빌드를 중단하거나, 프로덕션 이전 단계에서 이슈를 포착하기 위해 사용 가능한 다른 조치를 취함으로써 이슈를 예방할 수 있습니다. Snyk이 이슈를 알고 있다면 테스트로 잡아낼 수 있습니다. 빌드를 중단시키는 기준의 임계값을 높임으로써 예방 가능 이슈가 프로덕션 환경에 유입되는 것을 막을 수 있습니다. 임계값을 critical 이슈만에서 critical 및 high 이슈로 높이거나, Snyk 테스트에 실패한 PR을 엄격하게 승인하지 않음으로써 이를 수행할 수 있습니다.

문제가 Snyk에 알려진 지 적어도 7일 후에 이슈가 감지된 경우 해당 이슈는 예방 가능(Preventable)으로 분류됩니다. 7일 이내에 이슈 도입을 예방할 수 있었을 가능성도 있지만, 이 정의는 코드가 배포 프로세스를 통과하는 데 시간이 더 오래 걸리거나 매주 반복되는 테스트가 있는 시나리오에 대해 약간의 완충 기간을 제공합니다.

다음 예시도 예방 가능한 이슈입니다.

개발자가 개발의 일환으로 취약한 버전의 패키지를 추가합니다. snyk test 명령을 실행하여 이 알려진 이슈를 발견한 강력한 시프트 레프트 문화에도 불구하고 사용 가능한 수정 사항이 없었습니다. 이슈가 알려진 지 오래되었거나 개발자가 해당 패키지 사용 방식에 익숙하지 않다고 느껴서(또는 둘 다), 개발자는 대안을 선택하는 대신 취약한 라이브러리를 사용하기로 선택했습니다.

예방 불가능 이슈 (Non-preventable issues)

예방 불가능 이슈는 개발자가 시프트 레프트(shifting left)를 하지 않은 것과 대조적으로, 새로운 취약점이 게시되거나 새로운 보안 규칙이 생성되는 것과 같은 외부 요인의 결과입니다.

몇 달 또는 몇 년 동안 수정되지 않은 리포지토리가 있을 수 있지만, log4j와 같이 새로 게시된 취약점으로 인해 자산이 이제 취약해질 수 있습니다. 새로 게시된 치명적 또는 높은 심각도의 오픈소스 취약점이 있는 경우, 고위 경영진, 파트너 및 고객의 주의가 필요할 수 있으며, 이 카테고리의 이슈를 식별하고 트렌드를 신속하게 측정할 수 있는 능력이 필요합니다.

이슈가 Snyk에 알려진 지 7일 이내에 감지된 경우 해당 이슈는 예방 불가능(Non-preventable)으로 분류됩니다. 이는 이미 사용 중인 종속성에서의 새로운 취약점이나, 종속성이 프로젝트에 도입된 것과 동일한 기간에 공개된 취약점을 포함할 수 있습니다. 7일 이내에 이슈 도입을 예방할 수 있었을 가능성도 있지만, 이 정의는 코드가 배포 프로세스를 통과하는 데 시간이 더 오래 걸리거나 매주 반복되는 테스트가 있는 시나리오에 대해 약간의 완충 기간을 제공합니다.

기타 신규 이슈 (Other new issues)

현재 Snyk 내에서 모든 이슈를 예방 가능 또는 예방 불가능으로 쉽게 분류할 수 있는 것은 아닙니다. 이러한 결정의 핵심 입력값은 이슈와 문제가 식별된 날짜입니다. 둘 중 하나라도 의심스러운 경우 이슈는 **기타 신규(Other new)**로 분류됩니다.

모든 Snyk Code 및 Snyk IaC 이슈는 기타 신규로 레이블이 지정됩니다. 오픈소스 라이선스 이슈도 기타 신규로 분류됩니다.

예방 가능성 분석 고려 사항

Snyk은 이슈의 예방 가능성을 측정하여 이슈가 예방 가능한지 여부를 자신 있게 구분할 수 있습니다. 그러나 이 메커니즘은 계산 시 몇 가지 가정을 포함합니다.

첫 번째 가정은 기본 취약점이 Snyk에 알려진 지 7일 이내에 감지된 비기준선 이슈는 예방 불가능하다는 것입니다. 이 시나리오에서는 개발자가 로컬이나 파이프라인에서 테스트를 실행하여 이슈를 감지했고 즉시 배포했습니다. 7일 임계값은 이 시나리오를 설명하기 위해 합리적인 유연성을 제공합니다.

두 번째 가정은 SCA 엔진이 스캔에서 취약점을 감지하기 전에 Snyk 취약점 데이터베이스에 먼저 캡처될 수 있다는 것입니다. Snyk은 이러한 변경 사항을 밀접하게 동기화하려고 시도하지만, 일부 경우에는 취약점이 Snyk 취약점 데이터베이스에 게시된 후에 엔진 업데이트가 이루어집니다.