Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Panel
borderColor#888888#C3CCD7
bgColor#FCFCFC

Table of Contents

Table of Contents
indent16px


How are rules categorized

규칙들은 어떻게 분류되어 있습니까?

The SonarQube Quality Model divides rules into three categories: Bugs, Security Vulnerabilities, and Code Smells. Rules are assigned to categories based on the answers to these questions:

Is the rule about code that is demonstrably wrong, or more likely wrong than not?
If the answer is "yes", then it's a Bug rule. 
If not...

Is the rule about code that could be exploited by a hacker?
If so, then it's a Vulnerability rule.
If not...

Is the rule neither a Bug nor a Vulnerability?
If so, then it's a Code Smell rule.

How are severities assigned?

To assign severity to a rule, we ask a further series of questions. The first one is basically:

What's the worst thing that could happen?
In answering this question, we try to factor in Murphy's Law without predicting Armageddon.

Then we assess whether the impact and likelihood of the Worst Thing (see How are severity and impact decided?, below) are high or low, and plug the answers into a truth tableModel은 규칙을 버그(Bugs), 보안 취약점(Security Vulnerabilities) 및 코드 악취(Code Smalls)의 세 가지로 분류합니다. 각 규칙들은 다음 기준에 따라 각 분류로 할당됩니다:

코드와 관련된 규칙이 명백한 잘못에 관한 것입니까? 혹은 보다 잘못된 측에 속합니까?

이 질문에 대한 답이 "네"인 경우, 해당 규칙은 버그(Bugs) 분류에 포함됩니다.
만약 그렇지 않은 경우...

코드와 관련된 규칙이 해커에 의한 착취와 관련된 것입니까?

이 질문에 대한 답이 "네"인 경우, 해당 규칙은 취약점(Vulnerability) 분류에 포함됩니다.
만약 그렇지 않은 경우...

코드와 관련된 규칙이 버그(Bugs)나 취약점(Vulnerability)에 해당하지 않는 것입니까?

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

규칙에 심각도(severity)를 할당하기 위해, 몇가지 질문을 계속 던집니다. 기본적으로 가장 첫 번쨰 질문은 다음과 같습니다:

이 일이 발생했을 때 최악의 상황으로 일어날 수 있는 일은 무엇입니까?

이 질문에 대한 답을 던지는 과정에서, 아메게돈(Armageddon)을 예측한 것이 아니라 머피의 법칙(Murphy's Law)을 고려하고자 했습니다.

이후 우리는 최악 상황과 관련된 영향도(impact) 및 가능성(likelihood)를 평가했습니다(아래, 심각도와 가능성은 어떻게 결정합니까?를 참조합니다). 높음(high)과 낮음(low)으로 각 요소를 평가했습니다:


 

impact

likelihood

Blocker

(plus)(plus)
Critical(plus)(minus)
Major(minus)(plus)
Minor(minus)(minus)

How are severity and likelihood decided?

To assess the severity and impact of a rule, we start from the Worst Thing (see How are severities assigned?, above) and ask category-specific questions.

Bugs

Severity: Could the Worst Thing cause the application to crash or to corrupt stored data?
Yes = high 

Likelihood: What's the probability that the Worst Thing will happen? 

Vulnerabilities

Severity: Could the exploitation of the Worst Thing result in significant damage to your assets or your users?

Likelihood: What is the probability that a hacker will be able to exploit the Worst Thing?

Code Smells

Severity: Could the Worst Thing lead a maintainer to introduce a bug?

Likelihood: What's the probability that the Worst Thing will happen

심각도와 가능성은 어떻게 결정합니까?

각 규칙의 심각도와 영향도를 평가하기 위해 우리는 가장 최악의 상황(심각도는 어떻게 할당됩니까? 참조)에서 시작해 분류 별로 질문을 던졌습니다.

버그(Bugs)

심각도: 최악의 상황이 발생하는 경우 어플리케이션에 크래시가 발생하거나 저장된 데이터를 손상시킬 수 있습니까?

가능성: 최악의 상황이 발생할 확률이 얼마나 됩니까?

취약점(Vulnerabilities)

심각도: 시스템 착취로 인해 최악의 경우 여러분의 자산 혹은 여러분의 사용자들에게 심각한 위험을 초래할 수 있습니까?

영향도: 해커로 인해 최악의 상황에 준하는 상황이 발생할 확률이 얼마나 됩니까?

코드 악취(Code Smells)

심각도: 최악의 상황이 발생하는 경우, 소프트웨어 유지보수담당자가 새로운 버그를 유입시킬 수 있습니까?

영향도: 최악의 상황이 발생할 확률이 얼마나 됩니까?