이슈 - 분석
이슈 분석은 중요하고 심각한 문제들에 대한 가장 중요한 지표들에 대한 비교적 최근 90일 데이터를 중점적으로 살펴보도록 미리 설정된 방식으로 접근합니다. 이러한 정적 필터는 페이지의 상단에 표시됩니다.
이슈 분석은 다음 제품에 대한 지표에 집중합니다:
Snyk Open Source
Snyk Code
Snyk Container
Snyk IaC
분석에 포함될 그룹 및 조직을 선택할 수 있습니다.
지표는 AppSec 성능 프레임워크의 열에 따라 정리됩니다. 현재 지표와 트렌드를 이해하여 예상과 다른 이상 현상 또는 패턴을 식별하는 것이 중요합니다.
이슈 분석은 프로그램 상태를 빠르게 이해할 수 있도록 각 열에 대한 최상위 지표와 그와 관련된 트렌드를 항상 표시하도록 설계되었습니다. 필요에 따라 각 탭의 보다 상세한 보기로 이동할 수 있습니다. 이러한 보기의 다른 열과 지표는 다른 회사, 비즈니스 단위, 제품, 팀 및 기타 참가자에게 다른 시기에 더 또는 덜 관련할 수 있습니다.
이슈 분석 애플리케이션 페이지 전반에 툴팁을 사용하여 지표 및 용어에 대한 설명을 확인할 수 있습니다.
그룹이나 조직에 대한 이슈 분석을 수동으로 필터링할 수 있습니다.
AppSec 성능 프레임워크
AppSec 성능 대시보드는 AppSec 성능 프레임워크를 사용하여 각 열에 대한 성능을 표시합니다.
많은 AppSec 팀은 먼저 해결해야 할 가장 심각한 문제를 이해하려고 노력하고 그에 맞게 반응합니다. 팀이 성숙해지면 각 열에서 프로그램을 선행적으로 개선할 수 있는 기회를 찾습니다: 노출, 관리, 예방 및 커버리지.
노출
노출 열은 애플리케이션을 구성하는 자산에 대한 위험을 나타냅니다. 주의는 모니터링 중인 자산에 실제 위험을 제공하는 열린 이슈에 집중됩니다.
관리
관리 열은 앱을 구성하는 모니터링 중인 자산에 영향을 미치는 문제를 비즈니스가 어떻게 관리하는지 나타냅니다. 기존 위험을 살펴보는 대신, 이는 팀이 모니터링 중인 자산에서 나타나는 위험에 대한 해결, 승인 또는 미루기 행동의 패턴을 살펴본다.
예방
예방 열은 팀이 어떻게 효과적으로 도구와 프로세스를 최적화하여 앱을 구성하는 자산으로 들어가지 않을 수 있는 문제를 막는지를 보여줍니다.
커버리지
커버리지 열은 보안 관점에서 앱을 구성하는 자산이 어느 정도 보호되어 있는지를 나타냅니다.
리스크가 도입되는 방식의 구분
리스크 노출만 평가할 때는 제품에 문제가 어떻게 도입되었는지를 고려할 필요는 없습니다. 문제를 조사하거나 감사를 수행할 때는 문제가 악용될 수 있다는 점을 인식해야 합니다.
그러나 AppSec 프로그램의 성능을 평가할 때는 문제가 어떻게 도입되었는지를 이해하여 공격에 대비하고 다음 감사나 공격 방어를 위한 준비를 할 수 있어야 합니다.
이슈는 다음과 같이 분류됩니다:
베이스라인 이슈
이 프로젝트가 모니터링되기 시작한 첫째 날에 식별된 문제를 포함합니다. 베이스라인 이슈는 Snyk 모니터링이 시작될 때 존재했던 위험에 대한 새로운 시각을 나타냅니다.
회사가 보안 도구를 사용하기 시작할 때 베이스라인 문제를 식별할 수 있지만, 시간이 흐르면 발견할 수도 있습니다. 베이스라인 문제는 새로운 비즈니스 유닛을 Snyk에 온보딩할 때, 이전에 이미 온보딩된 팀의 레거시 코드 식별 중, 또는 인수로 인해 발견될 수 있습니다.
베이스라인 이슈를 노출 측면에서 다른 이슈와 동일하게 처리해야 하지만, 베이스라인 이슈 증가는 비베이스라인 이슈 증가만큼 경계에 두지 않아도 됩니다.
예방 가능한 이슈
예방 가능한 문제들은 개발자가 가능한 Shift-left 도구 및 프로세스를 더 활용했다면 SDLC(소프트웨어 개발 생명주기)에서 더 일찍 식별되고 해결될 수 있었던 문제입니다.
문제는 개발자가 Snyk Learn을 활용하거나 IDE 플러그인을 활용하거나 PR 체크를 활성화하거나 CLI에서 snyk test를 지역에서 실행하거나 빌드를 중단하거나 또는 이외의 작업을 통해 발생 가능합니다. Snyk가 문제를 알고 있다면 테스트가 그것을 잡을 수 있습니다. 생산 환경으로 들어가기 전에 이슈를 잡을 수 있습니다. 빌드를 중단시키는 것부터 시작하여 중요 문제만이 아니라 중요와 높음 문제까지 문을 깰 수 있습니다. 중요 문제만이 아니라 PR을 승인하지 못하기까지 해당 PR을 승인하지 못하기까지볼 수 있습니다.
문제가 예방 가능한 경우, 문제가 감지되기 일주일 전에 Snyk에서 문제에 대해 알고 있었음을 의미합니다. 문제가 일주일 내에 해결될 수도 있지만, 이 정의는 코드가 배포 프로세스를 통해서 오래 걸리거나 주간 반복 테스트인 경우에 대비하여 약간의 여유를 제공합니다.
예방할 수 없는 이슈
예방할 수 없는 문제는 개발자가 좌로 이동하지 않는 대신 새로운 취약점이 발표되거나 새로운 보안 규칙이 생성되는 외부 요인의 결과입니다.
몇 달이나 몇 년 동안 수정되지 않은 저장소가 있을 수 있지만, log4j와 같이 새로 발표된 취약점으로 해당 자산이 취약해졌습니다. 새롭게 발표된 심각하거나 높은 심각도를 가진 오픈 소스 취약점으로 인해 톱 경영진, 파트너 및 고객의 관심이 끌릴 수 있습니다. 이 범주의 이슈가 식별되고 그 추세가 빠르게 측정될 수 있어야 합니다.
문제가 Snyk에서 알려진 후 7일 이내에 발견된 경우 이를 할 수 없는 문제로 분류합니다. 사용중인 의존성에서 발생한 새로운 취약점 또는 프로젝트에 도입되는 동안 공개된 취약점과 함께 폭로된 취약점을 포함할 수 있습니다. 문제가 7일 이내에 해결될 수도 있지만, 이 정의는 코드가 배포 프로세스를 통과하거나 주간 반복 테스트인 경우에 대비하여 약간의 여유를 제공합니다.
기타 새로운 이슈
Snyk의 오늘과 같은 이슈를 쉽게 예방 가능 또는 예방할 수 없음으로 분류하기 어려운 이슈가 모두 기타 새로운으로 레이블링됩니다. 이 결정의 주요 입력은 이슈 및 문제를 식별한 날짜입니다. 이 둘 중 하나가 의심스러운 경우 이슈는 기타 새로운으로 분류됩니다.
현재 모든 및 이슈는 기타 새로운으로 레이블이 지정됩니다. 오픈 소스 라이선스 이슈도 기타 새로운으로 분류될 것입니다.
Last updated