CURVC DevOps

페이지 트리

이 문서는 SonarQube Security Hotspot 에 대한 정보를 공유하기 위해 작성되었다. 




보안 핫스팟(Security Hotspot)이란?

보안 핫스팟(Security Hotspot)은 개발자가 검토(Review)해야 하는 보안에 민감한 코드 조각을 강조 표시한다.
보안 위협이 없는지 해당 코드 조각을 검토하고, 결과에 따라 코드를 보호하기 위해 수정 사항을 적용해야 한다.

핫스팟을 보는 또 다른 방법은 여러 개의 중복 보호 계층(Several redundant protection layers)이 애플리케이션에 배치되어 공격이 발생했을 때,
보다 더 탄력적으로 복구하는 레이어드 시큐리티(Defense in depth) 개념일 수 있다.


취약점(Vulnerability) 또는 핫스팟(Hotspot)?

핫스팟(Hotspot)과 취약점(Vulnerability)의 주요 차이점은 수정 프로그램 적용 여부를 결정하기 전에 검토가 필요하다는(the need of a review) 것이다.

  • 핫스팟을 사용하면 보안에 민감한 코드가 강조 표시되지만 전체 응용 프로그램 보안에 영향을 주지 않을 수 있다. 코드를 검토하여 코드를 보호하기 위해 수정이 필요한지 여부를 결정하는 것은 개발자의 몫.
  • 취약점으로 인해 응용 프로그램의 보안에 영향을 주는 문제가 발견되어 즉시 수정해야 한다.


핫스팟의 예로 RSPEC-2092가 있는데, 여기서 쿠키가 HTTPS가 아닌 연결을 통해 쿠키가 전송되지 않도록, 쿠키 보안 플래그를 사용하는 것이 좋지만 다음과 같은 이유로 검토가 필요하다.

  • HTTPS는 MITM 공격에 대한 주요 보호 기능이고, 보안 플래그는 네트워크 보안에 일부 오류가 발생할 경우에만 추가적으로 보호하는 기능일 뿐이다.
  • 추적 쿠키(Tracking cookie) 또는 그와 유사한 쿠키는 (HTTPS가 아닌 웹 사이트 포함) 모든 곳에서 전송되도록 설계 될 수 있다.

핫스팟을 통해 우리는 사용자에게 약간의 자유를 제공하고 컨텍스트 (예산, 위협 등)에 따라 가장 관련성이 높고 적절한 보호를 선택하는 방법에 대해 교육한다.


보안 핫스팟이 중요한 이유는?

개별 핫스팟을 수정해야 하는 필요성은 상황에 따라 다르지만 보안 핫스팟을 응용 프로그램의 견고성을 향상시키는 데 필수적인 부분으로 간주해야 한다.
Fix된 핫스팟이 많을수록 공격 시 코드가 더 안전하게 보호되며, 보안 핫스팟을 검토하면 다음을 수행할 수 있다.

  • 위험 이해 – 정보 보안 위험(위협 및 영향)을 줄이기 위해 수정 사항을 적용해야 하는 시기와 이유를 이해한다.
  • 보호 식별 – 핫스팟을 검토하는 동안 위험에 처한 코드 작성을 방지하고, 어떤 수정 사항이 적용되었는지 확인하고,
    강조 표시된 코드를 수정하기 위해 여전히 구현해야 하는 수정 프로그램을 결정하는 방법을 확인할 수 있다.
  • 영향 식별 – 핫스팟을 사용하면 전체 애플리케이션 보안에 미치는 영향을 기반으로 코드를 보호하기 위해 수정 사항을 적용하는 방법을 배우게 된다.
    권장되는 보안 코딩 방법은 핫스팟 페이지에 포함되어 검토하는 동안 도움이 된다.


수명 주기(Lifecycle)

보안 핫스팟에는 전용 수명 주기(Dedicated lifecycle)가 있다. 상태(Status)를 변경하려면 사용자에게 보안 핫스팟 관리(Administer Security Hotspots) 권한이 필요하고,
이 권한은 기본적으로 사용하도록 설정되어 있따. 찾아보기(Browse ) 권한이 있는 사용자는 보안 핫스팟에 할당된 사용자에 대해 댓글(Comment)을 달거나 변경할 수 있다.

상태(Statuses)

수명 주기 동안 보안 핫스팟은 다음 상태 중 하나를 사용한다.

  • To Review : SonarQube가 설정한 새 보안 핫스팟의 기본 상태. 보안 핫스팟이 보고되었으며 이를 확인해야 함.
  • Acknowledged : 개발자가 보안 핫스팟을 검토했으며 강조 표시된 위험에 대한 해결 방법이 보류 중.
    여기에는 수정이 진행 중이거나 다음 단계를 결정하는 데 시간이 필요한 경우가 포함됨.
  • Fixed : 개발자가 보안 핫스팟을 검토하고 수정 사항을 적용함.
  • Safe : 개발자가 보안 핫스팟을 검토하고 변경할 필요가 없다고 판단.(예: 다른 관련 보호 기능이 이미 마련되어 있기 때문에)


워크플로우(Workflow)

이 워크플로에 따라 보안 핫스팟을 검토하고 코드 보안에 필요한 수정 사항을 적용한다.

검토 우선 순위(Review Priority)

SonarQube가 보안 핫스팟을 감지하면 검토 우선 순위에 따라 보안 핫스팟 목록에 높음에서 낮음으로 추가된다.
높은 검토 우선 순위가 있는 핫스팟은 보안이 필요하고 우선적으로 주의가 필요한 코드를 포함할 가능성이 가장 크다.

검토 우선 순위는 각 보안 규칙의 보안 범주에 따라 결정된다. OWASP Top 10 및 CWE Top 25 표준에서 높은 순위에 오른 카테고리의 규칙은 높은 검토 우선 순위를 갖는 것으로 간주된다.
OWASP Top 10 또는 CWE Top 25 표준에 높은 순위가 매겨지지 않았거나 언급되지 않은 범주의 규칙은 중간 또는 낮음으로 평가된다.

핫스팟 검토(Reviewing Hotspots)

핫스팟을 검토할 때는 다음을 수행해야 한다.

  1. What's the risk? 탭을 검토하여 보안 핫스팟이 발생한 이유 파악.
  2. Assess the risk 탭에서 Ask Yourself Whether 섹션을 읽고 보안 핫스팟에서 강조 표시된 코드를 보호하기 위해 수정 사항을 적용해야 하는지 확인.
  3. 코드가 안전하지 않다고 판단되면, How can you fix it? 탭에서 Recommended Secure Coding Practices를 따라 코드 수정.

위 단계를 수행한 후 보안 핫스팟을 적절한 상태(위 참조)로 설정한다. 다른 사용자의 검토가 추가적으로 필요한 경우 To review 상태로 남겨둘 수 있다.

검토 기록(Review History)

Review history 탭에는 보안 핫스팟이 할당된 상태 및 검토자가 핫스팟과 관련하여 작성한 모든 설명을 포함하여 보안 핫스팟의 기록이 표시된다.

IDE에서 핫스팟 검토(Reviewing Hotspots in your IDE)

개발 IDE에서 직접 보안 핫스팟을 보면, 문맥(Context)를 더 잘 이해하고 안전한지 여부를 결정하는 데 도움이 될 수 있다.
인증된 사용자로 표시되는 Open in IDE 버튼의 용도입니다. 이 기능은 다음 IDE에서 사용할 수 있다.

프로젝트는 적절한 IDE에서 열려 있어야 하며, SonarLint의 연결 모드를 통해 서버에 바인딩되어야 한다.


SonarQube가 분석한 개정(Revision) 또는 분기(Branch)는 IDE에서 연 것과 동일하지 않을 수 있다. 이 경우 SonarLint는 로컬 코드에서 보안 핫스팟을 찾기 위해 최선을 다할 것이다.



참조 링크



  • 레이블 없음

추가적인 정보를 확인하세요.