페이지 트리

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





개요

SonarQube는 소스 코드에 대한 Rule(Rule)을 실행하여 Issue를 생성합니다. Rule에는 네 가지 유형이 있습니다.

  • Bug (안정성)
  • Vulnerability (보안 취약점)
  • Code Smell (유지 관리 가능성)
  • Security Hotspot (보안 핫스팟)

Code Smell 및 Bug의 경우 가양성(Zero false-positives)이 전혀 없을 것으로 예상됩니다. 적어도 이것은 개발자가 수정이 필요한지 궁금해하지 않아도 되도록 하는 목표입니다.

Vulnerability의 경우 목표는 Issue의 80% 이상이 참 긍정(True-positives)이 되도록 하는 것입니다.

Security Hotspot Rule은 보안에 민감한 코드에 주의를 기울입니다. Issue의 80 % 이상이 개발자가 리뷰 한 후 상태가 "Reviewed"로 신속하게 해결(Resolved) 될 것으로 예상됩니다.

Rule 페이지는 기존의 모든 Rule을 검색하거나 제공된 템플릿을 기반으로 새 Rule을 만들 수 있는 진입점입니다.


Rules(규칙)

기본적으로 상단 "Rule" 메뉴에 진입하면  SonarQube에 설치된 사용 가능한 모든 Rule을 볼 수 있습니다. 왼쪽 창에서 검색 기준에 따라 선택 범위를 좁힐 수 있습니다.

  • Language(언어) : Rule이 적용되는 언어
  • Type(유형) : Rule 유형 - Bug, Vulerability, Code Smell, Security Hospot
  • Tag(태그) : Rule을 분류하고 더 쉽게 발견 할 수 있도록 Rule에 태그 추가
  • Repository(저장소) : SonarQube에 Rule을 제공하는 엔진 / 분석기
  • Default Severity(기본 심각도) : SonarQube에서 정의한 Rule의 원래 심각도
  • Status(상태) : Rule은 3 가지 Status를 가질 수 있음

    • Beta(베타) : Rule이 최근에 구현되었으며 아직 사용자로부터 충분한 피드백을 얻지 못했기 때문에 가양성 또는 거짓 부정(False positives or False negatives)이있을 수 있음
    • Deprecated(더 이상 사용되지 않음) : 유사하지만 더 강력하고 정확한 Rule이 존재하므로 이 Rule을 더 이상 사용하지 않음
    • Ready(준비) : Rule을 프로덕션에서 사용할 준비가 됨
  • Available Since(이후 사용 가능) : SonarQube에 Rule이 처음 추가된 날짜, 예를 들어 플러그인의 마지막 업그레이드 이후 모든 새로운 Rule을 나열하는 데 유용
  • Template(템플릿) : Custom(사용자 지정) Rule을 만들 수 있는 Rule 템플릿을 표시
  • Quality Profile(품질 프로필) : 특정 프로파일에 포함 또는 제외된 Rule

Qulaity Profile을 선택한 경우, 활성 심각도(Active severity)와 상속 여부(Inherited)를 확인할 수도 있습니다. 자세한 내용은 품질 프로파일 설명서를 참조하십시오.


Rule 세부 정보

Rule의 세부 정보를 보려면 Rule을 클릭하거나 오른쪽 화살표 키를 사용합니다. 기본 Rule 데이터와 함께 활성(Active) 상태인 프로필(Profile)과 함께 Issue 가 발생한(Open) 횟수를 확인할 수도 있습니다.

다음 작업은 올바른 사용 권한이 있는 경우에만 사용할 수 있습니다. "품질 프로파일 및 게이트 관리(Administer Quality Profiles and Gates)"

  • Add/Remove Tags(태그 추가/제거):

    • Rule에 기존 태그를 추가하거나 새 태그를 만들 수 있습니다. (텍스트 필드에 입력하는 동안 새 이름을 입력하기 만하면됩니다)
    • 일부 Rule에는 제거 할 수없는 태그가 내장되어 있으며 Rule을 제공하는 플러그인에서 제공합니다.
  • Extend Description(확장 설명):

    • Rule 설명을 확장하여 조직에서 특정 Rule을 사용하는 방식을 사용자에게 알리거나 Rule에 대한 더 많은 통찰력을 제공할 수 있습니다.
    • 이 확장은 관리자가 아닌 사용자가 Rule 세부 정보의 일반적인 부분으로 사용할 수 있습니다.


Rule Template(템플릿) 및 Custom(사용자 지정) Rule

Rule Template 은 사용자가 SonarQube에서 자신의 Custom Rule을 정의 할 수있는 기초로 플러그인에 의해 제공됩니다. Template을 찾으려면 왼쪽 창 "Template" 항목에서 Show Templates Only(템플릿만 표시) 항목을 선택합니다.

Rule templates can easily be isolated from the selection when selecting Show Templates Only.

Template에서 Custom Rule을 만들려면 "Custom Rules" 제목 옆에 있는 Create(만들기) 버튼을 클릭하고 다음 정보를 입력합니다.

  • Name - 이름
  • Key (auto-suggested) - 키(자동 제안)
  • Description (Markdown format is supported) - 설명(마크다운 형식이 지원됨)
  • Default Severity - 기본 심각도
  • Status - 상태
  • The parameters specified by the template - Template에 지정된 매개 변수

Template에서 정의된 Custom Rule의 세부 정보로 이동하려면 "Custom Rule" 섹션의 링크를 클릭하여 이동할 수 있습니다.

Custom rules can be created from the SonarQube UI using the rule template.


Custom Rule

Custom Rule은 편집하거나 삭제할 수 있다는 점을 제외하고는 다른 Rule과 마찬가지로 간주됩니다.

Unlike Sonar rules, custom rules can be edited and deleted.

Note : Custom Rule을 삭제할 때 SonarQube에서 물리적으로 제거되지 않습니다. 대신 상태가 "REMOVED"으로 설정됩니다. 이렇게 하면 이 Rule과 관련된 현재 또는 이전 문제가 완전히 제거될 때까지 SonarQube에 표시될 수 있습니다.


Coding Rule 확장

Custom Coding Rule을 추가할 수 있습니다. 자세한 정보 및 자습서는 코딩 Rule 추가를 참조하십시오.


Rule 유형 및 심각도

Rule은 어떻게 분류됩니까?

SonarQube Quality Model은 Rule을 Bugs, Vulnerabilities, Security Hotspots, Code Smells 의 네 가지 카테고리로 나눕니다. Rule은 다음 질문에 대한 답변을 기반으로 카테고리에 할당됩니다.


코드에 대한 Rule이 명백하게 잘못되었거나 그렇지 않은 것보다 틀릴 가능성이 더 큽니까?
대답이 "예"이면 Bug Rule입니다.
그렇지 않다면 ...

해커가 악용 할 수있는 코드에 대한 Rule입니까?
그렇다면 Vulnerability Rule입니다.
그렇지 않다면 ...

보안에 민감한 코드에 대한 Rule이 있습니까?
그렇다면 Security Hotspots Rule입니다.
그렇지 않다면 ...

Rule은 버그도 취약점도 아닌가?
그렇다면 Code Smells Rule입니다.


심각도(Severity)는 어떻게 할당됩니까?

Rule에 심각도를 할당하기 위해 우리는 일련의 질문을 더 던집니다. 첫 번째는 기본적으로 다음과 같습니다.

일어날 수있는 최악의 일은 무엇입니까?

이 질문에 답하면서, 우리는 아마겟돈을 예측하지 않고 머피의 법칙을 고려하려고 노력합니다.

그런 다음 최악의 상황의 영향과 가능성 (심각도와 가능성은 어떻게 결정됩니까?, 아래 참조)이 높은지 낮은지 평가하고 답변을 진실 테이블에 꽂습니다.


영향(Impact)가능성(Likelihood)
Blocker

(눈금) 

(눈금) 
Critical

(눈금) 

(오류) 
Major
(오류) 
(눈금) 
Minor
(오류) 
(오류) 


심각도(Severity)와 가능성(Likelihood)은 어떻게 결정됩니까?

Rule의 심각도를 평가하기 위해 우리는 최악의 일부터 시작하여 (위의 심각도는 어떻게 할당됩니까? 참조) 범주별 질문을합니다.

Bugs(버그)

영향 : 최악의 문제로 인해 응용 프로그램이 충돌하거나 저장된 데이터가 손상 될 수 있습니까?

가능성 : 최악의 일이 일어날 확률은 얼마입니까?

Vulnerabilities(취약점)

영향: 최악의 상황을 악용하면 자산이나 사용자에게 심각한 피해가 발생할 수 있습니까?

가능성 : 해커가 최악의 상황을 악용 할 확률은 얼마입니까?

Security Hotspots(보안 핫스팟)

보안 핫스팟은 검토될 때까지 근본적인 취약점이 있는지 여부를 알 수 없으므로 심각도가 할당되지 않습니다.




참조 링크


  • 레이블 없음